08 octubre 2014

Mi experiencia en Navaja Negra 2014 #nn4ed




Mucho ha dado que hablar Navaja Negra, uno de los Congresos de seguridad españoles, en los que la transparencia ha predominado, tanto en temas organizativos como de la decisión de la mayoría de las charlas, mediante el voto democrático por los asistentes al mismo.  Como ponente y asistente al mismo, puedo dar fe que el buen ambiente, la camaradería y esa sensación de volver a ver toda junta a un montón de loco por la seguridad, ha imperado. Sin embargo, no todo ha sido tan positivo. Quizá tardemos en saber qué sucedió con la demo de Pedro Candel AKA s4ur0n, debido a la cola que ha traído a nivel mundial con su charla "Pesadilla en RSA”.

Hablando única y exclusivamente en mi nombre, le envío un abrazo enorme a Pedro, que como cualquier humano, puede equivocarse. En cualquier caso, lo que hace noble a una persona, no es que no cometa errores nunca, sino su capacidad para reconocerlos públicamente, e incluso pedir disculpas por ello.

Por compromisos laborales en Madrid, me perdí la primera de las jornadas, la del jueves, donde debió haber un interesante debate entre cuerpos y fuerzas de seguridad del estado, con conocidos abogados y representantes de la Comunidad. Igualmente, me llegó muy buen feedback de la charla del amigo Pedro Sánchez y de lo amena e instructiva del abogado sevillano Luis Jurado #JE. 

El viernes por la mañana debuté en Navaja Negra 2014 con un taller patrocinado por Cyberoam, de Buenas Prácticas de Configuración de Sistemas de Seguridad Perimetral. Fueron dos horas y pico (y si no es porque miré el reloj, por mí, aún estaría allí hablando), de una charla bastante interactiva con el público, que permitió hacer una “clase colaborativa”, que desde mi punto de vista fue muy enriquecedora para todos, incluido por supuesto, para mí.



El viernes por la tarde, pude asistir a la charla de Chema Alonso. Ésta iba sobre ciertas peculiaridades en funcionamiento interno de Google a la hora de cachear e indexar las páginas que va viendo, permitiendo hacer BlackSEO, ataques de fuerza bruta, así como ciertas dosis de Google dorking.

Tras el descanso, vino la mencionada charla de Pedro Candel, a la que asistí muy parcialmente.

Para cerrar el día, estrené la charla “CSI Madrid S13E37: спасению” en la que condensaba lo más rápidamente un caso de peritaje forense al que tuve que hacer frente durante las Navidades de 2013-2014. Un caso que inicialmente parecía sencillo, al rascar en profundidad, simplemente se "fue de madre”. Varias configuraciones incorrectas, debido a que el servicio informático que mantenía la máquina demostró unos conocimientos nulos en materia de seguridad (usuarios con contraseña configurada como vacía desde hacía años y nunca cambiada, uno de ellos “admin” en el grupo administradores, el servicio Terminal Server abierto a Internet sin restricción alguna, etc,…) hicieron que varios ciberdelincuentes se lo pasaran pipa con un Windows 2003, utilizándolo cada uno para ganar dinero, de diferentes formas.



Al finalizar la charla, el turno de preguntas lo inauguró Dani Kachakil, que planteó una muy razonable duda, que hacía tambalearse todo el planteamiento del caso. Básicamente, Kachakil decía que un Windows 2003, por defecto, no permite que un usuario con contraseña vacía, se conecte a través de Terminal Server, y que para que esto se pueda hacer, hay que modificar una clave del registro de Windows, que invalida esa medida de seguridad. En el momento en el que lo planteó, me vinieron a la cabeza la de horas de trabajo invertido y pensé, pues tiene razón pero..... sin embargo, yo sé los logs que analicé, las conexiones del usuario “admin” registradas en el Log, desde direcciones IP de Rusia y China, entre otros, así como la actividad en el directorio del usuario admin…

Varios asistentes a la charla, que además indicaron que se dedicaban al mundo forense, corroboraron lo que decía Kachakil, y planteaban la misma duda. Además, Dani indicaba que había que hacer un cambio en una key del registro para permitir el acceso remoto, lo cual no cuadraba con los conocimientos tan pobres que demostró el servicio de mantenimiento informático (tomarse la molestia de buscar en Google cuál es la clave del registro y cambiar el valor correspondiente para poder entrar con contraseña vacía de forma remota, quizá fuese muy descabellado, pudiendo poner una contraseña sencilla). 

Tras el fin de la jornada del viernes, y ya de copas, abordé a Kachakil en un bar y estuvimos hablando del tema de nuevo. A su opinión se sumó Necronoid que rotundamente decía que eso no era posible y que tenía que existir algo más. Al rato, apareció Jesús Pérez Rubio que se mostró más neutral, no teniendo claro cuál era la solución o la raíz del problema. Con todo esto, la verdad es que aún tuve más dudas al respecto, aunque también estaba seguro de lo que había visto, por lo que… cuando llegué al hotel, me puse a trastear con un Windows 2003 que tengo en una máquina virtual, y esto fue lo que pasó: Creé un usuario llamado admin, con contraseña vacía (para poder hacerlo, tuve que eliminar los requisitos de contraseña, que tenía setteado a 12 caracteres en esa máquina); al crearlo con contraseña vacía, el sistema te indica que no se podrá acceder al sistema remotamente con ese usuario; lo incluí en el grupo administradores.  Trasteando por la Configuración de seguridad, en Directivas Locales -> Opciones de Seguridad, dí con una directiva que dice “Cuentas: Limitar el uso de cuentas locales con contraseña en blanco sólo para iniciar la consola”. La modifiqué a deshabilitada y probé desde una Kali,… rdesktop contra la IP, usuario admin, contraseña en blanco y para adentro…. Al final, no era tan difícil, aunque sinceramente, no entiendo para qué un administrador Windows iba a hacer esto, con los riesgos de seguridad que implica, pero todo apunta a ello.




Yendo más allá, la modificación de la directiva mencionada, por debajo, lo que hace es cambiar el valor de la clave HKLM\System\CurrentControlSet\Control\LSA\LimitBlankPasswordUse a valor 0. 
Sólo me quedaba comprobar, a partir de los ficheros que contienen la rama System del registro de Windows en HKLM, en la máquina analizada en el peritaje, si este valor era el indicado. Tras hacer un regdump.pl -vr del fichero system y filtrando por la cadena "limitblankpassworduse", se ve esto:

limitblankpassworduse (REG_DWORD) = 0x00000000 (0)

Es decir, que efectivamente, esto estaba así en la máquina y todos teníamos razón. Los que indicaban que por defecto no se podía acceder por Terminal Server con usuario con contraseña vacía a partir de Windows 2003, y yo en tanto en cuanto este setting había sido deshabilitado en su momento por "vayaustedasaberquién" siendo posible este cambio.

El sábado por la mañana pude ver parte de la charla de Abraham Pasamar sobre evasión de sistemas antivirus, de la que tiene una excelente saga en Security By Default, y lamentablemente no pude ver la de Alejandro Nolla ni la de Óscar Tébar.

Me habría gustado atender al resto de las charlas, pero entre motivos laborales el viernes, personales el sábado y conversaciones en la puerta con asistentes al evento, se me pasó el tiempo volando.

8 comments :

Dani dijo...

Esto ya entraría en la categoría de "desadministracion de sistemas"

NecronoiD dijo...

Reitero lo que te dije en su momento, que se me hace raro que un usuario que demuestra pocos conocimientos y dejadez total en la administración de sistemas elija desactivar una politica local (o tocar una clave de registro me da igual) en vez de poner una simple contraseña en una cuenta para acceder de forma remota, pero no es más que una opinion y el que tenia las evidencias del forense eras tu. Te agradezco la elegancia con que has tratado el tema.

Dani dijo...

Tampoco sabemos si todo este despropósito fue causado por la misma persona. A veces alquilas un piso y un año después te llega el pufo de la factura del gas del que estuvo antes...

Mario Vilas dijo...

Podria ser algun tipo de backdoor, no? De todas formas no descartes que haya algun articulo en StackOverflow o similar explicando como apagar la seguridad de Windows para "facilitar el acceso"...

Lorenzo Martinez dijo...

Precisamente aludí a que a lo mejor lo había buscado el técnico en StackOverflow, a uno de los que preguntaron al finalizar la charla. Respecto a lo del backdoor, aunque estuviese ejecutándose (que habían cambiado un fichero que era un backdoor), hasta donde el informático me dijo, se había redirigido sólo el TCP/3389 del router a la máquina, y no todo el tráfico,... Si hubiera estado en modo DMZ-Host, estoy seguro que se la habrían cepillado con más vulnerabilidades tipo NetBIOS, RPC o similares,... y la fiesta habría sido aún mayor.... Tengo claro que accesos con "admin" se hicieron por RDP, porque los logs de Windows indican esas conexiones

chema dijo...

Lo sorprendente es que algien que se dedica a hacer forenses haya dudado siquiera de algo tan basico como lo de las cuentas con contrasenya vacia (cualquiera con conocimientos basicos de window o de seguridad lo deberia saber).

El liston en este pais esta cada vez mas bajo.

silverhack dijo...

También cabe recordar que TS no sólo se utiliza para iniciar sesión a través de una consola central. Muchas aplicaciones en modo "Terminal Server" (Sobre todo antiguas, desactualizadas o sin soporte) necesitan iniciar sesión de manera interactiva en un sistema (Por ejemplo una aplicación que copia ficheros a %SYSTEMROOT% o a un PATH específico de máquina, o modifica claves de registro de manera remota, etc..) y por no tocar el código de estas se degrada la seguridad del sistema. Ojo, de todo el sistema, no de Terminal Server. Lo que muchos no saben es que modificando esa clave estás modificando todo lo que esté supervisado por la LSA, por lo que si estableces esa clave a "0", todo servicio que de alguna manera esté supervisado por la LSA (Recursos compartidos, registro remoto, inicios de sesión como servicio, etc..) se verá afectado por esta medida.

Es un problema muy antiguo que suele pasar en entornos de TS y Citrix, algo que ha traído de cabeza a muchos administradores de sistemas. En mi opinión no tiene nada que ver con que un administrador sepa o no sepa de seguridad, simplemente que si le obligan a loguear una aplicación (Antigua, sin soporte, etc, etc..) porque no necesitan-quieren cambiarla, pues no tiene más que hacerlo.

Hoy día este tipo de problemas ya se han solucionado tanto en TS como en Citrix, permitiendo poder generar tickets de SSO precisamente para "mejorar esta experiencia" sin degradar la seguridad de una plataforma-infraestructura.
En cuanto a la cuenta "adm", y sin haber participado en ese forense yo apuntaría a lo siguiente:
1.- Acceso a la máquina a través de otro medio (Malware, exploit, etc..)
2.- Creación de usuario adm sin password
3.- Modificación de clave de registro para permitir inicio de sesión sin password (Esto afecta no sólo a TS sino a cualquier servicio cuyo proveedor de credenciales esté supervisado por la LSA)
4.- Acceso NO SÓLO a través de TS. Podría haber iniciado sesión a través de psexec o meterpreter sin password y también habría colado...
Besitos

Lorenzo Martinez dijo...

Hola "chema"... Pues yo te lo explico muy fácilmente. Nunca creo tener el 100% de la verdad, máxime cuando todo un Dani Kachakil es quien me lo plantea por primera vez. No sé si estuviste, pero mi respuesta fue: "Tío, tiene que haber entrado por RDP con usuario admin. Sé lo que ví en los logs y en la actividad del sistema de ficheros... y todo coincidía". Evidentemente, cuando Kachakil, Necronoid y otros dos asistentes vienen con la misma duda, por supuesto que me hacen dudar, mejor dicho, me hacen buscar la raíz del problema, y ver que efectivamente, mi análisis forense fue correcto con la información que tenía.
Por lo demás, todo bien. Muchas gracias por tu constructivo comentario ;D