Redes Sociales

jueves, 27 de febrero de 2014

Pasos seguidos para la limpieza de las VMs del curso de INTECO "Ingeniería social y analisis de sospechas"

En el último curso impartido por INTECO desde el pasado Martes hasta hoy hemos hablado de ingeniería y "analisis de sospechas", curioso nombre cuando de lo que se trata es de detección y limpieza de troyanos.

Como parte práctica nos han dado cuatro máquinas virtuales infectadas que había que limpiar "a mano", sin herramientas de limpieza automática (léase cualquier tipo de antimalware). En esta entrada describiré los pasos que seguimos (los de mi grupo) para la limpieza de dichas máquinas virtuales.

Resolución maquina virtual VM02

Se arranca la maquina y se comprueba el problema:

No se encuentra ningún ejecutable en las carpetas de arranque . Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reinicia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD

cd HD

Se busca el listado de fichero creados los días 20 y 21 de Febrero (Sabemos que es cuando se infectaron las máquinas). No se encuentra ningun exe, ningun lnk ni nada interesante.

Encontramos dos ficheros interesantes:

  • Una carpeta setup
  • Un fichero llamado At1.job, que es una tarea programada.
  • LockScren.AO.lnk

La carpeta setup resulta ser c:\windows\system32\oobe\setup\setup.exe

Al mirar los contenidos del fichero At1.job vemos que se ejecuta el fichero setup.exe de la ruta anterior.

Probamos a mover ese fichero setup.exe a otra ruta. Rearrancamos Windows, y ya no aparece el Ransomware.

Restauramos una versión anterior de Windows.

Buscamos las entradas del registro que llamen a este setup.exe y aparecen las siguientes:

HKCU/Software/Microsoft/Windows/ShellNoRoam/MUICache=”C:\windows\system32\oobe\setup\setup.exe”
HKU/1-5-21..../Software/Microsoft/Windows NT/CurrentVersion/Winlogon/Shell=”C:\windows\system32\oobe\setup\setup.exe”

Las borramos. También borramos el fichero setup.exe.

El fichero lnk es un enlace al ejecutable que infectó la máquina, por lo que sabemos de que virus se trata (con enviar el fichero setup.exe también nos habria valido).

Buscamos por internet LockScren.AO y encontramos esta página:

http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Trojan:Win32/LockScreen.AO#tab=2

Resolucion VM03

Al arrancar la máquina, aparece este error de la ejecución de “other.res”:

Se busca ese fichero y aparece en

c:\Documents and Settings/aula2/Application Data/other.res

La pantalla de error tiene un icono muy pixelado que claramente pretende engañar.

El other.res también aparece en el administrador de tareas.

Se arranca la maquina y se comprueba el problema. No se encuentra ningún ejecutable en las carpetas de arranque . Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reinicia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD
cd HD

Se busca el listado de fichero creados los días 21 de Febrero (sabemos que las maquinas fueron infectadas en esa fecha).

Se encuentra un fichero Flash7.ocx.exe que suena raro:

En los momentos después de la ejecución del troyano se ven ficheros temporales de internet y la instalacion de Flash.

Volvemos a Windows.

Vemos que el Flash7.ocx (realmente Flash7.ocx.exe) tiene exactamente el mismo icono que el error. Lo mandamos a Virustotal.

Virustotal nos dice que es un virus y lo detectan 38 de 47 antivirus y que se llama urausy.

Mientras tanto se busca other.res en el registro de Windows:

Tambien se encuentra esta entrada:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell=explorer.exe, C:\Documents and Settings\aula2\Application Data\Other.res

Lo borramos y matamos el proceso. Tambien borramos el fichero.

Buscamos Flash7.ocx.exe en el registro. Aparece la siguiente entrada:

La ruta es HKCU/Software/Microsoft/Windows/ShellNoRoam/MUICache/

La borramos.

Borramos la carpeta completa Flash. No deja borrarla. Rearrancamos Windows en modo a prueba de fallos, tampoco la conseguimos borrar, por lo que entramos desde Linux y nos la cargamos.

Se borra tambien BRNDLOG.BAK en %UserProfile%/aula2/AppData/Microsoft/Iexplorer



Resolución maquina virtual VM04

Se arranca la maquina y se comprueba el problema.

No se encuentra ningún ejecutable en las carpetas de arranque . Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reinicia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD
cd HD

Se busca el listado de fichero creados el día 21 de Febrero (Sabemos que el bicho se instaló ese día en la máquina). No se encuentra ningun exe, ningun lnk ni nada interesante.

Buscamos por internet y encontramos un virus parecido llamado gpcode.ak, y una entrada de un blog( http://www.securelist.com/en/weblog?weblogid=208187531) donde indica que la única solucion es recuperar los ficheros usando photorec, ya que despues de encriptarlos, el virus los borra y los ficheros borrados, si no se a tocado demasiado el sistema, se pueden recuperar.

Nos ponemos a ello y recuperamos un montón de ficheros:

Eliminamos el fichero Bliss.bmp, que es el fondo de pantalla con la calavera.

Este es el resultado:



Resolución VM05

Se arranca la máquina y se comprueba el problema. No se encuentra ningún ejecutable en las carpetas de arranque. Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reincia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD
cd HD

Se busca el listado de fichero creados el día 21 de Febrero (Fecha de instalación del troyano). Encontramos tres ficheros interesantes:

  • Un fichero setup.exe
  • Un fichero sdrive64.exe
  • Un fichero Skomaz.lnk

Buscamos dicho Skomaz en internet y encontramos esta páginas http://www.spywarelib.com/remove--Trojan-spy-skomaz.html.

...donde habla del fichero sdrive64.exe. Y esta:

https://www.virustotal.com/es/file/e7fa7e304b3ab56c695a51d8caf832b79563969465b388420381ac13ac8b550b/analysis/

Donde habla de que el virus tiene 1165824 bytes.

Buscamos ficheros de ese tamaño y casualmente encontramos que hay uno llamado setup.exe (el de antes).

Los borramos y arrancamos. Ya no aparece la pantalla de rescate pero Windows no funciona.

Es porque en vez de lanzar explorer.exe en alguna entrada del registro esta lanzando sdrive64.exe

Lo encontramos en HKCU/Microsoft/Windows NT/Winlogon/Shell=C:\Documents and settings\aula2\Local Settings\Temp\sdrive64.exe

Voila!

jueves, 20 de febrero de 2014

Cifrado de correos electrónicos con GPG (1/2)

Voy a aprovechar un trozo del tema 9 del curso de seguridad de la Hacker High School, de la que soy traductor, para poner en contexto lo que es PGP, las claves públicas y privadas, MIME y S/MIME, de cara a luego a hacer la práctica del funcionamiento de todos estos conceptos. Lo hago por que la verdad, me ha parecido una explicación muy amena, sencilla e interesante y creo que todos deberíamos SIEMPRE enviar nuestros correos cifrados y firmados y evitar así que ocurran cosas como lo de la NSA. Ahí va:

PGP viene de Pretty Good Privacy (En castellano, Bastante Buena Privacidad) y fue desarrollado por Phil Zimmermann. Es posible que buscando por internet nos encontremos con la versión de código abierto llamada GPG (GNU Privacy Guard). GPG esta disponible gratis para muchas plataformas, y solo usa algoritmos abiertos y públicamente evaluados.

GPG trabaja sobre el principio de gestión de claves públicas y privadas, lo que significa que las claves tienen una parte PÚBLICA que se la puedes dar a cualquiera que quieras que te envíe un correo cifrado, y una parte PRIVADA que debes mantener en secreto, y que es la única forma de descifrar el mensaje que has recibido. Al conjunto de clave pública y privada se le llama par de claves, y generalmente es lo primero que generas cuando instalas GPG en una máquina. El par de claves está protegido por una contraseña de manera que puede no ser modificado por nadie más que por el dueño. Puede ser necesario alterar el par de claves cuando quieras cambiar las direcciones de correo que el par de claves soporta, o por si quieres hacer uso de otras funciones.

Dado que necesitas la clave pública de alguien a quien quieras enviar un mensaje cifrado, existen servidores como pgp.mit.edu donde puedes descargar la clave o claves públicas asociadas con una dirección de correo en concreto, así como subir tu propia clave pública. Es posible que las claves hayan expirado o que se pierdan las contraseñas privadas, de manera que siempre usa la última clave o incluso mejor, pide al destinatario de tu correo que te mande la suya y confirma y confirma el fingerprint (una especie de más corto).

MIME (Multi-Purpose Internet Mail Extensions) es un conjunto de extensiones del protocolo de correo SMTP (Simple Mail Transfer Protocol). MIME permite enviar como adjuntos diferentes tipos de contenidos tanto de datos como multimedia, audio, video, imágenes, ficheros comprimidos, y aplicaciones. La cabecera MIME se inserta al principio del correo electrónico y el cliente de correo del receptor usa esta información para determinar qué programa está asociado con el fichero adjunto. MIME por sí mismo no proporciona ningún tipo de seguridad a los correos o a los adjuntos.

S/MIME (Secure/Multipurpose Internet Mail Extensions) es un protocolo que añade las características de firma digital y cifrado a los ficheros adjuntados al mensaje mediante MIME. Usando firma digital, S/MIME consigue garantizar la autenticidad, integridad y no repudio del mensaje (“no repudio” significa que no puedes negar que lo hayas mandado tu). S/MIME proporciona privacidad y seguridad (usando el cifrado) a los correos que usen este protocolo.

Cuando consultas un servidor de claves, ¿Cómo puedes estar segur@ de que una clave pública de un destinatario de correo electrónico es realmente la suya y no ha sido subida por cualquier otra persona?. La solución a este problema es que estas claves pueden ser firmadas por terceras personas. Imagina que ya tienes la clave (pública) de alguien en quien confías, y que sabe quien es la persona a la que quieres mandar un correo electrónico. Esa otra persona puede firmar la clave pública, lo que significa que le añade un poco más de confianza a esa clave, dado que tu ya conoces a esta otra persona. Esto es conocido como confianza heredada. Por supuesto, también puedes encontrar otra forma de ponerte en contacto con el destinatario y pedirle que te mande su clave pública, o recibir la “huella” de la clave – la huella es un checksum de la clave que es fácil y rápida de verificar. En un servidor de claves, cada clave también tendrá un ID o identificador – que es otro checksum con el mismo objetivo.

Enviar un correo cifrado usando GPG. La mayor parte de los clientes de correo soportan extensiones que facilitan el manejo de claves y el cifrado de mensajes. Los mejor es comprobar de antemano si el destinatario de tu mensaje tiene una clave pública y obtenerla, ya sea de un servidor de claves, o del propio receptor del mensaje.

A continuación, escribe el correo electrónico como haces habitualmente (de nuevo recomendamos usar texto plano en vez de formato HTML), añade cualquier fichero adjunto que necesites y dile a tu cliente de correo que lo cifre y lo mande. Si decidiste firmar el correo, el cliente de correo habrá usado tu clave privada para firmar el mensaje primero, y a continuación habrá usado la clave pública de tu destinatario para cifrar el correo y todos los ficheros adjuntos. Si proteges tu par de claves con una contraseña(¡deberías!), tu cliente de correo te pedirá esa contraseña.

Recibir un correo cifrado usando GPG. Los correos cifrados con PGP contienen o bien un fichero adjunto marcado como GPG, o tienen un bloque de texto con una cabecera que le dice al cliente de correo que acaba de recibir un correo cifrado. El cliente de correo ahora accede a tu clave privada (posiblemente pidiéndote antes una contraseña) y descifra el mensaje y todos los adjuntos. Si el mensaje no fue cifrado con tu clave pública este descifrado simplemente fallará. Si el mensaje fue firmado por el emisor, la extensión (o plugin) GPG del cliente de correo usará la correspondiente clave pública para verificar la firma también. El plugin de GPG que utilices te alertará de cualquier problema que encuentre con las firmas o ficheros adjuntos, pero en general, una vez instalado, el uso de GPG es bastante fácil.

miércoles, 12 de febrero de 2014

La aventura sigue siendo usar el DNIe

El proceso de firmado con el DNI electrónico sigue siendo una pequeña pesadilla y por lo que veo, la web http://www.dnielectronico.es sigue pecando de poca claridad. Se explica, de primeras, todo el proceso de validación de los certificados, cuando lo que quiere el usuario de a pie es utilizarlo.

Esta muy bien intentar convencernos de que el DNIe es buenísimo y segurísimo pero lo que necesita el usuario es un "guia burros" que le indique paso a paso como utilizarlo.

Con un DNIe con los certificados recién renovados y un portátil con Windows 8 recién instalado, me propuse hacer funcionar el DNIe y poder así firmar documentos electrónicamente. Accedí a la página que recomendaba mi lector, un LTC31 de C3PO, la antes mencionada http://www.dnielectronico.es.

Me gustó que en la página de inicio hubiera una opción "Compruebe su DNI"... que por desgracia te lleva una página con mucho texto y muchas explicaciones pero nada clara a la hora de comprobar el funcionamiento del DNI. El enlace para la comprobación se encuentra al pie de la página y en mi caso, me llevó a una página de error del navegador:

Pues vaya... si que empezamos bien. Será entonces necesario instalar los drivers del lector. ¿Pero no venían ya incluidos en Windows 7 y 8?. No tardo mucho en encontrar que, ciertamente en Windows 7 y Windows 8 no hay que instalar los drivers del DNI electrónico... pero los certificados sí. Tras un rato de lectura por el portal, instalotodos los certificados habidos y por haber, y esto sigue sin funcionar. Hasta que leo un comentario "Instalar en su navegador el Certificado Raíz de la FNMT clase2 CA. Este paso es especialmente importante en el navegador Mozilla Firefox ya que no lo incorpora por defecto en el almacén de Autoridades". Leches, estoy usando Mozilla Firefox. Me paso a Internet Explorer y la página carga como la seda:

Bueno, ahora queremos firmar digitalmente un documento. Vamos a empezar haciendo la prueba de firma que nos recomienda el propio portal del DNI: https://av-dnie.cert.fnmt.es/compruebacert/firmar.action. Lo primero que nos avisan es que es necesario tener instalado Oracle Java. Vaya tan seguro como es el DNIe, es necesario tener instalado Java, el sumidero de seguridad más grande que tenemos hoy en día...

Una vez accedemos a este sitio ya con Java instalado, nos aparece un aviso indicándonos que se va a ejecutar un applet "de origen desconocido". Pues vaya... Y cuanto más lees, mejor: "esta aplicación se ejecutará con acceso restringido, lo que puede poner en peligro su computadora e información personal". Eso sí: "Active la casilla (de que acepta los riesgos) y haga clic en Ejecutar para iniciar la aplicación".

En fin, from lost to the river, hacemos clic y le damos a ejecutar. Nos sale otro aviso y le decimos que sí, que permitimos la ejecución del Applet de Java. Y por fin nos carga la aplicación de prueba. Nos sale una página bastante simple donde podemos poner un texto en la parte superior (y ojo, no poner nada en la parte inferior porque si no, fallará la firma).

Al darle al botón "Firmar Texto" se inicia una cadena de hasta 6 solicitudes de permiso a las cuales vamos respondiendo que si, que firmar, poniendo la contraseña (el PIN), dándole a permitir, que si, que lo que quiera:

Finalmente, si lo hemos hecho rápido (el Timeout parece muy corto en la aplicación), nos aparece nuestro texto firmado.

Que bien... ¿y tanto trabajo para esto?. Bueno, hasta ahora sólo hemos comprobado que funciona. Una vez que tenemos el DNIe activado, funcionar con él no debería ser muy difícil.

En el portal de www.usatudni.es nos muestran una lista de servicios on-line que se pueden (en teoría) hacer con el DNIe.

Por ejemplo voy a comprobar mi saldo de puntos del carnet de conducir y mis antecedentes (OMG) en https://sede.dgt.gob.es/es/tramites-y-multas/permiso-por-puntos/consulta-de-puntos/. Vamos a esa página y luego hacemos clic en "consulta de puntos con certificado". Automáticamente nos salta el DNIe:

Al darle a "Aceptar" no tenemos que hacer nada más. Ahí está soy un crack y tengo todos los puntos!. Me lo imaginaba pero no estaba nada seguro!.

Bueno, voy a poner un resumen de pasos para hacer funcionar el DNI electrónico en un Windows 8:

  1. Renovar la contraseña y los certificados del DNI tal y como se explica en esta página.
  2. Conectar el lector del DNI electrónico en el ordenador y meter el DNI en el lector.
  3. Windows 8 debería detectar el DNI automáticamente, le damos a "Aceptar".
  4. La luz del lector se pone verde, parpadea y al final se pone roja... lo cual da bastante mala espina.
  5. USAR EL INTERNET EXPLORER. Para otras cosas no lo recomendaría y de hecho, importante, quitarle antes cualquier rastro de spyware o adware que tenga, no queremos que nuestro PIN o contraseña del DNI se lo lleven los rusos...
  6. Vamos a ésta página y seguimos lo pasos que he explicado antes.

En próximas entradas explicaré como acceder a otros servicios y veremos que otros muchos que deberían funcionar, lo cierto es que no van.

Saludos!

viernes, 7 de febrero de 2014

Sabadell Security

El pasado mes de Junio recibí completamente por sorpresa una tarjeta de débito del Banco Sabadell, con el que tengo una cuenta abierta desde hace años. WTF...!! (En español: que coj...!!) - pensé. Pero si mi tarjeta es válida hasta Marzo de 2014!!. Al llamar una amable señorita que intento convencer que mi vida dependía de que activara esa tarjeta: Que es mucho mas segura, que tiene tecnología Contactless, que es mucho mas bonita... y azul!!... En fin.

Por supuesto que no he activado la tarjeta hasta hoy, porque se acerca el mes de Marzo y empiezo a temer por mi vida.

El caso es que al activarla (desde mi ordenador) me he llevado la sorpresa de que el nuevo número PIN, asignado a la nueva tarjeta... es el mismo que el antiguo PIN!!!

Como podemos ver en la imagen, el último paso antes de activar la tarjeta es mostrar, bajo esos asteriscos tan coloridos el nuevo PIN:

¿Que por qué no quiero usar mi antiguo PIN?. Pero si es lo más fácil, cómodo y seguro!!!. Si así no me tengo que aprender engorrosos números de 4 cifras sin ningún sentido!!.

Pues la cosa es muy simple. Es igual que cuando se nos olvida una contraseña y pedimos recordarla, nunca nos deberían mandar la antigua, ya que esto significa que esta contraseña se encuentra almacenada en algún fichero sin "hashear". En este caso mi PIN se encuentra en alguna base de datos del banco sin cifrar o con un cifrado reversible.

Eso en sí no tiene por que ser malo. Al fin y al cabo, el sistema tiene que poder comparar que el PIN introducido en el cajero es el mismo que el de la tarjeta (cosa que no se realiza en el cajero, que no es más que un terminal tonto, que lo único que hace es enviar los números de la tarjeta y el PIN a los servidores del banco, que es donde realmente se hace el "macheo").

El problema es que igual que el sistema ha obtenido los dígitos de la tarjeta de un sistema y el PIN de otra y los ha comparado con lo que le llega del cajero, una persona con acceso al sistema (y conocimientos) podría hacer lo mismo. Y no mola. No me mola que alguien pueda conocer todos los datos de mi tarjeta incluido el código PIN.

El problema que si en vez de almacenar el pin en claro (o con un cifrado reversible) se almacenaran los hashes SHA-512 del PIN de la tarjeta, como se hace en el /etc/shadow de UNIX/Linux, daría igual. La debilidad del sistema es que hay 10.000 pines y solo 10.000, del 0000 al 9999 y no hay más. Cada uno con un hash único. Por tanto, conociendo esos 10.000 hashes estamos en las mismas.

Así que estamos en las mismas. Hasta que no aumentemos la longitud del PIN hasta por lo menos 12 números (aún así "solo" habría un billón de combinaciones). Lo ideal sería que los cajeros tuvieran un teclado alfanumérico y cada uno tuviera su contraseña alfanumérica de longitud variable de acceso a la tarjeta. ¿Demasiado dificil para el común de los mortales?. Yo creo que no.

Mientras tanto, deberemos seguir confiando en la seguridad física, electrónica y profesional de los bancos.