sábado, 31 de mayo de 2014

Unos estafadores utiliza la imagen de La Sexta, RTVE, Menéame o Antena3 para robar tus datos de tu Android

Hoy vengo a contar una historia curiosa y peculiar de cómo una persona haciendo uso de greyware es capaz de montarse un negocio robando los datos de personas que se descargan sus falsas apps de Google Play en un terminal Android. De cómo lo hace, y de cómo actúa una persona así. Para que quede claro, voy a comenzar la historia desde el principio, para que podáis seguir todo el hilo de investigación y al final me deis vuestra opinión. 
El Greyware y las apps en Google Play
Que en Google Play hay mucho adware no es algo que sea una novedad. Ya hace no mucho publiqué un artículo en el que creía que respecto al malware para Android ya se tiene el full-equip porque los estafadores han visto en él un canal propicio para llegar a las víctimas. Entre las cosas que campan por Google Play hay mucho greyware y adware. Muchas de ellas son aplicaciones que prometen cosas fantásticas de forma gratis, como cuando supuestamente Apple abrió una cuenta en Google Play para vender iWorks.

Figura 1: Un falso desarrollador vendiendo falsas apps de Apple

Es decir, software malicioso que roba datos engañando a los usuarios con unas políticas de privacidad y términos legales de difícil acceso y compresión, algo que se están encargando de hacer ilegal desde hace tiempo, para exigir más claridad y menos estafadores como estos.
Unapp.es se hace una base de datos con tus datos
Google, periódicamente va tirando estas apps de Google Play cuando sus procesos de revisión interna, las casas de antimalware, usuarios o empresas de seguridad van denunciando las apps y los developers maliciosos. Normalmente Google tira al día una buena cantidad de apps que puede rondar entre las 800 o las 2.000 - según el día -. Unas de ellas fueron las apps del desarrollador Wert Exchanger, que fueron tiradas por Google Play de su tienda  y que nos llevó a preguntarnos por qué.
Cuando fuimos a ver por qué Google Play las había tirado haciendo un poco de investigación interna pudimos confirmar que son apps que acceden a "demasiados" datos y que no hacen lo que prometen. Son fake apps que engañan al usuario. Saber a cuáles son los datos a los que acceden es fácil de comprobar, y mirando el código aparece esta sección que se publicó en el blog de Eleven Paths en el que se aprecia que se lleva datos del terminal para generar un buen fichero de datos personales que espero que tenga bien declarado en Agencia de Protección de Datos y con todas las medidas de seguridad pertinentes.

Figura 2: El código que se lleva los datos a un servidor llamado bd.unapp.es


Dicho esto, en el código se puede ver un dominio unapp.es así que bastaba con saber quién ponía este código que se lleva los datos haciendo una búsqueda Whois para ver que detrás de él está Santiago M.A.
La ofensa y amenaza
Cuando lo publicamos escribió a un compañero diciendo que está en sus términos legales la explicación de por qué se llevan esos datos - aunque no se notifica al usuario que se van a llevar esos datos en concreto de los terminales Andorid -. Lo que dice la política es genial, es justo esto:
" Los datos recabados son los adecuados, pertinentes y no excesivos en relación con el ámbito, las finalidades y servicios determinados, explícitos y legítimos de Usatek S.C"
Figura 3: Política de Google Play de acceso al IMEI

El número de apps que tiene haciendo esto, con este código es muy alto, actualmente unas decenas activas que al final del post os dejo con que desarrolladores las ha publicado.

El caso de una app falsa con la imagen de Menéame

Lo más gracioso, es que las apps que distribuye Santiago M.A. son falsas, ninguna hace lo que promete y utilizan técnicas agresivas para la difusión de la estafa. Uno de los usuarios activos que tiene ahora es Adrocia, donde se usa la imagen de Menéame, Google y un juego de niños.

Figura 4: El desarrollador Androcia mete el mismo código de fake app

En el caso de Menéate, que usa la imagen de Menéame - además de llevarse los datos con el código que os he dejado en la Figura 2 - fuerza al usuario a poner 5 estrellas sí o sí, para poder usar la app.

Figura 5: Menéate con Menéame. Una fake app que te roba tus datos.

Esto lo hace en todas las apps que publica, por ejemplo, bajo el desarrollador Androcia - uno de los que usa para este negocio -, y algunos usuario se han quejado abiertamente de esto en los comentarios que tienen que dejar.
Lo peor es que cuando te instalas una de sus apps, la política legal que te muestra es la que he explicado antes, y si no aceptas los términos legales, no pasa nada, a los 20 segundos da como que los has aceptado y NO se lleva los datos a su servidor. Ya sabes, tu nombre, email, IMEI, etcétera. Datos imprescindibles para ver el contenido según ellos.


Figura 7: A los 20 segundos te automáticamente da por aceptada la política

Sin embargo, como lo que interesa es ganar dinero, los datos de la persona sí que se envían al servidor de publicidad que está utilizando, tal y como se puede ver en esta captura hecha con Burp sobre una esta app corriendo sobre un emulador de Android.


Figura 8: Como se puede ver, se envían los datos a un servidor incluso sin aceptar la política

Por supuesto, una vez que la instalas, la app o no hace nada, o te muestra unas bonitas animaciones que no tienen desperdicio, como que está cargando algo. Lo más curioso es que encima de solo meter una cutre-animación para simular que hacen algo las apps, el tipo utiliza la misma en un buen montón de apps. Mirad este flash de apps para robar WiFi.


Figura 9: Una de las animaciones que usa en sus fake apps de hacking WiFi

Si miramos todos los dominios que usar para colgar estas animaciones, el chiringuito que tiene montado para ganar pasta con Adware haciendo fraude online es de un nivel de dispersión grande.

El resto de las apps que mantienen su negocio de greyware
Supongo que por este tipo de cosas, las apps son tiradas de Google Play, pero... el número de apps utilizadas en esa estafa es muy grande. Así, además del primer desarrollador que vinos antes que utilizaba esta estafa, hay muchos más y en Eleven Paths estuvimos buscándolos.

El primero de los usuarios con apps haciendo esto mismo fue el usuario przyjaciele aktor, que por supuesto ya no está en Google Play, pero ahora sigue creando más usuarios desarrolladores, como por ejemplo Nave Real, donde Google Play ya le ha tirado algunas apps.


Figura 9: Las apps de Nave Real, un desarrollador que roba igualmente los datos

En Multimedia apps, - activo ahora mismo - tiene la siguiente lista de apps. La lista de marcas son Antena3, Xplora, TVE, NASA, etcétera.


Figura 10: Las apps de Multimedia apps

En estas que quedan, es fácil ver en el código el mismo segmento que está publicado en la Figura 2 para llevarse los datos. Otro usuario que Google Play ya ha tirado, utilizaba apps con la imagen de La Sexta, RTVE, Antena 3, Televisión de Galicia, alguna que otra linterna, etcétera. Se pueden ver las apps de "Marica non chores" en la caché de Google.

Figura 11: Apps de Marica non chores que usaban el mismo código


Otro de las cuentas de desarrollador que está utilizando en esta recolección de datos con falsas apps es Ricardo Cholete, usando la imagen de Discovery Channel, ESPN, Canal Historia o TeleSur.

Figura 12: Apps de Ricardo Cholete


También tiene un desarrollador con nombre celeron que se ha sumado a la fiesta de las falsas apps de WhatsApp.



Otros desarrolladores que también uso fue Freida Ideal Desing & Program, Sestaapps, Sestao River The best, Piercing, Leti & Cia, Nay App, etcétera, que por suerte les han tirado ya todas las apps que publicaron. En la caché de Google puedes encontrar lo que hacían.
¿Para que robar todos estos datos?

La base de datos de tener asociado el IMEI, el número de teléfono y el correo electrónico puede venir bien para los que intentan meter un troyano bancario que robe los SMS de confirmación de operaciones cuando se sepa el nombre de correo electrónico. Es decir, supongamos que una persona está robando los usuarios y contraseñas de accesos bancarios con malware in the browser. Si roba también el correo electrónico, podría ser útil comprar una base de datos que sepa exactamente en qué terminal es en el que hay que meter el troyano, pero esto... esto solo es una suposición.

En definitiva, las apps que genera la empresa de Santiago M.A. no están hechas para hacerte ningún bien, y desde el inicio son aplicaciones fraudulentas hechas con el objetivo único de robarte los datos y ganar pasta con la publicidad que consigan que te envíen. Esperemos que Google endurezca los controles para evitar que este tipo de apps proliferen tan alegremente.

Actualización: La historia de esto continúa en Adware & Política

Fuente

viernes, 30 de mayo de 2014

El repentino y misterioso fin de TrueCrypt

TrueCrypt ha sido durante años la herramienta de cifrado de código abierto por excelencia y casi un estándar de facto, aunque siempre ha esta envuelto en un halo de misterio, sobretodo porque sus desarrolladores son anónimos. Ésto junto con todas las filtraciones sobre el espionaje de la NSA han levantado muchas suspicacias acerca de la seguridad de la herramienta, provocando incluso el surgimiento de proyectos de crowdfunding para auditar su código.

En el blog ya comentamos los resultados de la primera fase del proyecto 'Is TrueCrypt Audited Yet?' en la que no se encontraron evidencias de backdoors o código malicioso intencionado, sólo algunas vulnerabilidades debidas a que no se siguieron buenas prácticas de programación segura (falta de comentarios, funciones obsoletas, tipos de variable inconsistentes, etc) y algunas debilidades en las comprobaciones de integridad de cabeceras de volumen (Volume Header integrity check).

A falta de la segunda fase de criptoanálisis, ayer nos sorprendió una actualización en la página oficial de TrueCrypt en Sourceforge en la que sus desarrolladores anunciaban su fin principalmente por dos motivos:
1. usar TrueCrypt no es seguro y podría contener fallos de seguridad no corregidos
2. TrueCrypt se desarrolló fundamentalmente porque Windows XP no tenía soporte de cifrado nativo y, ahora que Microsoft ha finalizado su soporte, aconsejan migrar a ¡¡Bitlocker!! (WTF!).

De hecho en la página del proyecto subrayan que la web sólo se mantiene para ayudar a migrar los datos cifrados con TrueCrypt, detallan los pasos para migrarlos y publican la versión 7.2 que sólo permite descifrar...

¿Por qué de repente anuncian que TrueCrypt es inseguro? ¿lo han descubierto justo ahora o "ya lo sabían"? ¿Cómo es posible que recomienden migrar a una herramienta que no es de código abierto? (¿sus desarrolladores trabajan ahora para M$?)

La primera impresión fue pensar que la página había sido comprometida y se trataba de un hoax. Sin embargo según pasan las horas todo apunta a que los cambios son legítimos, la versión 7.2 está firmada con la clave GPG de sus creadores y (al menos) el código fuente de la nueva versión parece no contener malware: 43 archivos cambiados, 1760 añadidos, 4112 borrados y mucho "AbortProcess ("INSECURE_APP");"...

Sea como fuere, lo digan sus desarrolladores o no, con todo este misterio y con todo el dolor de mi corazón creo que si ha llegado el momento de dejar de utilizar TrueCrypt, pero no necesariamente hacia BitLocker, existen otras alternativas libres como TcPlay, Luksus, Cryptonite (para Android), RealCrypt (un spin-off de TrueCrypt), FreeOTFE, AxCrypt, AESCrypt, etc.


Y vosotros, ¿Cuál tienes pensado utilizar o ya utilizas alguna otra?



Fuente

martes, 27 de mayo de 2014

Localizar direcciones e-mail en servidores PGP KeyServers

Cuando se plantea hacer un test de intrusión a una compañía, una de las pruebas habituales es probar la tolerancia que tiene la organización a ataques dirigidos en modo APT con alguna prueba de phishing. Algo similar a como decía yo que había que probar la seguridad de tu organización para saber si se necesita con urgencia un plan de concienciación interno para el personal y alguna solución de segundo factor. El objetivo es fácil: robar identidades internas para conseguir accesos privilegiados a la red.
Para ello se deben recopilar los posibles objetivos, para lo que hay que buscar las direcciones de correo de las posibles víctimas, que luego se podrán buscar por distintas redes sociales para interactuar con ellos y hacerles el ataque. 
Localizar esos correos puede hacerse de muchas formas, desde usar The Harvester o Maltego para localizarlos en los buscadores, hasta hacer un spidering & crawling al sitio para localizar las direcciones de correo electrónico publicadas en la web, pasando por buscar en las bases de datos de identidades dumpeadas, revisando con la FOCA para extraerlos de los metadatos o en los lugares de configuración well-know, como los registros SOA del DNS, los datos en los Certificados Digitales o la información histórica de las entradas de Whois. Todo vale para localizar datos.

Figura 1: Correos electrónicos de fbi.gov localizados por Maltego

Una de las cosas que se pueden utilizar también son los servidores de claves públicas PGP. Si una persona está utilizando PGP (Pretty Good Privacy) para firmar y/o cifrar sus correos es necesario que comparta su clave pública PGP para que alguien pueda cifrar el contenido del mensaje con ella y garantizar que sólo él puede ver el contenido.
Para que sea fácil la distribución de claves públicas PGP se crean servidores de claves públicas llamados KeyServers que pueden ser consultados con clientes para hacer búsquedas. Estos servidores se montan en las organizaciones normalmente en el puerto 11371, así que un sencillo escaneo de puertos nmap en la red por ese puerto debería dejarte localizarlos.
Lo bueno es que también hay servidores de claves PGP públicas que funcionan vía web, desde que se publicó OpenPGP HTTP Key Server en el MIT, que permiten hacer búsquedas usando comodines. Así, si la clave es pública, puedes buscar direcciones de correo de cualquier organización.

Figura 2: El servidor OpenPGP del MIT

Algunas de esas claves son creadas y publicadas con cierto trolleo, porque al buscar las del FBI me han salido algunos resultados, que parecen cuanto menos sospechosos de haber sido inyectados como claves fake. Al final uno se crea el certificado digital que quiere y lo distribuye, incluso sin tener que ser suya la dirección de correo electrónico.

Figura 3: Resultados obtenidos al buscar fbi.gov

Este servidor del MIT no es el único, en España hay un servidor de claves PGP públicas en RedIris que también puede usarse para buscar datos en los certificados públicos PGP de, especialmente, dominios de la universidad.

Figura 4: Servidor de claves PGP públicas en RedIris

También tiene un servidor de claves públicas PGP el propio dominio de PGP.com donde aparecen otras bases de datos. Recordar que PGP es un software comercial también, y es quién ofrece este servidor.

Figura 5: Servidor de claves PGP públicas en PGP.com

Buscando por Internet pueden aparecer más servicios de claves públicas PGP en la web, como este que está en Alemania. Al final, cualquier pieza de información puede ser útil en un ataque, y nosotros en nuestro sistema de pentestig persistente Faast - que también cuida de que no se caduquen los certificados digitales como el gran FAIL que le ha pasado a Apple - buscamos en todos ellos para poder el mayor número posible de información a la hora de lanzar los plugins de pentesting contra los servicios.

lunes, 26 de mayo de 2014

YaCy: un motor de búsqueda distribuido y libre que utiliza P2P

YaCy es un motor de búsqueda gratuito que cualquiera puede utilizar para crear un portal de búsqueda para su intranet o para ayudar a buscar en la Internet pública. Al contribuir a la red P2P global, la escala de YaCy sólo está limitada por el número de usuarios en todo el mundo y es posible indexar miles de millones de páginas web. Es totalmente descentralizado, todos los usuarios de la red de motores de búsqueda son iguales, la red no almacena las solicitudes de búsqueda de los usuarios y no es posible que nadie pueda censurar el contenido de los índices compartidos.

El objetivo es lograr la libertad de información a través de una búsqueda en la Web libre distribuida y desarrollada por usuarios de todo el mundo.



Descentralización

Imagina que, en vez de depender de un propietario de software o de un gran motor de búsqueda profesionalizado, tu motor de búsqueda fuera operado por muchos ordenadores que no estan bajo el control de ninguna compañía o persona. Bueno, ¡eso es lo que YaCy hace! El resultado de la busqueda web descentralizada actualmente tiene alrededor de 1.4 mil millones de documentos en su índice (y continua creciendo) y mas de 600 operadores de peer contribuyen cada mes. Alrededor de 130.000 solicitudes de búsqueda son realizadas con esta red cada dia.


Imagen en vivo de la red “mundo libre”


Instalación sencilla
 
Su instalación sólo te llevará tres minutos. Sólo tienes que descargar la versión, descomprimir el paquete y ejecutar el script de inicio. En linux necesita OpenJDK7. No es necesario instalar las bases de datos externas o un servidor web, todo está ya incluido en YaCy.


Página del proyecto: http://yacy.net/en/index.html

viernes, 18 de abril de 2014

El Modo Dios en Windows 7 (God Mode)


Desde principios de 2010 se conoce (y todavía sigue vigente) una característica oculta en Windows 7 denominada "God Mode" que permite a los usuarios acceder a todos los paneles de control del sistema operativo dentro de una sola carpeta. De hecho incluyemás de 270 elementos configurables, muchísimos más de los que encontramos directamente dentro del Panel de Control estándar.
Lo más sorprendente es que basta con crear un nuevo directorio y renombrarlo con la siguiente cadena de texto al final:

GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}

Pruébalo y verás que serás capaz de manejar todo desde un solo lugar, desde cambiar la apariencia del puntero del ratón hasta hacer una nueva partición del disco duro. Se trata de un acceso directo para desarrolladores oculto y no documentado... y existen unos cuantos accesos directos más:

    Default Location – {00C6D95F-329C-409a-81D7-C46C66EA7F33}
    Biometrics – {0142e4d0-fb7a-11dc-ba4a-000ffe7ab428}
    Power Settings – {025A5937-A6BE-4686-A844-36FE4BEC8B6D}
    Notification Area – {05d7b0f4-2121-4eff-bf6b-ed3f69b894d9}
    Manage Credentials – {1206F5F1-0569-412C-8FEC-3204630DFB70}
    Get New Programs – {15eae92e-f17a-4431-9f28-805e482dafd4}
    Default Programs – {17cd9488-1228-4b2f-88ce-4298e93e0966}
    NET Framework Assemblies – {1D2680C9-0E2A-469d-B787-065558BC7D43}
    Wireless Networks – {1FA9085F-25A2-489B-85D4-86326EEDCD87}
    Network Neighborhood – {208D2C60-3AEA-1069-A2D7-08002B30309D}
    My Computer – {20D04FE0-3AEA-1069-A2D8-08002B30309D}
    Printers – {2227A280-3AEA-1069-A2DE-08002B30309D
    RemoteApp and Desktop – {241D7C96-F8BF-4F85-B01F-E2B043341A4B}
    Windows Firewall – {4026492F-2F69-46B8-B9BF-5654FC07E423}
    Performance – {78F3955E-3B90-4184-BD14-5397C15F1EFC}
    Sync conflicts: {289978AC-A101-4341-A817-21EBA7FD046D}
    Sync setup folder: {2E9E59C0-B437-4981-A647-9C34B9B90891}
    Windows Update: {36eef7db-88ad-4e81-ad49-0e313f0c35f8}
    Bluetooth Devices: {28803F59-3A75-4058-995F-4EE5503B023C}


Referencia: http://support.microsoft.com/kb/979240/es

sábado, 29 de marzo de 2014

El abc para desproteger un Excel con contraseña

Desde que soy consultor de seguridad una de las herramientas que más utilizo de mi arsenal de hacking es... Excel ٩(͡๏̯͡๏)۶ ... y cómo este blog va de lo que va... pues vamos a mostraros un pequeño "how-to" para romper las principales protecciones de nuestras hojas de cálculo favoritas.

Cifrar con contraseña

Algo muy común es proteger el acceso total al fichero con una contraseña:




Lo que hace Excel por debajo para proteger la hoja de cálculo de esta manera es cifrar el archivo con AES y una clave de 128 bits (ojo porque hay un pequeño truquito para aumentarla a 256 bits modificando el registro). Para romperlo, lo mejor en este caso es utilizar un ataque de diccionario con John the Ripper o cualquier otra herramienta que gustéis.... 

Primero obtenemos el hash de la contraseña del documento con office2john incluido en laversión jumbo 1.7.9 compilada por Robert Harris:
D:\Hacking\john-1.7.9-jumbo-7-Win-32\run>office2john.exe /cygdrive/d/Libro1.xlsx  > hash_excel.txt

/cygdrive/d/Libro1.xlsx:$office$*2010*100000*128*16*507e4f65f0c73a48077b22ce5473ccec*50946a93488c091f536b4063eb3ae667*799528a214fb108b73f91ef5806222ebf9049d87e963238ac5a1acf82f9eb9db

Ahora un poquito de benchmarking para comprobar la capacidad de mi patata de PC: 
D:\Hacking\john-1.7.9-jumbo-7-Win-32\run>john --test --format=office
Benchmarking: Office 2007/2010 SHA-1/AES [32/32]... DONE
Raw:    30.1 c/s real, 30.3 c/s virtual

Después iniciamos el ataque de fuerza bruta con el diccionario elegido: 
D:\Hacking\john-1.7.9-jumbo-7-Win-32\run>john -w:dicio.txt hash_excel.txt
Loaded 1 password hash (Office 2007/2010 SHA-1/AES [32/32])
123456           (/cygdrive/d/Libro1.xlsx)
guesses: 1  time: 0:00:00:00 DONE (Fri Mar 28 00:27:47 2014)  c/s: 14.83  trying
: 123456
Use the "--show" option to display all of the cracked passwords reliably
   
Y en menos de 5 segundos tenemos acceso al mismo, gracias en parte a que el dueño del documento utilizó una de las peores contraseñas posibles

Finalmente guardamos el fichero como Libro2.xlsm, pero antes en el desplegable 'Herramientas' seleccionamos 'Opciones generales' y eliminamos la contraseña de apertura:
  

Bloquear el proyecto VBA

Otra opción es establecer una contraseña para ver las propiedades o incluso visualizar el proyecto VBA (las macros). 




Sin embargo esta *irrisoria* protección es para el UI y básicamente añade unas pocas líneas al form:

CMG="0604AB00EA009E049E049A089A08"
DPB="C6B41DD07A30374D374DC8B3384DDC63D35C51C89D809616E325E4129493EEFDBC48EE77D47B79"
GC="6664CAA0CBE07BE17BE17B"


Estos campos corresponden a ProjectProtectionState, ProjectPassword y ProjectVisibilityState respectivamente. Por lo que si borramos esos campos (reemplazando el texto con espacios en blanco) Excel no nos pedirá una contraseña para ver el código del proyecto...

Para ello descomprimimos el fichero Libro2.xlsm como si de un zip se trataba, editamos el fichero xl\vbaProject.bin con notepad++ (u otro editor hexadecimal) y cambiamos DPB= por DBx=.

Luego guardamos el archivo con la misma extensión .BIN y agregamos al zip sustituyendo el mismo archivo.

Al abrir de nuevo el fichero Excel nos dirá que contiene una clave 'DPx' no válida:



Simplemente continuamos cargando el proyecto, ignoramos el error, asignamos una nueva contraseña en las propiedades de VBAProject y salvamos...

Al volver a abrirlo tendremos acceso al código de la macro:


Proteger hoja actual y estructura del libro

Otra opción que normalmente se utiliza es la de proteger la hoja actual y la estructura del libro para que otros usuarios no realicen cambios:


Sin embargo, quitar esta protección también es bastante trivial. Simplemente añade al proyecto VBA la siguiente macro: 


Sub PasswordBreaker()
    'Breaks worksheet password protection.
    Dim i As Integer, j As Integer, k As Integer
    Dim l As Integer, m As Integer, n As Integer
    Dim i1 As Integer, i2 As Integer, i3 As Integer
    Dim i4 As Integer, i5 As Integer, i6 As Integer
    On Error Resume Next
    For i = 65 To 66: For j = 65 To 66: For k = 65 To 66
    For l = 65 To 66: For m = 65 To 66: For i1 = 65 To 66
    For i2 = 65 To 66: For i3 = 65 To 66: For i4 = 65 To 66
    For i5 = 65 To 66: For i6 = 65 To 66: For n = 32 To 126
    ActiveSheet.Unprotect Chr(i) & Chr(j) & Chr(k) & _
        Chr(l) & Chr(m) & Chr(i1) & Chr(i2) & Chr(i3) & _
        Chr(i4) & Chr(i5) & Chr(i6) & Chr(n)
    If ActiveSheet.ProtectContents = False Then
        MsgBox "One usable password is " & Chr(i) & Chr(j) & _
            Chr(k) & Chr(l) & Chr(m) & Chr(i1) & Chr(i2) & _
            Chr(i3) & Chr(i4) & Chr(i5) & Chr(i6) & Chr(n)
         Exit Sub
    End If
    Next: Next: Next: Next: Next: Next
    Next: Next: Next: Next: Next: Next
End Sub

Ejecutalá y se mostrará la clave de respaldo que ocupa internamente el código de Excel en dicha hoja: 
  

A partir de ahora ya podremos editar la hoja excel e incluso desproteger el fichero:


Y nada, a correr!

jueves, 27 de marzo de 2014

Demonizando Latch para proteger archivos con dos llaves


Imaginemos que tenemos un servidor dispuesto para nuestros usuarios. Tenemos cierto archivo o carpeta que tiene que estar disponible para dos usuarios en concreto; el cual no puede ser leído o modificado sin el permiso de ambos.

Sería genial que ambos usuarios pudiesen tener el control sobre este hecho, como si se tratase de un cofre el cual necesita dos llaves (podrían ser más) para ser abierto, sin ni siquiera tener un acceso físico a la máquina, es decir,  que puedan decidirlo por control remoto desde su smartphone y así tener el control total sobre el acceso a dicho archivo o carpeta... 

Esta situación es posible si miramos las posibilidades que nos brinda LATCH (de paso les agradezco a 11paths el juguetico que me hace pasar unas horas muy entretenido) y hacemos un apañejo, o chapucilla a la espera de que implementen algo parecido (que seguro que lo han pensado).

Pues bueno vamos a ver como lo hacemos y al tiempo aprenderemos a hacer nuestros propios demonios en Linux.

Lo primero sería dar dos usuarios de alta en Latch, para así disponer de "las llaves" para nuestro cofre (una para cada uno). Lo haremos en latch.elevenpaths.com.

No me entretendré en este proceso por no alargar la entrada, si queréis verlo detenidamente echar un ojo a esta otro post crear cuenta latch.

Una vez hecho ésto pasaremos a registrar ambas cuentas en el sistema con el siguientescript , tambien tenemos descrito el proceso en la entrada anterior en la parte deemparejar nuestra cuenta. Como es obvio, lo haremos una vez por cada id de aplicación y su correspondiente secreto y en distintos archivos (latch-llave1.account y latch-llave2.account). Con ésto ya tenemos nuestras "2 llaves":


Liberando nuestro demonio

"Un demonio, daemon o dæmon (de sus siglas en inglés Disk And Execution MONitor), es un tipo especial de proceso informático no interactivo, es decir, que se ejecuta en segundo plano en vez de ser controlado directamente por el usuario. Este tipo de programas se ejecutan de forma continua (infinita), vale decir, que aunque se intente cerrar o matar el proceso, este continuará en ejecución o se reiniciará automáticamente. Todo esto sin intervención de terceros y sin dependencia de consola alguna.” (Wikipedia)

En este caso vamos a utilizar un demonio sencillo en System V, pero no olvidemos que lo podemos complicar tanto como queramos... 
#NUESTRO DEMONIO
#!/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/bin/daemonkeeper #Ruta a nuestro fichero a ejecutar
DAEMON_OPTS=''
NAME=daemonlatch            #nombre de nuestro demonio
DESC=keeper_of_seven_keys
PIDFILE="/var/run/${NAME}.pid" #Donde se guarda el pid del proceso
QUIET="--quiet"
START_OPTS="--start ${QUIET} --background --make-pidfile --pidfile ${PIDFILE} --exec ${DAEMON} ${DAEMON_OPTS}"
STOP_OPTS="--stop --pidfile ${PIDFILE}"
OWNER=root                              #el dueño del proceso
LOGDIR=/var/log/${NAME}          #donde guardaremos nuestros logs

test -x $DAEMON || exit 0

# SI NO EXISTE EL DIRECTORIO LOG, LO CREAMOS
if [ ! -d "$LOGDIR" ]; then
    mkdir -m 750 $LOGDIR
    chown $OWNER:$OWNER $LOGDIR
fi

set -e

case "$1" in
  start)
 echo -n "Starting $DESC: "
 start-stop-daemon $START_OPTS
 echo "$NAME."
 ;;
  stop)
 echo -n "Stopping $DESC: "
 start-stop-daemon $STOP_OPTS
 echo "$NAME."
        rm $PIDFILE
 ;;
  restart|force-reload)
 echo -n "Restarting $DESC: "
 start-stop-daemon $STOP_OPTS
 sleep 1
 start-stop-daemon $START_OPTS
 echo "$NAME."
 ;;
  *)
 N=/etc/init.d/$NAME
 echo "Usage: $N {start|stop|restart|force-reload}" >&2
 exit 1
 ;;
esac

exit 0
Guardaremos esta parte del demonio en /etc/init.d/ y le cambiaremos los permisos a 700. De manera que solo sea root quien pueda leer, escribir y ejecutar el archivo.

También crearemos el archivo pid en /var/run:
#chmod 700 daemonlatch 
#touch /var/run/daemonlatch.pid

Esta parte será la encargada del control; con la cual podremos parar, arrancar o re arrancar el demonio:
/etc/init.d/nombre del demonio /start/stop/restart

Ahora pasaremos a la segunda parte del demonio que llamaremos thekeeper que será la que se encargará de ver el estado de cada llave en el servidor de latch, de manera que si las dos llaves están activadas el archivo o carpeta se podrá leer, modificar,etc. según convengamos, o de lo contrario no se podrá:
#!/bin/bash
cofre=/home/manuel/importante.gpg
applicationId2="571a1Wfq8jnspoxk66pm"
secretkey2="rX2eZoqoBu6P1xWWwHVJNW15ErrlVgRcEqbtARF3"
LATCH2="/home/LATCH/latch-llave2.account"
account2=`grep "^$USER:" $LATCH2 |cut -d: -f2`
logs="/var/log/daemonlatch/daemonlatch.log"
##COMPROBAMOS LLAVE2
if [ -z `echo "$account2"|cut -d: -f2`  ]; then exit 0; fi
URL="/api/0.6/status/$account2"
requestSIgnature+="GET\n"
date2=`date -u '+%Y-%m-%d %H:%M:%S'`
requestSIgnature+="$date2\n\n$URL"
signed=`echo -en "$requestSIgnature" | openssl dgst -sha1 -hmac "$secretkey2" -binary|sed -e 's|.*= \(.*\)|\1|g'`
b64signed=`echo -n "$signed"|base64`
auth_header="Authorization: 11PATHS $applicationId2 $b64signed"
date_header="X-11Paths-Date: $date2"
JSON=`wget -q --no-check-certificate -O - --header "$auth_header" --header "$date_header" "https://latch.elevenpaths.com$URL"`
status2=`echo -e "$JSON" | sed -e 's|.*status":"\(.*\)","name.*|\1|g'`
echo $status2

##COMPROBAMOS LLAVE1

applicationId="JXM2krpxLzNxi41Ru0oe"
secretkey="SeTQQo4OzyJ02T2SB9q6qPAA8lNyWkUcA4NZdNiI"
LATCH="/home/LATCH/latch-llave1.account"
account=`grep "^$USER:" $LATCH |cut -d: -f2`
if [ -z `echo "$account"|cut -d: -f2`  ]; then exit 0; fi
URL="/api/0.6/status/$account"
requestSignature+="GET\n"
date=`date -u '+%Y-%m-%d %H:%M:%S'`
requestSignature+="$date\n\n$URL"
signed=`echo -en "$requestSignature" | openssl dgst -sha1 -hmac "$secretkey" -binary|sed -e 's|.*= \(.*\)|\1|g'`
b64signed=`echo -n "$signed"|base64`
auth_header="Authorization: 11PATHS $applicationId $b64signed"
date_header="X-11Paths-Date: $date"
JSON=`wget -q --no-check-certificate -O - --header "$auth_header" --header "$date_header" "https://latch.elevenpaths.com$URL"`
status=`echo -e "$JSON" | sed -e 's|.*status":"\(.*\)","name.*|\1|g'`
echo $status
if [ "$status" == "on" ] && [ "$status2" == "on" ]; then
date >>$logs
echo -e "cofre abierto " >> $logs
chmod 777 $cofre
elif [ "$status" == "off" ] && [ "$status2" == "off" ]; then
echo -e "cofre cerrado" >> $logs
chmod 000 $cofre
elif [ "$status" == "off" ] && [ "$status2" == "on" ]; then
echo -e "cofre cerrado" >> $logs
chmod 000 $cofre
elif [ "$status" == "on" ] && [ "$status2" == "off" ]; then
echo -e "cofre cerrado" >> $logs
echo 000 $cofre
else 
echo -e "Error de LATCH. Intenta de nuevo\n" >>$logs
echo 000 $cofre
fi

Por último haremos la tercera parte de nuestro demonio que llamaremos daemonkeeper, la colocaremos en el directorio /bin y le daremos permisos 700.

Con esta parte lo que se controlará es el tiempo que pasará entre chequear el estado de las llaves, en este caso será 30 seg.. 
#!/bin/bash
date >>/var/log/daemonlatch/daemonlatch.log
echo "demonio arrancado" >> /var/log/daemonlatch/daemonlatch.log
while true
do
sleep 30
/bin/thekeeper
done
Una vez creado nuestro demonio vamos a asignarle los niveles de ejecución o Runlevels.

Tenemos varios niveles de ejecución, y cada uno de ellos nos proporciona unas funcionalidades diferentes, y un entorno de trabajo distinto. 

La definición de cada runlevel la encontramos en el fichero /etc/inittab. En mi caso son los siguientes DEBIAN WHEEZY:

# Runlevel 0 is halt.
# Runlevel 1 is single-user.
# Runlevels 2-5 are multi-user.
# Runlevel 6 is reboot.

Para saber en qué nivel de ejecución estamos actualmente podemos utilizar el comando runlevel. Para iniciar o parar un demonio al entrar en un runlevel simplemente tenemos que crear un enlace simbólico en el directorio correspondiente al runlevel en el que queremos iniciar/parar el demonio. Los directorios con los enlaces a los scripts de los demonios son los de /etc/rcX.d/ donde X se corresponde con el número de runlevel. Así, por ejemplo, en el directorio /etc/rc5.d/ tenemos los enlaces a los scripts de los demonios que se iniciarán/pararán al entrar en el runlevel 5. Ahora que ya sabemos dónde hemos de colocar nuestros enlaces ya podemos crearlos. 

Es muy importante el nombre que le damos a los enlaces ya que de él depende si el demonio se inicia o se para y el orden en que se inicia/para. La sintaxis que se sigue en el nombre del enlace es la siguiente: S (para iniciar el demonio apuntado por el enlace) K(para parar el demonio apuntado por el enlace) y luego el orden en que se ejecutará; que puede ir desde 00 hasta 99 (siendo 00 la máxima prioridad). Además puede haber varios con la misma prioridad. 

Bueno al tajo!! Ahora para crear los enlaces simbólicos debemos hacerlo en los runlevels adecuados. Para iniciar en el runlevel 5 (multiusuario gráfico) y 3 (multiusuario) y para pararlo en el runlevel 6 (reinicio) y 0 (apagado). Lo hacemos con el comando ln de la siguiente manera:

ln -s /etc/init.d/daemonlatch /etc/rc5.d/S30daemonlatch
ln -s /etc/init.d/daemonlatch /etc/rc3.d/S30daemonlatch
ln -s /etc/init.d/daemonlatch /etc/rc6.d/K05daemonlatch
ln -s /etc/init.d/daemonlatch /etc/rc0.d/K05daemonlatch


Ya tenemos listo nuestro demonio!!!

Tan solo nos queda probarlo. Para ello simularemos que uno de los usuarios crea un archivo cifrado que se llamará 'importante' en su /home (igual lo podemos hacer con una carpeta)
$touch /home/manuel/importante
$gpg -c /home/manuel/importante


$rm /home/importante

Esto creará importante.gpg del cual ambos usuarios tendrán la clave.

Arrancamos el demonio:

#/etc/ini.d/daemonlatch start 

Cada cierto tiempo (el que hayamos estimado en el archivo daemonkeeper) nuestro demonio conectará con el servidor de LATCH consultando el estado de las llaves...

En cuanto uno de los dos usuarios que tienen las llaves en su poder bloquee su llave en LATCH, el archivo deja de estar disponible para nadie... y no estará accesible hasta que ambos lo decidan...

Con esto hemos conseguido que estos usuarios tengan un archivo mancomunado y pleno control en el acceso, les hemos dado una capa nueva de protección...

Podríamos hacer esto más complejo y elegante, como por ejemplo llevar un sistema de log mas pensado, hacer un fichero de configuración para el demonio y que recoja las variables de él, etc, etc....

Un saludo y sean buenos...