martes, 29 de noviembre de 2016

Clonado de discos con fallos: ddrescue

Hace unas dos semanas me pasaron un equipo para que lo arreglase. El problema: una actualización de Windows no se instaló correctamente. Lo que podía ser algo sencillo terminó con un cambio de disco.

Para empezar, el sistema intentaba hacer una reparación por su cuenta, es decir: había detectado un fallo y automáticamente entraba en modo reparación. Y no finalizaba.

Tampoco permitía acceder al menú avanzado pulsando F8, por lo que en ese instante esa opción para buscar soluciones no estaba disponible.

La única opción sería arrancar con un USB de Windows 10 y buscar la solución desde el pincho. Una de las configuraciones que hice fue indicarle al equipo desde el setup de la BIOS que me permitiera pulsar F2 o F12 para mostrar el menú de los dispositivos de arranque. Una vez tuve montada la unidad de arranque me llevé una desagradable sorpresa: quise tirar para atrás la instalación de la actualización a través la opción del punto de restauración sin ningún éxito: no se había creado ninguno. Raro, teniendo en cuenta que en teoría se crea uno justo antes de que se apliquen las actuaciones.

¿Qué más podía hacer? Solicitar hacer la auto-reparación, pero desde el USB. Tampoco hubo éxito. Si terminaba, era para reinicarse otra vez mostrando incluso mensajes de error.

¿Qué más hice? En alguno de estos arranques con el USB hice el famoso

sfc /scannow

Pero tampoco funcionó. De hecho, si no recuerdo mal, apenas empezó y ya había finalizado.

Por lo tanto, configuré el arranque de Windows para que me mostrara un menú con las distintas instalaciones para tener acceso a la posibilidad de pulsar F8 con total éxito:

bcdecit /set {bootmgr} displaybootmenu yes

Así, ya con acceso al menú principal, decidí arrancar en modo seguro, en el que se supone que se cargarían los menos controladores posibles. Y ahí estaba, arrancando normalmente hasta que me ofreció parar el checkdisk. No recuerdo si lo dejé pasar en ese instante o no. Creo que no. Pero después también daría su trabajo. El caso es que al rato ya estaba con acceso al sistema. Por lo tanto, reinicié, entré en modo normal (no usé el menú de F8) y ya estaba dentro. Esto parecía que ya sólo quedaba montar la actualización que había dado problemas y terminar de pasar el chkdsk en condiciones. Nada más lejos de la realidad.

Por un lado, se veía que el equipo de vez en cuando se bloqueaba un poco. Y por otro, que la actualización (KB3200970: lo bueno que tiene el guardar las ventanas durante meses) no se instalaba ni "para atrás". Estuve buscando y según los hallazgos resulta que esa actualización había estado dando problemas. Además, según los logs de Windows Update ya se había intentado instalar bastantes veces. Por lo que decidí pasar a la siguiente tarea: revisar el disco duro.

Como en cada arranque seguía pidiendo pasar el chequeo, quise forzarlo yo. Como no recuerdo todas las opciones las opciones que puse, puedo enumerar:
  • Desde Windows arrancado
  • Desde el USB
  • Arrancando Windows: En el que se quedaba en el 4% durante aproximadamente una hora.
Sobretodo esta última opción, que ya la había visto en algún momento (lo dejaba un poco menos de tiempo) no me terminaba de gustar. Desde el sistema arrancado con el disco duro no terminaba de convencerme y no había resultados que ayudasen. Incluso llegué a dejar la operación una noche y poco a poco se iba mostrando cómo el tiempo para finalizar iba subiendo, llegando a indicar 4 horas y pico para luego terminar a medias. Por lo que decidí hacer otra cosa: sabiendo la marca del disco, buscar en la página de su fabricante y coger la herramienta de validación que ofrece. ¿Quién mejor que el propio fabricante para decirte si el disco está bien o no? Una vez instalada hice dos pasadas: la express y la exhaustiva. El resultado casi se olia: en ambas opciones la herramienta indicaba que había errores en el disco. Sí, soy consciente de que se podría haber intentado arrancar el equipo y haber hecho el scan con el sistema offline.

Por lo tanto, para resumir, tenemos:
  • Un equipo que no ha sido capaz de instalar en varias ocasiones una actualización (¿error de la propia actualización?¿del sistema operativo?¿de hardware?).
  • Un sistema operativo que cada pocos minutos, por no decidir algo menos, se bloquea durante unos segundos
  • Un disco duro que el sistema operativo no es capaz de reparar los sectores de su sistema de ficheros y la herramienta del fabricante indicando errores.
Ante la posibilidad de que el disco duro pudiera romper del todo antes o después, con la consecuente pérdida de datos, hice una operación que no era nueva para mí: clonar ese disco cuanto antes. Con una salvedad: la herramienta de clonado sería otra a la usada habitualmente (dd): ddrescue. (Por si estáis pensando en una clonadora, ahora mismo no dispongo de ninguna. Pero todo se andará, :D ).

Dos pasos: físico y lógico.

El físico: comprar un disco duro nuevo de, como mínimo, el tamaño original del disco. Incluso de la marca si es posible. A la vez, adquirir una carcasa para convertir el interno original a USB. Colocar cada uno de los discos en su posición: instalar el disco nuevo en el equipo y el antiguo en la carcasa. La carcasa no se enchufa todavía. Aunque se pueda hacer de la otra forma (clonar y después cambiar), me gusta hacerlo así.

Ahora, el lógico, es decir, lo que hice con software.

Arranqué un Kali y tirando del entorno gráfico que trae por defecto usé un terminal. No sabría decir si ddrescue estaba instalado. Mis primeros intentos de lanzarlo no funcionaron, pero el resultado final es que lo pude usar.

Aquí eché de menos un aparatito que me podía salvar de un posible desastre: un bloqueador de escritura. Resulta que esta operación es delicada porque si te equivocas podrías clonar un disco completamente nuevo (o no, según te estén vendiendo un disco que ya ha sido usado) sobre el importante, perdiendo todos los datos. Lo bueno de ddrescue con respecto a dd es que el primero es capaz de continuar con sectores defectuosos e intentar recuperar sus datos. Sin embargo, dd se puede llegar a parar o, a una mala, si se le indica conv=noerror,sync (lo he tenido que buscar, ¿eh?) continúa si se encontrasen errores, pero no hace el intento de ver si se pueden recuperar (o eso es lo que he entendido).

Como nunca había usado ddrescue busqué la información para ejecutarlo. Una de las cosas que he me ha gustado mucho es que no tienes que preocuparte de si pones el parámetro de origen y destino mal (En dd ¿if era la salida de la lectura o era la entrada de lo que vas a escribir? ¿Lo contrario con of? Te acuerdas durante un tiempo pero luego...):

ddrescue lista_parámetros dicoOrigen discoDestino fichero_log

Así de sencillo. Además, la otra cosa buena que tiene es que al guardar los resultados en un fichero de salida (.log, .txt, .etc) si se parase el proceso podrías continuar más adelante. Y es muy importante, porque puedes hacer distintas pasadas tal y como recomiendan hacer. Consejo que yo seguí.

ddrescue -v -R -n /dev/sdc /dev/sda /root/result_v2.log -f

Por un lado, muy arriesgado mandar la salida a una carpeta virtual. Si algo iba muy, muy mal habría que repetir toda la operación. Pero no había más conexiones USB: 1 para el USB de arranque, 2 para el disco que estábamos clonando.

  • -v: verbose, para mostrar más información
  • -n: para ignorar los errores y no hacer nada con ellos.
  • -R: según pude leer, va de "atrás adelante". Leí que si había problemas el disco era recomendable. Y aquí (https://lists.gnu.org/archive/html/bug-ddrescue/2012-05/msg00006.html) explican más o menos cómo funciona, lo que yo no era consciente era que esta opción ralentizaría el proceso.
  • -f: al detectar que podrías estar machacando información (porque se cree que hay una partición en el destino), te obliga a poner este parámetro, que significa "forzar", como indicando que estás seguro de que quieres continuar.

Poco más de 24 horas después, el proceso terminó con apenas 22 errores y unos 300 KB en errores.

ddrescue -v -R -n
ddrescue -v -R -n

Para intentar recuperar los pocos errores que dio hice una segunda pasada:

ddrescue -v -R -r1 /dev/sdc /dev/sda /root/result_v2.log -f

  • -r1: Todo sea dicho, he visto distintos formatos. El 1 lo he llegado a ver junto a la r, separado, distintos valores: -r 3. En mi caso, seguí esta indicación. En teoría es el número de intentos que tiene que hacer para recuperar ese dato.

Aunque no tengo la foto final, tardó media hora de reloj, aparecieron más errores pero el total ocupaba menos que lo que muestro en la imagen de arriba. Al final, di el disco por clonado y recuperado.

Hasta aquí, después de varios días pegándome con el disco, ya teníamos un disco completamente nuevo con el sistema operativo tal cual estaba cuando lo apagamos, con una actualización pendiente de instalar y el sistema operativo esperando a realizar un checkdisk.

Para no alargar más la historia, sólo resumir que fue coser y cantar: pude arrancar correctamente el sistema, la actualización se instaló sin dar ningún problema y el chkdsk pasó del 4% en tiempo record.

Con lo que he podido contar (seguro que alguna cosa me he dejado en el tintero como, por ejemplo, las distintas veces que creé los puntos de restauración): ¿qué habríais hecho vosotros? ¿Qué herramientas con las contáis o que sabéis hubierais usado para arreglar este equipo?

jueves, 13 de octubre de 2016

Timestamp con TSA con HTTP

Si quisiéramos enviar una request a un timestamp server, ¿Cómo lo harías? Yo conozco una TSA que antes me funcionaba (las pruebas que hacía tiraban) hasta que hace poco me encontré con que ya no tiraba el método empleado. Al menos tengo pruebas realizadas que daban resultado y ahora ya no. ¿Por qué? Porque me ahora me está pidiendo que le envíe los datos por post. [Actualización antes de publicar] Porque aun pudiendo haber funcionado con el método de más abajo, el problema no era que no estuviera llamando por post. Realmente en alguna prueba debí de quitar algún carácter y dejó de funcionar [fin actualización] Si accedemos directamente nos encontramos con:
The GET method is not allowed. Try with POST!
La siguiente pregunta es: ¿Cómo sé qué parámetros tengo que pasasrle si quiero continuar usando curl? Hice lo que todo el mundo haría en su sano juicio: leerse la mitad de la RFC1381. Es cierto que hay muchas cosas que se te escapan hasta que encuentras la sección que dice:
There is no mandatory transport mechanism for TSA messages in this document. The mechanisms described below are optional; additional optional mechanisms may be defined in the future.
Y te enumera las distintas formas. Entre las mencionadas están e-mail, fichero (con extensión .tsq o Time-Stamp query), sockets y el que estaba buscando:  HTTP(S). Pero la información que muestra ya la sabemos, porque lo estábamos usando. Pero a partir de otra búsqueda pude encontrar en Stackoverflow que hablaban de un "navegador" específico para estos menesteres. Por lo tanto, para enviar a una TSA un fichero .tsq hay que usar la herramienta tsget.

En teoría deberíamos de poder acceder a ella directamente porque se espera que esté en el path. Pero en mi caso la encontraba. Ni siquiera probando whereis. Así, con otra búsqueda más, apareció en /usr/lib/ssl/misc/. Además, lo más curioso de todo es que el comando man sí que mostraba el manual.

Ahora que ya la tenemos, nos encontramos con un nuevo bache: esta herramienta está hecha en perl y nos muestra un mensaje de error:
"&WWW::Curl::Easy::global_cleanup called at ./tsget line 196."
Aunque después descubrí que sí que había funcionado con este mensaje, hice una nueva búsqueda en la que me encontré con que se podían instalar dos cosas para eliminar el mensaje:
  • Una librería para curl y openssl: 
    • apt-get install libcurl4-openssl-dev
  • Una librería de perl:
    • perl -MCPAN -e "CPAN::Shell->force(qw(install WWW::Curl::Easy));"
Aunque en una de ellas empezó a pedirme que configurara ciertos parámetros y me ofreció hacer casas automáticamente, primero decidí hacerlo a mano. Pero terminé desistiendo y cancelé el proceso para más tarde repetirlo y permitirle hacerlo automáticamente. También hay que tener en cuenta que es posible que te haga falta instalarlo para cada usuario (lo hice con root y parecía que me también me pedía ejecutar el comando de perl para mi usuario mortal).

Una vez instaladas las cosas y encontrarme con que seguía saliendo el mensaje, pero también obtenía resultados, se puede explicar las distintas formas de llamar a la TSA. 

¿Qué estaba haciendo antes y cómo se puede hacer con el nuevo comando?

Antes estaba ejecutando esta línea, pero sin los caracteres en negrita (con ellos funciona, sin ellos no):

cat miFich.tsq > curl -s -S -H "Content-Type: application/timestamp-query" --data-binary @- http://tss.accv.es:8318/tsa -o result.tsr

Con tsget se podría ejecutar de esta forma:

./tsget -h http://tss.accv.es:8318/ts -o /ruta/destino/fich.tsr /ruta/fichero/query.tsq

Ahora si se quiere se podría añadir la ruta de esta herramienta al $PATH para no depender de tener que poner la ruta completa de los ficheros de entrada/salida. Para eso tendremos que editar el fichero /etc/profile. Para mi usuario mortal funciona, que es lo importante.

¿Qué podemos contar de todo esto?

  • Que para estas cosas nos tenemos que acordar de mirar todos los comandos letra a letra, que a veces leemos lo que queremos, no lo que realmente hay escrito.
  • Que para trabajar con una agencia de sellado de tiempo, además de curl tenemos tsget.
  • Que si una cosa no funciona, siempre puedes terminar buscando una posible solución en el RFC del tema en cuestión, si es que existe. En mi caso me lo leí hasta la mitad y como mínimo alguna cosa curiosa aprendes aunque no consigas solucionar el problema. 

martes, 4 de octubre de 2016

Crónica Navaja Negra 2016

Un año más he podido asistir al evento Navaja Negra. Con la única diferencia de que por un buen compromiso personal sólo asistí los dos primeros días.

Otro cambio que ha habido este año ha sido la salida que se produjo hace unos meses de algunos componentes de la organización, a los que se les ha echado mucho de menos. Además, otro cambio que hemos podido ver es que al mismo tiempo que se estaban realizando los talleres se estaban dando algunas charlas. Yo me terminé decantando por estas últimas porque para los talleres se suponía que hacía falta un material que con el que no terminé por hacerme. En mi caso ya les comenté que prefería que no hubiese solapamiento, pero es el típico tema del que hay discrepancias y no se puede contentar a todo el mundo.

Para llegar a Albacete fui con Julian (@Txambe). Una vez hubimos llegado y nos asentamos, nos preparamos para las ponencias en la Universidad de Castilla la Mancha:

Navaja Negra 2016 - Universidad de Castilla la Mancha, Albacete
Navaja Negra 2016 - Universidad de Castilla la Mancha, Albacete
Lo primero que se hizo en la sala fue el inicio de la CON por parte del presidente de la organización Rubén Ródenas (@Eldoctorbugs) presentando lo que podíamos esperar este año, además de indicarnos cómo funcionaría el CTF, los patrocinadores, wellcome pack, etc.

Inicio Navaja Negra 2016
Inicio Navaja Negra 2016
En la mesa también estaba el director de la escuela y Juan Carlos, que era el representante del Centro de Apoyo a Empresas. Así, después de la inauguración, fuimos a desayunar con el magnífico cátering que nos pusieron.

La primera ponencia la presentaba Eduardo Arriols (@_Hykeos), "Como Pedro por su Smart-Building", en el que nos hablaba de los problemas que se podrían causar a los servicios de cuidades, bancos, edificios, etc si los paneles de control que gestionan sus servicios (la luz, temperatura, etc) estuviesen accesibles por Internet.
Navaja Negra 2016 - Eduardo Arriols - Como Pedro por su Smart-Building
Eduardo Arriols - Como Pedro por su Smart-Building
Si la domótica está centralizada podemos hablar de un sistema: Building Management System. Nos habló de las distintas "personas" involucradas en sus desarrollo: los fabricantes y los implantadores (los que compran los cacharros a los fabricantes y lo instalan). Entre otras vulnerabilidades están las típicas web: usuarios por defecto, SQL Injections, contraseñas fácilmente descifrables (hizo reversing de una librería que usaba uno de los sistemas analizados). Usando Shodan o ZoomEye pudo encontrar muchos gestores de este tipo de sistemas abiertos al público. Para finalizar nos enseñó algunas demos.

Para la siguiente ponencia, Daniel Vaca, "Encontrando malware en Android like a n00b".
Navaja Negra 2016 - Daniel Vaca - Encontrando malware en Android
Daniel Vaca - Encontrando malware en Android
 En su charla nos describía cómo funciona Koodous (@koodous_project), una plataforma colaborativa que permite subir las APKs de las aplicaciones de Android y la comunidad las analiza con el fin de buscar malware en ellas, entre otros métodos con análisis estático. Aún así, también usan otros sistemas como Yara (standar análisis de malware identificado por patrones), de los cuales nos mostró algunos ejemplos. Nos hizo una demo de la versión web. Nos nombró dos herramientas que no estaría de más tenerlas, como mínimo, escritas aquí: ApkTool y QARK (Quick Android Review Kit).

Para la siguiente charla, Eva Suarez (@EvaSuarez22) y Manuel García (@Hypnito), con su "Show me the dork",
Navaja Negra 2016 - Eva Suarez y Manuel García - Show me the dork
Eva Suarez y Manuel García - Show me the dork
 Nos presentaban una herramienta que a partir de dorks conocidos permitía automatizar el uso de los mismos para saber si estás afectado por los mismos. Nos explicaron cómo lo idearon y lo desarrollaron, además de los distintos problemas que se iban encontrando (por ejemplo, el captcha de Google) con el fin de que la herramienta fallara lo menos posible. Entre otras herramientas utilizadas tiran de Sinfonier para hacer las reglas que permitirá lanzar las consultas (los dorks) a Google. Además se guardan estadísticas para ir mejorando los resultados. Nos hicieron una demo y se permite probar la herramienta a través del correo que se ve en la foto con un plan de betatester.

Al final su charla pudimos comer allí mismo, ya que como otros años, nos llevaron la comida a la universidad.

Comida primera día Navaja Negra 2016
Comida primera día Navaja Negra 2016

Después de comer pudimos asistir a la ponencia de Rafael Pedrera (@RafaBlackMagic), "Ciberseguridad en infraestructuras críticas".

Navaja Negra 2016 - Rafael Pedrera - Ciberseguridad en infraestructuras críticas
Rafael Pedrera - Ciberseguridad en infraestructuras críticas
Nos contó cómo funcionan, además de hablarnos de las fases de compromiso, ejemplos de ciberataques, mencionó la Estrategia de CiberSeguridad Nacional, los SoC (Security Operation System), los CERTs... De los cuales nombró dos: El CCN-CERT y el CERTSI_ (Perteneciente al INCIBE). Definió qué son las infraestructuras críticas, habló de las investigaciones de ciberterrorismo y ciberdelincuencia o los problemas ya conocidos de los SQL Injection o los pares de usuarios y contraseñas archiconocidos que siempre aparecen en un montón de lugares críticos.

La siguiente ponencia, que era la patrocinada (otra de las típicas discusiones: si no se patrocina, la entrada se hace inasumible. Los hay que no quieren nada patrocinado. Yo creo que media hora o una hora por jornada patrocinada no hace daño). En este caso, Alberto Ruiz (@Alberto_Sophos), nos presentaba "Next generation endpoint: El retorno del rey".
Navaja Negra 2016 - Alberto Ruiz - Next generation endpoint: El retorno del rey
Alberto Ruiz - Next generation endpoint: El retorno del rey
Nos contó la historia de los antivirus y su evolución. Las distintas modas en la venta de estas aplicaciones. Propone no sólo funcionar por firmas, sino tener en cuenta los distintos comportamientos del sistema, ya que al final los distintos malwares siempre terminan actuando de la misma forma. Y si se puede centralizar en a sistemas, como por ejemplo SIEMs, mucho más fácil de gestionar (siempre que sea una empresa, en un entorno domestico...).


Antes de la merienda, Ulises Quesada, del Cuerpo Nacional de Policía, del Grupo de delitos económicos y tecnológicos, nos hacía una pequeña comparación de la realidad vs ficción (en películas).

Navaja Negra 2016 - Ulises Quesada - Itinerario por el Cibercrimen
Ulises Quesada - Itinerario por el Cibercrimen
Nos hablaba de los distintos delitos: al patrimonio, intimidad, calumnias, malware bancario... Mostraba la comparación de a más derechos menos seguridad. Explicaba las características de las estafas y ponía algunos ejemplos de las mismas: es sencillo de ejecutar, no hace falta estar muy cualificado para llevarlas a cabo, lucro inmediato, el anonimato ayuda a no tener tanta conciencia con la víctima, menos riesgo...

Después de la merienda, Pepelux (@pepeluxx) y Luis Jurado (@streaming10), Pepelux y Luis Jurado "1 año de la LECRIM: bugs y exploits" nos contaron algunas formas de bypassear una de las normas de la LECRIM.
Navaja Negra 2016 - Pepelux y Luis Jurado - 1 año de la LECRIM: bugs y exploits
Pepelux y Luis Jurado - 1 año de la LECRIM: bugs y exploits

 Primero Luis nos puso en antecedentes legales: nos habló de algunos casos como los Panamá Papers y sus consecuencias: económicas, reputación, anonimato... Posibles causas: insiders, CSMs desactualizados, pivoting... Las formas en las que se debería de guardar la información o cómo mantener los datos privilegiados a buen recaudo: controles de acceso a la información, formación, etc. Sobretodo cuando se trata de los derechos de los clientes de los abogados. Así, nos contó cómo trabaja en ciertas circunstancias en las que se puede resumir todo como: modo paranoico (llamadas por VoIP con un servidor propio, portátil exclusivo para ese caso, entre otros). Para no extender más su parte: nos habló del derecho a hacer una llamada cuando nos detienen. ¿Qué pasaría si lo ejerciéramos llamando a un teléfono que controlamos, en el que atiende una centralita Asterisk y que al recibir la llamada ejecute comandos del sistema como por ejemplo el de borrar ficheros (rm ´-rf)? Esa fue la demo que nos hizo Pepelux.

En la siguiente charla, Ruth Sala (@ruth_legal) y Selva María Orejón (@selvaorejon) dieron su ponencia: "Cazando al cazador, investigaciones paralelas".
Navaja Negra 2016 - Ruth Sala y Selva María Orejón - Cazando al cazador, investigaciones paralelas
Ruth Sala y Selva María Orejón - Cazando al cazador, investigaciones paralelas
Su charla versaba sobre cómo estuvieron investigando el caso de una Youtuber que se vio acosada por una antigua pareja, también Youtuber, hasta el punto de que empezaron a realizar la investigación como un caso de violencia de género. La descripción de cómo tuvieron que actuar y recolectar las pruebas necesarias para poder judicializar el caso, encontrando otra víctima más y las horas y el tiempo de dedicación para poder llevar el caso. Con la descripción que daban se veía sobremanera la desesperación y el esfuerzo que llevaron a cabo en el caso y los distintos problemas que encontraron por el camino. 

Para finalizar el primer tuvimos la mesa redonda "Estado del arte en ciberseguridad" (de la cual, la única foto que tengo no ha quedado bien). Se estuvo hablando de alguna certificación (como la OSCP, que la dan los de Kali) y la última parte se estuvo hablando bastante de legal.

Después de esta mesa redonda, se hicieron los sorteos, en los que muchos agraciados perdieron el premio por no estar presentes. 

Ya después de cenar, nos habilitaron una sala en el Hotel Universidad para poder montar nuestros propios mini-talleres. 

Al día siguiente, viernes, también tuvimos unas charlas muy buenas. 

La primera de todas la dio Ernesto Sánchez (@ernesto_xload), y su "BadUSB, Vectores de ataque y Contramedidas".

Navaja Negra 2016 - Ernesto Sánchez - BadUSB, Vectores de ataque y contramedidas
Ernesto Sánchez - BadUSB, Vectores de ataque y contramedidas
Comenzó explicando qué es y cómo nos podíamos proteger. Habló de los antecedentes como los virus de sector de arranque para pasar por el famoso autorun de los CDs y los USBs. Además, diseccionó un USB mostrándonos su anatomía. Uno de los cambios mostrados fue el firmware de un pincho con el fin de que se hiciera pasar por un teclado. De los distintos dispositivos mostrados cuyo fin es el de ejecutar funciones como si de otro dispositivo USB se tratase estaban la RubberDucky, Telsi/Tensi (no lo llegué a ver del todo bien), Phoenix Ovipositor (que era el que ha montado la empresa de Ernesto), etc. Algunas posibles protecciones, por ejemplo, para los móviles y que no nos roben datos: ShielDucky o Patitohunter (una herramienta en Python). Después nos hizo unas cuantas demos. 

La siguiente ponencia era la de Pablo González (@pablogonzalezpe) y Rafael Sánchez (@R_a_ff_a_e_ll_o) nos contaron la técnica de "hacking devices around the world: Playing gallinita ciega".
Navaja Negra 2016 - Pablo González y Rafael Sánchez - Hacking devices around the world: Playing gallinita ciega
Pablo González y Rafael Sánchez - Hacking devices around the world
Empezaron contando qué es "jugar a gallinita ciega": Buscar una dirección IP al azar y ver qué hay detrás. A través de un estudio de las motivaciones de los atacantes el mayor porcentaje es la oportunidad (como está ahí abierto, entonces, puedo). El resto de las razones: mostrar que uno sabe mucho, dinero, aprendizaje o psicopatía (romper por romper). También nos hablaron de los RIRs, unos organismos que se encargan de repartir las direcciones IP, fuente de datos para empezar a buscar información. Uno de los RIRs oficiales es el APNIC. También nos definieron los Sistemas Autónomos (AS). No se olvidaron de incluir en las herramientas comentadas Shodan, Censys, MrLooquer, scan.io o Zmap. Ni tampoco de los sistemas que usan a la vez IPv4 e IPv6, llamados dual shocks. Para finalizar hablaron de la seguridad por oscuridad: "como parece que no me descubren estoy seguro". Una de las demos que nos hicieron fueron muestras de dispositivos que tenían abiertos los puertos para acceder a pantallas X11. 

Después de esta charla pudimos tomarnos un buen desayuno.

Así, al finalizar el desayuno, Nicolas Barbovitch y la "seguridad de sistemas de control de acceso basados en lectores ópticos" nos describía los diferentes sistemas de gestión de identidades con códigos de barras.
Navaja Negra 2016 - Nicholas Barbovitch - Seguridad de sistemas de control de acceso basados en lectores ópticos
Nicholas Barbovitch - Seguridad de sistemas de control de acceso basados en lectores ópticos
Empezó desgranando las diferentes familias de códigos de barras y el significado de cada una de sus secciones. Fue poniendo distintos ejemplos de los usos: parkings varios (que pasaron de usar bandas magnéticas a los códigos de barras), el boarding card de los aviones para entrar en salas VIP o incluso la pequeña posibilidad de tener otros dato no verídicos en ella (reecalcar la sección con el código CRS, un código del que se podría obtener más información de la deseada). Existe otra sección con un valor que permite que al validar el ticket suene un número determinado de pitidos, y según estos te cachean o no en EE.UU (por lo que lo de cacheos aleatorios...). Su solución es usar cifrado para que no se pueda manipular la información, tal y como hacen en Alemania con el estándar de la Unión Europea ERA. Los otros ejemplos posibles son, por ejemplo, los códigos usados en fidelización y ofertas, igualmente manipulables. 

Ricardo Rodríguez (), con su exposición "Evolution and Characterization of POS RAM Scrapping Malware", donde POS significa Point of Sales: Punto de Venta, o comúnmente conocido como TPV.
Navaja Negra 2016 - Ricardo Rodríguez - Evolution and Characteriization of PoS RAM Scrapping Malware
Ricardo Rodríguez - Evolution of PoS RAM Scrapping Malware
Se habló de los servicios financieros y las tarjetas de crédito para pagar. Se comentó que la mayoría de los TPVs tienen Windows y si están infectados sería una fuente muy buena para obtener los datos de las tarjetas. Hizo un repaso a la evolución y las características: Funciones, procesos, filtración de datos... ¿Dónde está el dato?: en memoria, en través de la red, en la misma aplicación utilizada... Y para obtenerlos: físicamente, de los tracks de las tarjetas (me acordé de Aladdin y la ponencia que nos dio en NoConName), del chip, del NFC... Contó las características del malware y cómo lo analizó. Después nos hizo una demo.

Después de otra suculenta comida, Jordi Ubach (@jubachm) y con su "¿A qué piso va?" pudimos ver el estado actual de la seguridad industrial. 
Navaja Negra 2016 - Jordi Ubach - ¿A qué piso va?
Jordi Ubach - ¿A qué piso va?
A continuación nos habló de varias marcas como objetivos: Om-Ron, Allem-bradley, Siemens, SMA, XZeres... Hizo incapie en que sus objetivos no eran infraestructuras críticas ni dispositivos asociados al IoT (Internet of Things). ¿Qué dispositivos enocntró? Maquinaria industrial, generadores de energía, aerogeneradores, climatizadores, contadores de luz (los que nos están instalando las compañias: conocidos como smartmeters o IIOT), riegos, frío industrial, lavaderos de coches... Analizó los puertos y también encontró comunicación en texto plano, protocolos estándares, conexiones remotas con software propietario... Y las vulnerabilidades típicas: SQLi, XSS, DoS. Hizo unas cuantas demos entre las que se encontraba un ascensor. 

A continuación otra charla patrocinada. En esta ocasión por CICE (@cicemadrid) presentado por Juan de Dios (@zabachenet) y  Daniel Hidalgo (@dhidalgor) en la que nos hablaron de sus inicios de cómo cuando empezaron eran unos pioneros. 
Navaja Negra 2016 - Juan de Dios y Daniel Hidalgo - Academia CICE
Juan de Dios y Daniel Hidalgo - Academia CICE
De cómo una academia en la que forman a profesionales en el área de imagen y sonido pueden ayudar en las tareas forense de la policía, formándolos para poder reconstruir escenarios, entre otras áreas. Así, nos deleitaron con una demo de un vídeo con fragmentos de los que han montado sus alumnos. 

Para la siguiente charla, Miguel Martín nos habló de la "prevención de ataques ROP mediante instrumentación dinámica".
Navaja Negra 2016 - Miguel Martin - Prevención de ataques ROP mediante instrumentación dinámica"
Miguel Martin - Prevención de ataques ROP...
Empezó recordando qué es un desbordamiento de buffer (sobrepasar la pila junto a la inyección de código). Vimos qué era un ROP y un JOP (Jump Ordered ¿Program?). Pude coger términos como "cambio de flujo indirecto (CALL y JMP basados en memoria) además de mostrar distintas defensas. Para finalizar nos habló de la herramienta PROPID (Prevención ROP con Instrumentación Directa). Lo siento mucho, pero el reversing me cuesta mucho y creo que de esta charla no pillé todo lo esperado. 

Y para finalizar, después de la merienda, pude asistir a mi última charla de las Navajas Negras 2016.

Daniel Medianerio (@dmedianero) dio a conocer "From root to the cipher: new TTPs in Android Malware".
Navaja Negra 2016 - Daniel Medianero - From root to the cipher: new TTPs in Android Malware
Daniel Medianero - New TTPs in Android Malware
Nos habló del malware en Android desde 2009 llegando a los actuales, contando uno a uno cómo funcionaban y funcionan. Algunos ejemplos que dio fueron: Hummingbad, Fakebank, GodLess, Twitoor, Gugi y Tordow. La pena es que no llegué a apuntar sus características. 

Y al finaliza su ponencia me estaba esperando el tren para un viaje familiar ineludible. Aún así, el tiempo que pude pasar estuvo genial. 

Como de costumbre, el año que viene espero volver. ¡¡Hasta la próxima!!

sábado, 6 de agosto de 2016

Cómo descargar APKs de Google Play

Lo siento mucho por esta mini-entrada, pero tenía necesidad de descargar una aplicación desde Google Play al ordenador.

Las apps de Android tienen formato APK y con un poco de mañana se pueden descargar al disco duro para analizarlas. Sabía que había uno de los blogs que sigo donde ya lo contaron y volviendo a buscar lo encontré.

Desde Estación Informática lo cuentan.

El servicio se llama APK Downloader, y pertenece a Evozi.com.

Te pide la URL directa de la aplicación en el market de Google.

APK Downloader - Evonzi.com
APK Downloader - Evonzi.com

Al introducir la URL y pulsar el botón Generate Download Link. ¡Ojo! Aquí os pueden colar anuncios, cookies, etc. En mi caso he tenido que hacer la operación dos veces para la primera vez. Así, el resultado que devuelve con esta entrada es:

ApkDownloader - Descargar APK
ApkDownloader - Descargar APK
Lo primero que voy a hacer va a ser poner en uno de los laterales esta herramienta web para tenerla a mano.

lunes, 23 de mayo de 2016

SPA3102 y los códigos telefónicos I: rsyslog

Este post llevaba en la recámara mucho tiempo. De hecho, me lo he encontrado cuando estaba buscando cómo hacer los logs del SPA3102: tenía que repetir los pasos y no lo encontraba con Google, sabiendo que ya lo había hecho antes. Intentaré completarlo, porque esto lo dejé a medias hace mucho tiempo y ya no me urge la necesidad que tenía.

--

Esta es otra entrada más sobre el sistema PBX y los códigos telefónicos.

Por poner un ejemplo, cuando estás creando unos feature codes habrá que probarlos de alguna forma. En mi caso solía ser tirando del teléfono que tengo puesto en el SPA3102, que para eso lo compré. El problema que me he encontrado es que a veces me funciona, después me encuentro con que no... Sigue sin funcionar... Más adelante sí... Y eso no puede ser. Por lo tanto, como el trasto tiene la posibilidad de conectarse a un servidor de logs, voy a configurar mi RasPBX para que haga el log y después, si no se entiende muy bien (ya lo digo yo, que lo acabo de probar: es un poco críptico), se busca qué significa.  

Si buscamos manuales, nos encontraremos con que te hablan del sistema syslogd. Pero resulta que el que viene instalado es rsyslog. Si por algún casual tuvieses syslogd, este manual parece que tiene buena pinta. Al menos en lo que a este tema se refiere. En nuestro caso, tocará buscar el específico para rsyslog. Aquí he encontrado uno, que nos dice que hagamos más o menos lo siguiente:

En /etc/rsyslog.conf:
  • Descomentar:
    • $ModLoad imudp
    • $UDPServerRun 514
  • Además, vamos a permitir o tener descomentada (más abajo te lo ofrece) la linea que dice $IncludeConfig /etc /rsyslog.d/*.conf
En /etc/rsyslog.d/spa3102.conf vamos a poner lo siguiente:

:FROMHOST-IP, isequal, "_direccion_ip_SPA3102_" /var/log/spa3102.log

Las comillas son obligatorias. 

Vamos a reiniciar el servicio con

/etc/init.d/rsyslog restart

Y esta parte ya estaría. Si no se crease el fichero indicado, lo mejor es buscar qué indica el sistema en /var/log/syslog.

Ahora hay que configurar el trasto de Cisco/Linsys. 

Iremos al menú Voice, submenú System. En los campos Syslog Server y Debug Server pondremos la dirección ip de nuestra PBX. El combo Debug Level lo pondremos a 3 (aunque en alguno de los manuales dicen 2, yo quiero la máxima información):

SPA3102 - Configurando el syslog y el debug level
SPA3102 - Configurando el syslog y el debug level
Guardamos y haremos una prueba con algo que sabemos que funciona desde el teléfono. Como por ejemplo, una llamada a la extensión de un softphone que tengas instalado en un ordenador. O, un código que debería de funcionar. Por ejemplo, en mi caso, el feature code *69 funciona desde el teléfono. Te indica la última llamada entrante y te ofrece devolverla. Pero, si quieres que te diga la hora, que por defecto lo hace con el código *60, nos comunica. Pero, desde nuestro softphone sí que funciona. O si queremos probar el que configuramos el otro día, podremos ver que nos sucede lo mismo. 

Está claro que hay algo que no consigo que este aparato (el Linksys SPA3102) se le está diciendo que no va a poder enviarlos (y que a estas alturas sigo sin controlar del todo). Esto es lo que vamos a descubrir. Tal y como hemos configurado más arriba, miraremos los datos en el fichero /var/log/spa3102.log

Una vez que he estado probando un poco con los los códigos que funcionan y los que no, he podido ver que:
  • [0]Off hook: terminal "descolgado"
  • [0]On hook: terminal "colgado"
Es decir, el primero es el aviso de "se ha descolgado el teléfono" y el segundo "han colgado el teléfono". Volviendo a lanzar el comando, sólo aparecen estas dos líneas. ¿Me dejaría algo el otro día al quitar los códigos que pudieran interferir? No sé, porque si los hubiese eliminado por completo no me dejaría hacer nada, y algunos sí que me los envía. 

Viendo que esto no tira, me he encontrado con que la pestaña Line 1 tiene una sección con el combo "SIP Debug Option". Lo voy a activar a full y reiniciaré el aparato.

--

La selección de SIP Debug Option permite visualizar en el log, además de los demás valores que ya se muestran de por sí, algunos mensajes SIP con los que estaba trabajando el terminal 3102 en cuestión.

En el día de hoy: el error que me daba de no funcionar el código *60 ya no se produce. Al menos hemos podido recuperar la forma de registrar los resultados internos del aparato. Si más adelante tengo que seguir trabajando con estos códigos, seguro que os lo cuento por aquí. 

miércoles, 11 de mayo de 2016

Facebook y renovar la contraseña

Hace poco a un familiar le llegó un correo en el que le indicaban que se había intentado cambiar su contraseña de Facebook. Era rarísimo. 

Lo primero que se hizo fue mirar de dónde provenía el correo. El dominio:  @facebookmail.com. Como se dio el dominio por válido, miró el contenido de los dos correos y había un enlace que indicaba que si no había solicitado el cambio de password que se hiciera click en éste. Y así se hizo. ¿Resultado? Una página cuya URL indicaba que era de Facebook avisando de que se había cancelado el reseteo. 

Más adelante se hicieron más averiguaciones: ¿Era realmente el domino @facebookmail.com de la empresa? Según las entradas de Google, algunas entradas indicaban que era un domimio para scam (Ej01, Ej02)y otras, perteneciente al foro de la compañía, que sí era legítimo (Ej01, Ej02 ). 

Una búsqueda en algún WhoIs me ha ayudado a saber más sobre el dominio del que estamos cuestionando su pertenencia. Si hacemos una comparación del perteneciente a facebook.com con respecto a facebookmail.com podemos constatar de que ambos dominios tienen los mismos datos. 

Aún así, podríamos decir que los datos de contacto entregados del segundo dominio podrían haber sido copipasteados del primero. ¿Más cosas que nos pudieran dar pistas de que es un correo falso? Aunque en ocasiones falle, Google suele atinar y descubrir que se está intentando suplantar la identidad de la empresa. Además, he hecho otra validación más: he mirado las cabeceras del correo en cuestión. La primera cosa que he pensado en mirar ha sido el resultado de la comprobación SPF: 

Received-SPF: pass (google.com: domain of password[valor_censurado]@facebookmail.com designates 66.220.155.153 as permitted sender) client-ip=66.220.155.153

Tenemos un pass. Aún así, me gustaría comprobar a quién pertenece esa dirección IP, 66.220.155.153. Una vez más, haciendo uso de Google encuentro un servicio, IP Location Finder, nos devuelve:

Encontrando Facebookmail con IP Location Finder
Encontrando Facebookmail con IP Location Finder
Por lo tanto, y siempre teniendo en cuenta estos datos, se puede afirmar que el correo se ha mandado desde la localización de los servidores de Facebook. 

Aunque me he centrado en estos valores también se puede tener en cuenta que en las cabeceras aparecen más valores como:
  • Comprobación DKIM:  DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=facebookmail.com;
  • Received del dominio original: Received: from facebook.com
Si bien algunos de estos son spoofeables estos datos me hacen pensar que el correo era legítimo. Además, estos datos se han realizado desde otro equipo distinto a aquel desde el que abrieron el correo sospechoso. 

domingo, 8 de mayo de 2016

EastMadHack 2016

Estos dos últimos sábados hemos tenido un evento muy especial en Arganda del Rey. Ha sido la primera edición de la EastMadHack. Dos sábados en los que durante todo el día se han realizado unas ponencias muy interesantes.

Esta primera edición la vi como el inicio que supongo que todas han tenido: un petit comité que en futuro llegará a alcanzar cientos de asistentes. En este caso podíamos contar unos veintipocos asistentes a la vez, dado que en algún momento algunos compañeros tuvieron que partir mientras que otros llegábamos. En mi caso, no pude asistir al comienzo del mismo, tal y como he hecho con otros (en los que casi siempre he sido de los top 10 en llegar). Aún así, he disfrutado mucho.

Dada la configuración de cómo estaban organizadas las charlas y volviendo a mencionar la confluencia que teníamos en las dos salas en las que hicieron las charlas (un salón de un bar restaurante el primer día, un aula de la Casa de la Juventud de Arganda la segunda sesión) permitía hacer preguntas en mitad de las charlas en vez de hacer una sección de preguntas al final de cada una de éstas. Al menos en la mayoría de las ponencias. Incluso alguno de los ponentes lo promovía. Al final de cada charla teníamos un sorteo de un libro, ya fuera de 0xWord o de MundoHacker (editorial Ra-Ma), del que me entregaron uno de esta última editorial sobre Protección de Datos .

Como de costumbre en los eventos a los que he asistido, la organización ha estado muy encima de que todo saliera bien. Incluso aún teniendo un lugar planificado para la segunda sesión, hicieron un cambio de localización a tres días de empezar para que los que fuéramos en coche pudiéramos tener un lugar fácil para aparcar sin pagar (quitándonos el problema de las zonas azules y verdes).

Desde EastMadHack se han comprometido a promover formaciones, por lo que no será descartable que dentro de poco tengamos noticias suyas al respecto.

Como ya he comentado, no pude estar desde el principio en ambas sesiones.

El primer día pudimos escuchar temáticas sobre criptografía en la Guerra Civil, Jupyter (para desarrollar en python), peritajes forenses (de la que se pudieron haceer muchas preguntas e intervenciones), cómo funcionan los antivirus en general y algo más particular para ESET o como hacer el reconocimiento como inicio para un pentest (en este último junto con un pequeño hack para el portátil de Kao, quien dio esta última charla).

Para el segundo día llegué cuando Angelucho empezaba su charla sobre "el eslabón más débil en Internet es el usuario", hacer búsqueda y análisis de big data en Twitter, O los distintos ataques a SSL/TLS, y la última de todas en las que se describía cómo funciona el entorno laboral de un desarrollador.

Soy consciente de que en otros eventos explico más. Espero que para la siguiente edición pueda hacerlo mejor.

No se puede olvidar las comidas, la cual se pudo compartir con la organización.

Si te gustan estos eventos, no te puedes perder las siguientes ediciones.