domingo, 3 de noviembre de 2019

Acceder a tarjeta SD desde máquina virtual

Una pequeña chuleta porque me hará falta más adelante (y seguro que a alguno de vosotros os ha pasado): intentar acceder a la tarjeta SD insertada en el lector integrado del portátil y no conseguir, ni siquiera, que la detecte.

Mi problema era que esta tarjeta SD tenía un sistema de ficheros ext4 y de las muchas formas de hacer el cambio esta era la que más seguridad me daba.

He encontrado varias fuentes que cuentan prácticamente lo mismo (entre otras, una pregunta en superuser.com).

Todo lo haremos con permisos elevados de administrador.

Desde un cmd ejecutamos:

wmic diskdrive list brief

Que nos debería devolver algo parecido a:

c:\> wmic diskdrive list brief

Caption             DeviceID            Model               Partitions  Size
SDHC Card           \\.\PHYSICALDRIVE1  SDHC Card           2           32004564480
TOSHIBA MQ01ABF050  \\.\PHYSICALDRIVE0  TOSHIBA MQ01ABF050  4           500105249280

A partir de estos datos usaremos el DeviceID. En nuestro caso será "\\.\PHYSICALDRIVE1". Aquí usaremos la herramienta de VirtualBox vbmanage:

C:\Program Files\Oracle\VirtualBox> VBoxManage internalcommands createrawvmdk -filename "%carpetaDestino%\sdcard.vmdk" -rawdisk "\\.\PHYSICALDRIVE1"

No genera realmente un disco duro virtual sino un enlace. No me ha pasado pero no quitaría la tarjeta hasta que no terminemos todo el proceso. No sé las consecuencias pero algo podría fallar. En mi caso para una tarjeta de 32GB no ha tardado casi nada en generar el fichero.

Ahora sólo quedaría ir a la máquina virtual que queremos utilizar (o crear una nueva) e incluir este disco virtual entre los que necesitemos. Para mí era necesario cambiar algunos datos que en Windows no podía, por lo que he tenido que crear una máquina virtual y además de añadir este "disco" de apenas unos pocos megas (por no decir KBs) la ISO con la que arrancarla. Eso sí: le ha costado arrancar más de lo que normalmente empiezan a arrancar las otras.

Recuerda: absolutamente todo lo tendrías que hacer con permisos de administrador (incluyendo la máquina virtual).

Espero que sea de utilidad si os veis en la necesidad.


martes, 8 de octubre de 2019

Clave de licencia del Windows

Buscando cómo solucionar un problemilla con un Windows no sé cómo he llegado a este comando que, en teoría, muestra la clave de licencia del Windows que estamos utiliznado:

wmic path SoftwareLicensingService get OA3xOriginalProductKey

Al ejecutarlo desde un cmd no me ha hecho falta elevar privilegios (y eso que mi usuario es mortal). Al menos sí que devuelve una cadena que tiene la estructura de las claves de licencias. Que sea realmente la que se está utilizando... Eso ya no lo puedo asegurar. Pero como chuleta de cómo se podría sacar de llegar a serlo viene muy, pero que muy bien.

Espero que si funciona también os sea de utilidad a vosotros.

sábado, 5 de octubre de 2019

Crónica Jornada III - Navaja Negra 2019

Hoy hemos tenido el último día de las Navajas Negras 2019.

Hemos empezado con Amador Aparicio (@amapada) y Ruth Sala (@ruth_legal).

Navaja Negra 2019 - Amador Aparicio
Navaja Negra 2019 - Amador Aparicio
Amador nos ha contado cómo un amigo suyo se encontró con que un enlace que le envió un servicio VTC a la hora de pedir un viaje le llevaba a encontrar información suya y más de la deseada. El problema viene en que dicho enlace no caduca por lo que es posible visualizar el contenido una vez finalizado el viaje. Además no se controla que la persona que accede a dicho enlace es la destinataria dando acceso a cualquiera al mismo. Además nos ha contado cómo demostró una hipótesis suya en la que los enlaces seguían un patrón determinado. Incluso encontró que alguien ya había estado trabajando en un script que permite localizar los enlaces válidos. De dichos enlaces, entre otros datos, aparecen nombres propios, el modelo y matrícula del vehículo empleado para el viaje, coordenadas y horas de origen y destino del viaje. Mientras Ruth ha puesto de manifiesto la problemática legal de este comportamiento y la estructura legal de la empresa la cual tiene diversas sedes con sus propios NIFs. Esto hace que sea más difícil denunciar a la empresa.

Después Santiago Hernández (@santiagohramos) nos ha hablado de detección de amenazas con imágenes.

Navaja Negra 2019 - Santiago Hernández
Navaja Negra 2019 - Santiago Hernández
Nos ha dado unas pequeñas pinceladas de las clasificaciones de la IA: (semi-)supervisado,no supervisado y reforzado. Ha contado algunos problemas del machine learning. Y ya puestos en harina tenemos el concepto de "malware images": convertir malware en imágenes. La ventaja de reconocer patrones de red o binarios en imágenes es que el reconocimiento de fotografías (por no volver a usar 'imágenes') está muy avanzado. Ha hecho una demo en la que se puede ver que las imágenes, al final, se ven como las antiguas pantallas cuando tenían nieve muy fina. Ha explicado tanto las ventajas como los inconvenientes.

Aquí hicimos el desayuno.

La última ponencia la dio Raúl Siles (@dinosec).

Navaja Negra 2019 - Raúl Siles
Navaja Negra 2019 - Raúl Siles
En su charla nos ha hablado de WPA3. Qué hacen los fabricantes ahora mismo ya que lleva muy poco tiempo. Según las distintas configuraciones que ofrece (personal/SAE, Enterprise, Enhanced Open/OWE, Easy connect/DPP) algunas veces un dispositivo cliente no termina de actuar como marca la especificación. En esos escenarios que nos ha mostrado ha hecho alguna demo en la que ha conseguido, por ejemplo, sacar al cliente de la red cuando realmente una de las partes del diseño está ideada precisamente para evitarlo. Nos ha desgranado características internas de cada una de estas configuraciones.

Al finalizar la charla de WPA3 Raúl ha pasado a hablar del hackathon que organizan en el Cybercamp 2019 animándonos a apuntarnos o incluso si no podemos y tenemos alguna idea que se quiere que se lleve a cabo presentarla y seguro que encuentran a alguien que esté dispuesto a montarla en el evento.

Y ya para finalizar se han entregado los premios del CTF y han hecho un gran sorteo con merchandising de la organización y algunos libros.

Lo siguiente ha sido la comida que nos han dado en el campus.

Me lo he vuelto a pasar muy bien y todo depende de cómo me vaya el año que viene pero espero poder a tener la rutina de visitarlo.

Crónica jornada II - Navaja Negra 2019

La segunda jornada de Navaja Negra ha sido tan intensa como la primera.

Hoy he tenido la posibilidad de hablar un rato con Longinos, que ayer tanto él como Ivan nos pudimos saludar tan solo unos segundos. Además, también se ha acercado a saludarme Patxi, de la Ertzaintza.

La primera charla de hoy la ha dado Carlos Hernández (@k4rliky).

Navaja Negra 2019 - Carlos Hernández
Navaja Negra 2019 - Carlos Hernández

Nos ha enseñado cómo decompilando algunos juegos como el WoW y de su estilo se puede hacer que el cliente con el que se juega cambie comportamientos del personaje que tenemos y se mueva por sitios que programáticamente no estaba pensado. Así podía hacer que el muñequito terminase alojado debajo del camino visual pero a la vez el juego le fuerza a seguir la ruta. Resultado: ningún enemigo le puede atacar (porque no le ven). También hemos podido escuchar parámetros de los juegos como "clipping" (¿quién no recuerda en Doom el truco "noclipping"?), groundLevel (que es el que fuerza este comportamiento que acabo de contar). Nos ha puesto más ejemplos con otros efectos parecidos pudiendo llegar a desplazarse a lugares secretos.

Después Mónica Salas nos ha descrito algunos problemas que dan Google y sus servicios.

Navaja Negra 2019 - Mónica Salas
Navaja Negra 2019 - Mónica Salas

Por un lado, "es imposible prescindir de los servicios de Google". Nos ha hablado de una auditoría que hizo en una empresa que implementaba MDM en la que parecía que absolutamente todas las configuraciones de los móviles estaban perfectas. Incluyendo un modo kiosco que (apenas) dejaba hacer nada. Exceptuando la configuración del teclado instalado que pedía calificarlo en Google Play. Y ahí es donde saltó la alarma porque desde ese punto pudieron ella y su equipo saltarse todos los controles implantados por el administrador pudiendo salir de ese modo kiosco. La conclusión es que hay que poner aplicaciones de total confianza y tenerlas bien testeadas aunque sean de una simpleza increíble.

La siguiente charla la ha dado Chema Alonso (@chemaalonso).

Navaja Negra 2019 - Chema Alonso y Pablo González
Navaja Negra 2019 - Chema Alonso y Pablo González
Una vez más ha hablado de la historia de Informática 64 y cómo consiguió con Rodol montar la empresa e ir aplicando diversas ideas que tenían por muy locas que parecieran. Y de eso iba la charla: implantar ideas locas. La que nos ha traído hoy ha sido poner un MAC antidiluviano unido a una raspberry por un puerto serie tipo mini-din (nombre puesto por mi: el circular) y conseguir subir software binario a la nube de Google que da espacio ilimitado para imágenes. Y para conseguir subir el programa lo convierten a imagen. Ha explicado cómo han hecho cada paso y han hecho una demo en vivo con toda la parafernalia necesaria.

Después del desayuno/almuerzo a media mañana le ha tocado a Josu Franco dar la charla.

Navaja Negra 2019 - Josu Franco
Navaja Negra 2019 - Josu Franco
Josu nos ha hablado de las amenzadas basadas en usuario, que es el eslabón más débil. En un minuto nos ha contado las características de un producto que hace su empresa: Cytomic.

Al finalizar la charla de Cytomic Josu Barrientos (@bulw4rk) nos ha hablado de los análisis PCI-DSS

Navaja Negra 2019 - Josu Barrientos
Navaja Negra 2019 - Josu Barrientos
Primero ha explicado qué es PCI-DSS: es la normativa que establece absolutamente todas las características que tienen que cumplir todo organismo que quiera operar con tarjetas de crédito: Asegurarse de cómo se transfiere la información, almacenamiento, funcionamiento de los sistemas, obligaciones... Qué consecuencias puede tener no cumplir con la normativa o si se tienen fallos con los clientes. Ha mostrado de una forma muy genérica cómo se haría un pentest a una organización que quería actualizar esta certificación y qué pasos siguió: alcance, descripción del contexto, búsqueda de datos (tanto en los sistemas como con OSINT, como por ejemplo, en LinkedIn), acceso los sistemas por wifi o emparejando en la red una pistola de códigos de barras... El resumen es que consiguió un acceso que no debería de haberse dado en ese contexto.

Sergio Arake (@SergioAraqueC) dio la siguiente ponencia con el título Mikrohackeando.

Navaja Negra 2019 - Sergio Araque
Navaja Negra 2019 - Sergio Araque
En ella ha descrito de dónde vienen y cómo son los dispositivos Mikrotik y su sistema operativo RouterOS y los subproductos RouterBOARD. Algunos ya sabéis que tengo uno de estos (sobretodo porque ya lo publiqué por aquí en alguna ocasión). También ha contado las distintas formas de acceder a los mismos y algunas vulnerabilidades que se han ido encontrando que permiten comprometerlos sin contar con las numerosas malas configuraciones: usuarios con más privilegios que los necesarios y contraseñas débiles entre otros. Algunas de las huellas de los hackeos son denegación de servicio contra estos aparatos, robos de información, cryptomining o incluirlos como parte de una botnet (VPNFilter). Para finalizar ha dado pautas para fortificar la configuración (muchas un tanto perogrullo, pero nunca está de más): actualizarlos siempre, el firewall bien fortificado, configurar sólo los protocolos de acceso seguros, passwords y roles como Dios manda entre otros.

Una vez más la comida que nos trajo la Organización estuvo bastante bien.

En la sobremesa Noemí Rodríguez (@Noemi_rgarcia) nos habló de las consecuencias legales de Shodan.

Navaja Negra 2019 - Noemí Rodriguez
Navaja Negra 2019 - Noemí Rodriguez

Ha hecho hincapié en las zonas grises que hay a la hora de acceder a ciertos lugares gracias a encontrarlos a través de, por ejemplo, Shodan. Según la interpretación de las leyes podemos meternos en problemas. Ajustar las leyes que regulan lo físico a lo intangible como son los 1s y los 0s es muy difícil. Ha puesto varios ejemplos de búsquedas de sistemas SCADA, MDBUS o control de estación eléctrica y nos ha dado el término de "allanamiento informático" (artíclo 197 del CP). Uno de los conceptos que se pueden resumir es: si has cambiado algo y ha hecho pupa te cae la del pulpo. Si sólo has mirado y era una empresa, bueno, mejor no hacerlo. Si es una persona física: muy malo porque eso es "revelación de secretos" y muchísimo peor nos encontramos con datos de personas especialmente protegidas. Sobretodo esto último cuando se trata de webcams con, por ejemplo, menores.

Al finalizar los capones de qué puede pasar si accedemos a lugares sin permiso y toqueteamos Joel Serna (@JoelSernaMoreno) y Ernesto Sánchez (@ernesto_xload) han destripado dos alarmas.

Navaja Negra 2019 - Joel Serna y Ernesto Sánchez
Navaja Negra 2019 - Joel Serna y Ernesto Sánchez

Hemos tenido la oportunidad de ver cómo funcionan dos alarmas que han comprado por internet. Han explicado que una de ellas ofrece wifi pero con un SSID que no se puede cambiar y mucho menos la contraseña, la cual obtuvieron reverseando el apk que se utiliza para configurarla. Además, resulta que a pesar de que esa misma alarma decía que funcionaba sobre 3G la circuitería interna realmente era sólo para 2G la cual es relativamente fácil manipular con una estación de telefonía móvil falsa (si bien tampoco es tan sencillo tener una también es bastante más delito que entrar directamente en la estancia donde se encuentra el aparato en cuestión y reventarlo de un martillazo). El NFC que permiten usar resulta que es muy básico y sólo mira el ID del tag y por lo tanto, si se graba otro tag con ese ID tampoco es que sea de mucha utilidad. Al principio han hablado un poco de los sistemas propietarios de las marcas conocidas y ciertos problemillas que podrían tener si publicasen algún reversing de sus sistemas.


Después de la merienda Ricardo Narvaja (@ricnar456) ha dado una pequeña charla.

Navaja Negra 2019 - Ricardo Narvaja
Navaja Negra 2019 - Ricardo Narvaja
En ella ha dado una pinceladas a los términos básicos para el reversing: bug, vulnerabilidad, exploiting. Definición de buffer overflow, integer overflow, use after free, format string, null pointer deferences. Y algunos tipos de exploits. Como le quedaba tiempo la gente ha tenido la posibilidad de preguntarle muchas cosas.

Al finalizar Ricardo hemos visto una vez más a Ruth Sala (@ruth_legal).

Navaja Negra 2019 - Ruth Sala
Navaja Negra 2019 - Ruth Sala

Como de costumbre nos ha ilustrado una vez más en los aspectos legales del mundo en el que nos movemos. En esta ocasión nos ha hablado de cómo se debería aplicar un pentest de ingeniería social y todas las áreas legales que deberíamos de tener en cuenta cuando tengamos que aplicar uno de estos. Sobretodo: si se va hacer telefónicamente hay que grabar la llamada. Todo tiene que estar muy bien documentado y por supuesto sin olvidarse del contrato. Nos ha contado que se hizo un CTF para el EuskalHack basado en uno de la DefCON y tuvieron muchos problemas para poderlo llevar a cabo, precisamente por el "intringulis" legal que esto conllevaba. Un área muy interesante y muy comprometida al mismo tiempo.

Y la última ponencia de hoy la ha dado Carmen Torrano (@ctorranog).

Navaja Negra 2019 - Carmen Torrano
Navaja Negra 2019 - Carmen Torrano
Ha empezado dando la cifra escalofriante de dispositivos IoT que va a haber conectados a internet en 2020: 20.000 millones de dispositivos (¿20 millardos?). Se ha puesto de relieve el problema de autenticar que un dispositivo de estos es el que dice que es y que hace sólo lo que se espera de él (y no otras cosas más). Además de los orígenes y destinos del tráfico con los que trabajan. Es muy importante concienciar a los usuarios y aplicarle seguridad a cada dispositivo. Ha dado las razones por las que el machine learning es perfecto para la seguridad IoT: la escala del número de dispositivos y el hecho de de que cada dispositivo tiene una única función determinada (saliendose de esa función es que algo malo hay). Nos ha hablado de honey pots y nos ha presentado un sistema que han montado con unos cuantos pots mostrando estadísticas de ataques incluso en tiempo real.

Y hasta aquí hemos llegado a la segunda jornada de esta edición. Y nos queda otra más que seguro que es igual de interesante que estas dos últimas.

jueves, 3 de octubre de 2019

Crónica jornada I - Navaja Negra 2019

Este año 2019 he podido volver a venirme a las Navajas Negras después de dos años de ausencia. Tal y como hacía los otros años anteriores me he venido con Julián.

En la inauguración, además de Rubén, presidente de la organización, han estado otras personalidades de las instituciones de la Universidad y del Ayuntamiento de Albacete.

Navaja Negra 2019 - Inauguración
Navaja Negra 2019 - Inauguración
Han hecho unos agradecimientos a la organización y les han felicitado por los éxitos cosechados.

Después se ha subido al escenario Ricardo Narvaja (@ricnar456) al que la organización ha tenido la oportunidad de entrevistarle.

Navaja Negra 2019 - Ricardo Narvaja
Navaja Negra 2019 - Ricardo Narvaja
Recordemos que Ricardo es el máximo exponente del reversing en el mundo latino. Entre las cosas ha destacar está el cómo comenzó a aprender a hacer reversing y cómo acabó fundando con otras personas Crackslatinos. También nos ha explicado todas las dificultades que encontró a la hora de hacer reversing y exploiting además de cómo se ganaba la vida.

Al finalizar la entrevista el Dr. Alfonso Muñoz (@mindcrypt) se ha subido al escenario.


Navaja Negra 2019 - Alfonso Muñoz
Navaja Negra 2019 - Alfonso Muñoz
Ha destripado una serie de ataques ya muy conocidos sobre SSL/TLS. Las características comunes que tienen, qué lecciones se han aprendido de ellos. Para ello los ha resumido mucho ya que no se ha dejado ni uno de los más famosos. HeartBleed, Freak, 3Shake, BREACH, Poodle...). Hemos podido recordar que dependiendo del ataque se conseguía descifrar sólo una pequeña porción el tráfico capturado o gran parte si no todo. Y para ello se buscaban distintos métodos: forzar un downgrade de versión de protocolo de cifrado (o a usar uno peor), aprovecharse de malas implementaciones, ataque de relleno (o también conocido como padding) y ataques de compresión. Las recomendaciones que nos ha recordado (porque en teoría ya deberíamos de saberlas, pero en la práctica...): olvidarse de RSA y asegurarse de que el algortimo escogido hace lo que debe.

Después del desayuno Jesús Díaz Barrero nos ha hablado de SecOps y de un sistema nuevo de su compañia.


Navaja Negra 2019 - Jesús Díaz Barrero
Navaja Negra 2019 - Jesús Díaz Barrero
Cuando se adquieren logs surgen problemas como gran ingente cantidad de datos que analizar que no da tiempo a verlos todos. Nos ha presentado un aplicativo: Cortext, que ayuda a minimizar al máximo el análisis de todos esos datos facilitando mucho su gestión y búsqueda de datos importantes.

Cuando ha terminado Raúl Casanova ha mostrado ataques a sistemas dispositivos conectados por bluetooth.


Navaja Negra 2019 - Raúl Casanova
Navaja Negra 2019 - Raúl Casanova

Lo primero que ha comunicado es que es un protocolo (aunque es posible que no esté bien dicho lo voy a nombrar así) de comunicación que se olvida mucho a la hora de hacer pentest. Ha presetado un caso práctico con su demo en la que teníamos un dispositivo (llamémosle móvil) emparejado por bluetooth con una máquina y ha conseguido que otro aparato ajeno termine usando ese "móvil" para hacer pivoting hacia la máquina. Para ello ha usado metasploit, servicios SDP (por ejemplo, el módulo sdp_switch), Vamos: ha hecho la fase de búsqueda, explotación, post-explotación (elevación de privilegios, pivoting...) que se hace en todo pentest. Nos ha hablado de una herramienta suya llamada bluedog.

Antes de la comida Roberto Amado Gómez (@ramado78) nos ha hablado de ataques sin usar malware con herramientas del propio sistema operativo.

Navaja Negra 2019 - Roberto Amado
Navaja Negra 2019 - Roberto Amado
El título de malwareless es porque se utilizan herramientas del propio sistema operativo para hacer el ataque. Para ello tenemos los conceptos LOLBIN y LOLBAS. La idea es usar dichos comandos que los antivirus no van a dar por maliciosos para que hagan otras cosas para las que no estaban pensados. Ejemplos de esas herramientas: certutils.exe, hh.exe, esentutil.exe... Ha puesto varios ejemplos y demos: en la primera se consigue que una de las herramientas se baje algún fichero al disco (algo "no deseado" por los malos) y otra en la que usando Word se consigue ejecutar un script en VBA que no sólo se queda en memoria y por lo tanto, siempre teniendo en cuenta la persistencia de los procesos, puede hacer mucho daño sin que los antivirus se enteren. Pocas cosas se pueden hacer para detectar este tipo de ataques. Un ejemplo hubiera sido el uso de Autoruns.

Después del descanso de la comida he ido al taller Fishing phisers, impartido por Carolina Gómez y Álvaro Alonso Gutierrez.

Navaja Negra 2019 - Carolina Gómez y Álvaro Alonso Gutierrez
Navaja Negra 2019 - Carolina Gómez y Álvaro Alonso Gutierrez
Hemos visto distintas formas de crear páginas para hacer phising incluyendo la generación de certificados que terminan colando sin dar alerta. La presentación ha empezado muy básica porque realmente no estaba destinada para un público con nuestro perfil. Después han nombrado alguna herramienta (además de VirusTotal) como https://www.any.run (muestra durante 3 minutos cómo se comporta un ejecutable y si hace conexiones a alguna dirección IP), Slavasoft.... Han hecho algunas demos con alguna técnica como por ejemplo próxies de certificados digitales. No voy a negar que esta me ha costado bastante (también estaba bastante cansado, todo sea dicho).

Al finalizar hemos podido merendar un poco.

La siguiente hora Alejandro Espinosa y Julio Martínez nos hablaron de dispositivos PLC (domésticos).

Navaja Negra 2019 - Alejandro Espinosa y Julio Martínez
Navaja Negra 2019 - Alejandro Espinosa y Julio Martínez
Estos dispositivos son los que se usan para aprovechar la instalación eléctrica para usarla como red de comunicación. Estos aparatos suelen utilizar el protocolo HomePlug AV, si bien ya está la "v2". Su investigación vino porque uno de ellos instaló en su vivienda una pareja de estos dispositivos pero terminaban emparejados con los de otra vivienda de un vecino. Nos han explicado cómo se identiican entre ellos y la red virtual que terminan generando dependiendo de una serie de datos y claves que se intercambian. Dependiendo del nombre de red que se ponga y de la clave introducida pertenecerán a una red o a otra lo que llegado el caso permitiría forzar a que un aparato que se controla se pueda conectar a una red ajena. Han hablado de los términos AVLN, STA y Cco (red, estación, controlador o admin). Nos han mostrado formas en las que se pueden conseguir las claves de una red o dispositivo (como por ejemplo, calculándola a través de su MAC).

Al finalizar esta ponencia Silvia Cuenca nos ha hablado de evidencias digitales para testigos que son dispositivos Android.

Navaja Negra 2019 - Silvia Cuenca
Navaja Negra 2019 - Silvia Cuenca
Nos ha explicado qué es un testigo digital (tiene que identificar bien al usuario con sus propias políticas, proteger las evidencias...). Ha usado el Google Pixel 3 que tiene el chip Titan 3 (parecido al TPM) para garantizar la integridad. Según busquemos usar algunos mecanismos de seguridad como el keystore (que guarda un alias de las claves) o el Open Mobile API se podrá soportar en unas versiones de Android u otras (4.3 y 9.0 respectivamente). Además de mostrarnos una tabla de diseño de su aplicación, algunos diagramas de ciclo de vida y métodos varios nos ha enseñado una demo de su aplicación. Como no lo he explicado muy hasta allá: el sistema que ha ideado trata de hacer que el móvil recoja las evidencias y almacenarlas o enviarlas a un servidor seguro siempre mateniendo la integridad de las evidencias en mente para que no se puedan poner en duda.

Para finalizar el día Pilar Vila y Belén Pérez nos han hablado de fonrensic en sistemas industriales. Lo siento, pero la única foto que pude sacar me ha salido (oh, sorpresa! Movida). Si bien muchos de los aspectos de los que han hablado son semejantes entre el forense informático (IT) y de los sistemas industriales (OT) los problemas están en que los sistemas industriales no se pueden parar así como así. Los hay que llevan décadas sin pararse ni actualizarse y si se han producido paradas han sido planificadas durante un periodo muy, muy corto de tiempo (casi siempre un par de minutos). Una parada en un sistema de estos son pérdidas para la empresa propietaria. También está la dificultad de hacer bien las cosas porque se pueden estropear con sólo mirarlas. Y ni que decir tiene que un notario o un juez entiendan de qué va el tema a la hora de judicializar un asunto relacionado con un forense de este tipo. No hay que olvidarse de otros problemas (¿he dicho que los hay que son muy arcáicos?): muchos protocolos y dispositivos existentes cada uno de su propio fabricante y no compatibles entre ellos. Dificultad de encontrar sistemas de conexión como switches gestionados o protocolos estándares, ambientes con temperaturas extremas. Un mínimo ping puede hacer fallar sistemas internos conocidos como PLCs (que no son como los comentados antes), sistemas SCADA. El resumen es que son ambientes mucho más dispares a los encontrados con máquinas menos delicadas que si ya de por sí en un entorno con PCs, SIEMs/UMTs, etc es ciertamente complejo de analizar al vuelo en estos otros entornos va mucho más allá.

Y hasta aquí la primera jornada. Ya veré si me da tiempo a hacer una única publicación para la segunda o termino juntando un único post para los dos días siguientes.

sábado, 3 de agosto de 2019

Debian/Linux: cambiando arquitectura x86 a x64

Hace poco os conté que no me aparecía el comando shutdown una vez había elevado privilegios con su y cómo lo solucioné. Todo ello porque descubrí que mi instalación de Debian estaba como x86 cuando mi máquina era x64. No recuerdo por qué lo hice en su momento: si fue un despiste o si tenía una razón que en ese momento era lógica. Así que busqué el procedimiento, lo seguí, me dio problemas, acabé actualizando (de casualidad) a la nueva versión de Debian hasta que me encontré con dicho problema y con su solución, ahí contada.

Como dije escribiría un post contando qué procedimientos seguí. No tomé nota, pero sí he estado manteniendo las distintas pestañas que estuve viendo, por lo que lo más seguro es que alguna cosa no termine de coincidir.

También, y antes de ponernos en harina, toca el típico disclaimer: no hagas esto si no estás muy seguro. Podrías terminar necesitando reinstalar muchísimos paquetes y te volverás loco. Vamos: que casi, casi podrías necesitar reinstalar (tal y como recomiendan en algunos sitios: hacer una instalación limpia antes de hacer el cambio).

Todo lo vamos a hacer en consola con privilegios.

Ejecutamos:

# dpkg --print-architecture

Que nos mostrará la arquitecura actual (que es la que nos indica que estamos en x86)

i386

Vamos a añadir la nueva para poder tirar de x64:

dpkg --add-architecture amd64

Si ahora ejecutamos:

dpkg --print-foreign-architectures

Nos mostrará:

amd64

Ahora toca actualizar el repostorio e instalar el kernel para x64. El mayor misterio es indicar en el que queremos que tire de amd64.

apt-get update
apt-get install linux-image-amd64:amd64

Toca reiniciar. Acuérdate de seleccionar el kernel recién instalado.

Al ejecutar dpkg con los dos parámetros anteriores los resultados se intercambiarán, siendo amd64 el principal e i386 el foreing.

Desconozco por qué hacen un clean pero normalmente para estos casos yo lanzo todos: purge, clean, autoclean, etc.

apt-get clean
apt-get autoclean
apt-get purge
...

Ahora toca descargamos tres paquetes para esta arquitectura y forzar su instalación con dpkg:

apt-get --download-only install dpkg:amd64 tar:amd64 apt:amd64
dpkg --install /var/cache/apt/archives/*_amd64.deb

Tampoco estoy muy seguro si le llegué a pasar el parámetro --force-architecture en alguno  de estos dos comandos. Me suena que sí pero no recuerdo en cuál (mínimo en el segundo).

En teoría ahora podrías instalar cosas en la recién configurada arquitectura. Esto tiene su aquel. Porque según las distintas fuentes ponen un orden u otro sobre cómo o cuándo instalar los paquetes. Al final lo que hace falta es actualizar todos los máximos paquetes necesarios. Además, hay más librerías que harán falta (gcc, libgcc1, libc6...) y se te quejará mucho el sistema si no las has actualizado.

Un ejemplo para las actualizaciones y correcciones de los paquetes puede ser el siguiente...

Actualizar el repositorio:

apt-get update

En algunas de esas instalaciones te forzará a escribir algo así como "Sí, ¡haz lo que yo digo!". Además, no metas ningún typo o no lanzará la instalación. Al final hace una comparación literal de lo que busca (entiendo que se incluyen exclamaciones y todo).

Aunque será necesario corregir o reparar muchas instalaciones (ambos son los mismos):

apt-get -f install
apt-get --fix-broken install

También se puede hacer reinstalación de paquetes. Este parámetro no recuerdo si lo llegué a poner: pero revisando la ayuda de apt-get viene y seguro que en algún momento lo lancé. Más adelante mostraré un ejemplo.

Actualizar todos los paquetes del sistema con respecto al repositorio:

apt-get upgrade
apt-get dist-upgrade

Ir buscando los paquetes instalador como i386 para ver si puedes forzar a que se instalen como amd64:

dpkg --get-selections | grep i386

Y a partir de aquí, forzar la reinstalación:

apt-get --fix-broken --reinstall paqueteParaReinstalar:amd64

Y de todas formas, te encontrarás con que hay paquetes que tienen ambas versiones instaladas. Algunas las podrás desinstalar (no te olvides de poner :i386 no vayas a perder la de la nueva arquitectura).

Así, será necesario repetir muchas, muchas, muchas... muchas veces todos estos procesos de apt-get. Por eso, al ser una locura y encontrarme con tantos problemas, se me ocurrió actualizar a la nueva versión de Debian. Que por suerte llevaba apenas dos semanas publicada. Y aún así, terminé corrigiendo problemas montando el entorno con una unidad de arranque y actualizando muchos más paquetes en ese entorno.

Como podéis ver es... Vamos. Que es bastante lío. ¿Compensa reinstalar de cero e ir montando el sistema de nuevo? Pues no lo sé. Para suele ser mejor recuperar un sistema que montarlo de cero. Pero de vez en cuando toca hacerlo. En mi caso, que llevaba relativamente poco tiempo con la instalación original, no me compensaba ponerlo de cero.

Si puedo ayudar en cualquier duda del procedimiento, por favor, avisadme. A ver si hay suerte y puedo ayudar.

***
Algunas de las fuentes que tuve que utilizar:

https://askubuntu.com/questions/5018/is-it-possible-to-upgrade-from-a-32bit-to-a-64bit-installation
https://unix.stackexchange.com/questions/40463/how-to-convert-a-32-bit-x86-debian-based-system-to-64-bit
https://wiki.debian.org/CrossGrading

viernes, 26 de julio de 2019

Debian; shutdown: command not found

Por cierto: este post lo escribiendo desde el móvil. Espero que el corrector no haga de las suyas.

Hace poco hice una actualización de mi Debian "scratch" a... "buster". Pero por intentar pasar la arquitectura de instalación de 32 bits a 64. Como la cosa no me terminó de ir del todo bien al intentar sustituir las aplicaciones me dio por buscar y encontré con que había nueva versión de Debian.

Para resumir: después de muchas sustituciones y malabarismos varios, di por finalizada la tarea. Pero mi usuario root era incapaz de apagar o. reiniciar la máquina con los comandos.

Así, buscando, me he encontrado con la solución.

El problema se da sólo al elevar simplemente con

#su

Porque ahora, tal cual está, no incluye la variable de entorno $PATH de root. Para que la incluya hay que pasar alguno de los siguientes parámetros: [- | -l (L minúscula) | --login]

Así, ejecutando:

#su -l

Ya nos incluirá en el $PATH la carpeta

/sbin

Que ha dejado de ponerla con el su de toda la vida.

Espero que si os sucede os sea de utilidad.

miércoles, 24 de julio de 2019

Elegir qué versión de Python ejecutar

En el siguiente enlace:

https://linuxconfig.org/how-to-change-default-python-version-on-debian-9-stretch-linux

nos indican cómo forzar qué versión de python ejecutamos tenemos varias instaladas a la vez.

Aunque también se tiene la opción de seleccionar el número directamente:

$python3.6
$python2.7

si ejecutamos

$python

¿Qué se ejecuta? Eso es lo que decidimos aquí. Así, además, se debería de poder desinstalar la versión antigua.

Sólo para tenerlo como chuleta. Espero que a vosotros también os sea de utilidad en algún momento.

lunes, 15 de julio de 2019

Simulador de expresiones regulares

Uno muy, muy rápido.

Un simulador para hacer expresiones regulares y ver con colorines qué se selecciona realmente es este que enlace aquí abajo:

https://regex101.com/


Al menos para python me ha venido muy bien y quiero tenerlo por aquí (hasta que se me olvide que lo tenía) por si algún día me hace falta encontrarlo de nuevo.

Además de python también lo ejecuta con otros tres o cuatro lenguajes más. Esto ahorrará mucho ensayo y error. Además, da bastantes pistas de qué parte se está detectando y cuál no.

viernes, 21 de junio de 2019

/etc/resolv.conf: se sobreescribe

A ver si me sale corto este post.

Esta es la típica solución que cuesta mucho encontrar, uno cree que se acordará de la solución y tiempo después la necesita y se ha olvidado.

Problema que llevo queriendo solucionar desde hace mucho tiempo: el fichero /etc/resolv.conf de un Debian que tengo instalado se me sobreescribe. Todo el tiempo que he querido solucionarlo he intentado quitar distintos servicios que ya ni me acuerdo. Pero me he encontrado con que una persona ha mostrado distintas soluciones al problema.

Una de ellas me ha permitido solucionarlo encontrándome con que mi resolv.conf era un enlace a un fichero de NetworkManager. En mi caso, su solución la he aplicado modificando directamente /etc/NetworkManager/NetworkManager.conf.

Ojo, que ese mismo enlace tiene más soluciones.

En el segundo enlace dan unas pocas pistas más. Pero habiéndolo solucionado con el primero poco más he leído del segundo (a parte de que he llegado a este a partir del segundo).

Espero que en algún momento os sea de utilidad.

domingo, 2 de junio de 2019

Compartiendo impresoras por internet

Hoy he adquirido una impresora láser multifunción por Wallapop. Un trasto que de sólo transportarlo a pulso del coche (que no he podido aparcar excesivamente cerca de casa) ya me he ahorrado un día de entrenamiento en el gimnasio.

El caso: se me ha ocurrido hacer una búsqueda de su márca (XXX) y modelo (YYY) para ver temas de configuraciones (manual), tóner, ruidos raros que no me pareció oir cuando la han probado... El tema es que el primer resultado era el manual en PDF de la propia página del fabricante. Y para mi sorpresa había varias direcciones IP después. No sé por qué se me ha ocurrido acceder a ellas (cenutrio de mí, todo sea dicho). Y me he encontrado... ¡Con un panel de control del servidor web de la propia impresora!

Ahora que sigo fijándome en la búsqueda: he puesto el nombre completo entrecomillado "XXX YYY" problema para solucionar

Sí, ya sé que esto se podría hacer en Shodan. Pero no me hubiera imaginado nunca que una búsqueda tan básica me hubiera dado un resultado de este tipo en la segunda entrada. Como hubiera dicho Eugenio en un chiste "Cosa curiosa Rusia".

Seguiré configurando el cacharro y si me encuentro más cosas del aparato, aviaré por aquí. Por cierto: tengo pendiente un artículo que tengo a medias del Grandstream. Ya veré cuándo puedo jugar con el teléfono y lo documento.

miércoles, 15 de mayo de 2019

Rsyslog: Logrotate

Voy a añadir una opción más a la configuración que hice recientemente para rsyslog. Para poder ver los datos que se envían desde el dispositivo que estamos analizando al servidor de logs correctamente, el hecho de que esté lleno de resultados de hace días no ayuda nada. Para ello se usa logrotate.

¿Cómo lo he configurado? Bien. He encontrado que existe un fichero en /etc/logrotate.conf y otros ficheros dentro de la carpeta /etc/logrotate.d/. De los ficheros que aparecían estaban asteriskdpkgsambarsyslog.

Para forzar a que se cambien los ficheros diariamente para los dos aparatos que me interesa analizar, el SPA3102 y el teléfono Grandstream he incluido las siguientes líneas en el fichero de rsyslog:

/var/log/spa3102.log
/var/log/grandstream.log
{
        rotate 31
        daily
        dateext
        missingok
        notifempty
}

Las notas que puedo hacer al respecto:

  • rotate: número de ficheros que quiero que se me generen.
  • daily: quiero que se hagan diariamente.
  • dateext: concatenar la fecha en los ficheros cuando se copian en vez de usar números.
  • missingok: Por lo que he entendido, si el fichero de log (¿original?) falta, no se genera ningún error.
  • notifempty: no rotar el fichero cuando este esté vacío.

Como no me terminaba de convencer hacer la prueba con todo lo que contiene rsyslog he decidido copiar y pegar la configuración aquí mostrada, sólo para Grandstream, en su propio fichero.

Después de la configuración he ejecutado la siguiente instrucción:

#logrotate -f -v /etc/logrotate.d/grandstream.conf

El resultado, además de rotar ficheros que no se habían tocado en mucho tiempo, es que me ha concatenado al fichero /var/log/grandstream.log la fecha, pero no me ha generado otro nuevo. Si miro su contenido, puedo ver que en dicho fichero se siguen guardando datos. Esto me hace preguntarme: ¿Me concatenará siempre la fecha o será sólo hoy? 

---

Si bien cuando empecé escribiendo este artículo, el sistema no se comportó como esperaba, me esperé unos días más para ver qué sucedía. ¿Qué tengo ahora? 

Ahora sí que tengo los ficheros con su nombre original y sus copias diarias con la extensión de "-aaaammdd" (año, mes, día). El único problema: no se están haciendo en el momento adecuado, por lo que tengo ficheros que dicen que son, por ejemplo, del día 15, que contienen datos del 14 y del 15. :
Así, tengo:
  • grandstream.log-20190515: registros de las 6H del 14 a las 6H del día 15.
  • grandstream.log: a partir de las 6H del día 15.
Ejecutando:

#cat /var/lib/logrotate/status

Es posible ver cuándo se rotó cada fichero. Y, en efecto, las horas cuadran con respecto al desfase mostrado en los logs que necesito analizar. Repasando el comando de más arriba:

#logrotate -dfv /etc/logrotate.d/grandstream.conf

Gracias a que he revisado con más detenimiento el resultado de su ejecución he podido corregir algunos de los ficheros de configuración aquí explicados (pero yo lo muestro sin me avise de errores). 

Con respecto a las horas a las que se produce la rotación ya he encontrado la razón de esa hora tan rara. La rotación se realiza con un cron diario (/etc/cron.daily/). Dentro de esa carpeta, entre otros ficheros, se encuentra el relacionado con logrotate. A su vez, la ejecución de cada uno de los scripts que tiene que lanzar cron, independientemente de que sean diarios, semanales, mensuales... Se hace a través de la configuración que se encuentra dentro de /etc/crontab. Este fichero muestra la hora y minuto que cuadra con la que se muestra en el contenido de los logs al final del más reciente con su extensión de fecha y al principio del que se ha creado.

Lo voy a dejar aquí. Sólo me queda tomar la decisión de dejarlo tal cual, quitar la extensión de fecha (y que me salga la numeración), cambiar la hora para la ejecución de todos los diarios, forzar a que se roten sólo esos ficheros a las 0H (y por lo tanto, al intentar hacerlo de nuevo a las 6H no tendrá efecto)... Ya veré.


Sólo para tener un listado de los distintos sitios que he visitado (y así poder buscar en un posible futuro si es necesario, aunque creo que he perdido alguno):

jueves, 9 de mayo de 2019

Grandstream GXP1405 I: Prensentación

Recientemente me hice con un teléfono VoIP Grandstram GXP 1405, ya deprecated, para incluirlo en mi centralita Asterisk.

Grandstream GXP 1405
Grandstream GXP 1405

Como se puede ver es muy sencillo. Tiene para configurar dos líneas, típico botón de poner el altavoz para manos libres, PoE (si bien también trae una fuente de alimentación), permite conectarle una diadema para hablar por micrófono, la (típica) posibilidad de usarlo de switch para ponerle el PC... Vamos, lo más típico que uno se puede encontrar en un trasto de este tipo en una oficina.

Seguro que puede apreciar en la pantalla LCD hay tres llamadas perdidas de unas cuantas pruebas que estuve haciendo. Eso es porque ya lo tengo configurado. Entre otras opciones permite configuración vía http(s). Desconozco por qué pero ayer mismo me dio problemas y tuve que tirar de https, cuyo certificado no está reconocido, pero para el caso, me sirve. 

La configuración manual de la línea 1, que es la que se corresponde con el usuario de la centralita que le he creado, no fue del todo complicada. La recuerdo muy sencilla, a pesar de que para cada línea ofrece muchas opciones.

Yendo a general settings:

Grandstream GXP 1405 - Menú para acceder a General settings
Grandstream GXP 1405 - Menú para acceder a General settings
Y la configuración es muy sencilla: poner la dirección IP, el nombre de usuario (o extensión), contraseña y listo:

Grandstream GXP 1405 - General settings
Grandstream GXP 1405 - General settings

Una vez apliquemos los cambios y volvamos a la sección de inicio, veremos el resultado que tenemos en el pantallazo: una línea conectada y la otra no. Si hubiese algún problema cuando inicie sesión, evidentemente, se quedará en rojo. 

Como apenas he jugado con el aparato, mientras estaba escribiendo este post me he encontrado con algunas cosas que me las estudiaré para ver si merece la pena escribir sobre ellas.

Además del servidor web tiene otro ssh, pero la shell es un simple menú que apenas deja tres cambios que prácticamente serán para acceder vía web.

Grandstream GXP 1405 - Configuración vía SSH
Grandstream GXP 1405 - Configuración vía SSH
Y así es como tengo un juguetito más que, al menos las pruebas que hice, funciona bastante bien. Esperemos que en un caso real también lo haga. 

sábado, 4 de mayo de 2019

Rsyslog v8: actualización

Hace un tiempo hice un post sobre rsyslog. Ahora que creía que lo tenía activo, me he encontrado con que no era así. Posiblemente porque reinstalé el sistema. Ahora que he querido volver a ponerlo me he encontrado con que la configuración es ligeramente distinta y no me termina de funcionar del todo bien.

Primero: en /etc/rsyslog.conf descomentar:

  • module(load="imudp")
  • input(type="imudp" port="514")
También habrá que asegurarse de que esta línea está descomentada:
  • $IncludeConfig /etc/rsyslog.d/*.conf
Como se puede ver, hasta aquí la única diferencia que hay con respecto a los parámetros antiguos es que ya no se usan "$ModLoad" ni "$UDPServerRun".

A su vez, en /etc/rsyslog.d/ he creado dos ficheros, uno para cada sistema que necesitaba logear. Su contenido:

:FROMHOST-IP, isequal, "_direccion_ip_sistema_" /var/log/_nombre_fichero_.log

& stop

Me he encontrado con un problema: no se me generan los ficheros. Algunas de las cosas que he leído que se podía hacer era ejecutar:

#/etc/init.d/rsyslog rotate

Que a su vez, según he entendido, fuerza a rotar los ficheros de log y a su vez generar los que no estuvieran creados. Pero no han funcionado.

También he querido buscar datos ejecutando rsyslog en modo debug (o eso he entendido al buscar soluciones:

#rsyslog -dn | more

Como son muchas líneas permitirá ver las lineas. Otra opción: mandarlo a un fichero auxiliar y después hacer un pipe ( | ) con grep

Nos permitirá ver que:
  • Se han localizado los ficheros que hemos incluido en /etc/rsyslog.d/ (puedes buscar la cadena "requested to include" o "config parser".
  • El contenido del filtro, al menos de uno de ellos.
Así, se podrá ver si hay algún problema. En mi caso no me ha terminado de ayudar. 

No obstante, uno de los sistemas sí que están guardando datos en /var/log/messages y en /var/log/syslog.

Que se estén guardando datos en estos ficheros para sólo uno de estos sistemas lo único que me indica es que realmente está escuchando. Por lo tanto, tengo que solucionar varios problemas:
  1. Que no se guarden los datos en los otros ficheros: syslog ni messages.
  2. Que se generen los ficheros que quiero.
  3. Que el equipo del los equipos de los que no se están guardando logs sí se guarden.

La verdad, he hecho muchas pruebas con distintos resultados.

En teoría para el número 1 estaba la opción "& stop". Pero como no se generan (generaban), tampoco estoy muy seguro de que esté sirviendo. 

Asegúrate de que la dirección IP del emisor es la correcta ya que en uno de los casos puse la propia del servidor de logs. De las muchas pruebas que he conseguido hacer, he tenido todo tipo de resultados. 

Continuando con la línea "& stop" para solucionar el número 2: he conseguido que se generen los ficheros comentando esa instrucción. Por un lado, hice la prueba de incluir el contenido de los dos ficheros (sin el stop) en la configuración directamente y así sí que se me generaban los dos ficheros. Pero después, si comentaba esas líneas, dejaba de funcionar. 

También hice lo siguiente: reiniciar tirando del cable el equipo que en ningún momento generaba el log. Como no tiene ninguna otra opción para apagar y encender no ha quedado otro remedio que hacerlo así.

Lo extraño: este del que hablo sólo genera el fichero si se reinicia. Aunque se produzca un evento, desconozco el por qué de ese comportamiento.

Como costará entender las soluciones, a ver si las puedo resumir:
  1. Evitar guardar en messages y syslog: A día de hoy no tengo solución viable.
  2. Reiniciar dispositivos si es necesario. Además, aplicar número 3.
  3. No poner "& stop" bajo ningún concepto, al menos para las necesidades básicas.

Aunque juraría que hice pruebas comentando esa línea maldita, no llego a entender por qué habiendo hecho lo mismo que mostré la anterior vez me ha costado tanto hacerlo funcionar.

sábado, 30 de marzo de 2019

Crónica RootedCon 2019: Día 3

Hoy he empezado el día con el despiste de pensar que llegaba tarde pensando que llegaba tarde por el cambio de hora. Ese cambio de hora que se hace entre el sábado y el domingo, y no hoy sábado.

Al llegar he visto a Alberto (@albert0r) y a Chencho (@chencho) de la organización con los que nos hemos hecho un selfie.



Además, me tenían una sorpresa preparada antes de empezar las charlas: subir al escenario para decirme que voy a hacer las crónicas oficiales de RootedCon. Una vez más: ¡¡Muchisimas gracias!! Además, hoy he participado haciendo más preguntas que los otros días (y saliendo de voluntario).

La primera charla la han dado Pablo González (@pablogonzalezpe) y Enrique Blanco (@eblanco_h).

RootedCon 2019 - Pablo González y Enrique Blanco - Autoencoders, GANS y otros chicos del montón
RootedCon 2019 - Pablo González y Enrique Blanco - Autoencoders, GANS y otros chicos del montón
Después de la introducción y de enumerar las cosas con las que hacen pruebas en Telefónica han empezado hablando de las noticias falsas. Si bien han explicado que muchas veces se habla de ellas cuando son escritas, también existen técnicas que permiten poner palabras en boca de otros a través de vídeos. Y para ello se utiliza la IA y el machine learning. Aunque también permiten detectar anomalías en la red o phising. Han descrito los distintos tipos de aprendizaje (inductivo: supervisado, no supervisado y semi-supervisado; reforzado). El módulo de machine learning hace falta entrenarlo y alimentarlo llegando a durar varios días. Además han explicado las redes neuronales, qué son los autoencoders y los GANs (entre dos imágenes, una indubitada se mira si la otra es real o falsa). Con los autoencoders Han hecho una demo con dos vídeos. Con GANs han permitido capturar con una webcam la cara de una persona (¡la mía!) haciendo que parezca que Chema Alonso estaba delante de ella.


También han mostrado una demo en la que se permitiría hacer algo parecido con audio, pero a día de hoy sólo es eficiente cuando se está hablando en inglés o en chino. También han explicado las contramedidas para detectar estas manipulaciones y las fake news. Entre otras, algunos recursos que permiten analizar urls, patrones biométricos, cambios de colores en los píxeles, patrones en el parpadeo de los ojos, etc.

Al final esta charla, Miguel Ángel de Castro Simón (@madecastrosimon) y Pablo San Emeterio (@psaneme) en la que han hablado de los disclousures que se hacen al mandar los e-mails a sistemas de análisis. 

RootedCon 2019 - Pablo San Emeterio y Miguel Ángel de Castro - Another bad e-mail
RootedCon 2019 - Pablo San Emeterio y Miguel Ángel de Castro - Another bad e-mail
Han empezado diciendo que los e-mails deberían de haberse llamado postales porque como se puede ver el contenido sin problema... La charla viene de un análisis que tuvieron que hacer como consecuencia de un malware a un banco pakistaní al les robaron una gran cantidad. En la investigación se encuentran con un e-mail que contiene un adjunto que es un malware y que éste se conecta a una dirección que todavía responde. Nos han nombrado varias herramientas: mail mincer para automatizar la investigación y ésta a su vez se vale de otras. Wildfire, Virustotal, Diario (suya propia a la que nos han dado la opción de poder pedir acceso: diario.e-paths.com). Al almacenar todas herramientas los ficheros se mandan pudieron obtener muchas estadísticas de los e-mails pudiendo analizar todos los datos posibles: asunto, cuerpo, adjuntos, pié (junto con los disclaimers de no lo leas si no es para tí pero ya lo has leído), destinatarios, dominios involucrados... Los distintos sectores a los que afectan los e-mails: gobiernos, industria... Interesante encontrase cómo se subían a estos sitios de búsqueda de malware ficheros confidenciales. Encontraron un malware que atacaba a Vietnam con una forma de ofuscación que generaba un fichero en memoria de una forma bastante peculiar y muy bien ideada. Además, la dirección IP donde se conectaba también estaba activa. Entre otras conclusiones están que los e-mails siguen siendo grandes fuentes de infección y de fuga de datos.

Después del descanso, Gonzalo José Carracedo (@BatchDrake) nos cuenta cómo ha hecho ingeniería inversa para poder contactar con un satélite.

RootedCon 2019 - Gonzalo José Carracedo - Introducción a la ingeniería inversa de señales de radio
RootedCon 2019 - Gonzalo José Carracedo - Introducción a la ingeniería inversa de señales de radio
Una de las motivaciones de la charla es que Irán consiguió capturar un dron militar de EE.UU manipulando las señales de radio que lo controlaban haciéndolo aterrizar limpiamente para, posteriormente, hacerle ingeniería inversa. Antes de empezar en materia ha recordado el código penal para que no se nos olvide que las señales que no estén destinadas al público en general no se pueden escuchar aunque estén ahí bajo pena de una cuantiosa multa. El objetivo es el intentar ver cómo se podría escuchar un satélite meteorológico ruso (Meteor-M nº 2) teniendo tan sólo dos fotos del mismo (si bien él tenía los datos, la idea es encontrarlos como si no se tuviesen). Sabe que está a una órbita determinada (heliosíncrona) y en España la mejor hora de intentar escucharlo sería por la noche. A partir de una de las fotos donde se ve alguien trabajando con el satélite en tierra estima las alturas de los elementos, entre otros las antenas. Sabiendo qué tipo de antenas eran y su altura pudo estimar la frecuencia y construirse una (no sin algunos problemas). Tuvo que usar una herramienta que calcula señales, suscan, a partir de la cual consiguió recuperar tres o cuatro datos más, entre otros los baudios con los que trabajar. Poco a poco consiguió sacar la codificación y los patrones que también hacía falta para poder comunicarse. Con todo, consiguió mostrar y obtener fotos del satélite. Otras herramientas o datos que nos dijo: Irptchop, por un lado. Y el vídeo "iridium" por otro (que tendré que verlo).

Al finalizar la exposición sobre satélites Rafa Sánchez Gómez (@R_a_ff_a_e_ll_o) y Fran Gómez (@ffranz) nos han hablado de IoCs en IPv6.

RootedCon 2019 - Rafa Sánchez Gómez y Fran Gómez - IoCker: When IPv6 met malware
RootedCon 2019 - Rafa Sánchez Gómez y Fran Gómez - IoCker: When IPv6 met malware
El estudio que nos han mostrado está relacionado con el hecho de que los IDSs obvian la revisión de las amenazas relacionadas con IPv6. Se preguntan por qué, dado que ya hay muchos bichos que utilizan las dos versiones de IP. A partir de datos que han ido recopilando han publicado el primer feed de amenazas dual stack: Mr. Looquer IOCFeed. Éste permite estudiar datos de interés para poder crear las normas de filtrado que mejor interesen, todas ellas relacionadas con IPv6. De los datos más importantes están el prefijo con el que estén configuradas las direcciones dado que se han encontrado con prefijos enteros que según los datos recuperados se podrían bloquear directamente. Han recordado la RFC: usar /48 y /64 bits para el prefijo de red. También se ha enseñado un resumen de análisis de ASNs, prefijos y tipos de amenazas encontradas. Herramienta que me parece imprescindible: Hurricane Electric. También han nombrado MrLooquer IPLake con el que harán scoring por ASN y prefijo (en el momento de escribir este artículo no está activo).

Después de comer, Daniel Kachakil (@kachakil) nos ha hablado de funciones del código de Android bastate... Sorprendentes.

RootedCon 2019 - Daniel Kachakil - Android's Download Provider
RootedCon 2019 - Daniel Kachakil - Android's Download Provider
En su ponencia nos cuenta varios CVEs que descubrió analizando el framework de Android. Ha descrito qué son los content providers, los cuales permiten acceder a bases de datos (por ejemplo, SQLite), ficheros... Además de mostrar algunas clases, tanto del propio framework como suyas y ficheros AndroidManifest.xml los cuales permitirían acceder a los datos de otras aplicaciones acorde a los permisos que el sistema tenga definidos, si es que están definidos. Así, definiendo un proveedor de datos estarás dando permiso para que otra aplicación acceda a esos datos en concreto. Ha mostrado cómo implementar tanto el proveedor de datos como el consumidor de los mismos, el cual puede tirar de consultas para lanzar queries, actualizar y eliminar, además del comando adb. Por lo que recomienda ir siempre al respositorio oficial en vez de a los mirrors. Ha puesto un ejemplo de dos códigos (uno actualización, otro delete) que primero ejecuta la acción y después se pregunta si se puede lanzar o no. Nos ha mostrado un código en varios trozos donde están los 3 CVEs: 2018-9468, 2018-9493 y 2018-9543. Aparecen métodos que hacen una llamada a "public download" que no requiere permisos pudiendo obtener y manipular todas las descargas que se deseen. Con estas vulnerabilidades también se podía ejecutar SQL injection en el terminal, pudiendo obtener los datos de la base de datos. También había acceso de un espacio, "my_downloads". Una cabecera que se encontró: QueryRequestHeaders.

Después de esta charla, el equipo de Everis que tenía un stand en el evento para buscar talento nos mostró cómo montó un fake AP. 

RootedCon 2019 - Everis - Fake AP: ingeniería social
RootedCon 2019 - Everis - Fake AP: ingeniería social
Nos mostraron las estadísticas de personas que accedieron a este AP, el cual no tenía ni siquiera salida a internet. Se vio cómo "sólo" cayeron 22 personas conectándose a un punto de acceso público en un evento de hacking. Había un portal cautivo con un e-mail como usuario y una password (la que fuera) al cual algunos cautos mandaron mensajes al que lo hubiera instalado para mostrar que ya sabían que se trataba de una trampa. 

Después ese paréntesis Jaime Peñalba Estébanez (@nighterman) ha empezado con su charla: Kernel exploitation, ¿el octavo arte?

RootedCon 2019 - Jaime Peñalba Estébanez - Kernel exploitation, ¿el octavo arte?
RootedCon 2019 - Jaime Peñalba Estébanez - Kernel exploitation, ¿el octavo arte?
Como ya sabréis, este área en concreto me cuesta mucho. Ha intentado explicar una explotación básica. Ha contado muy por encima qué es el kernel, la memoria virtual y la paginación. Ha hablado de un tipo de vulnerabilidad, "null pointer dereference", relacionada con punteros, y también ha explicado algunas mitigaciones. Las hay hardware, SMAP y SMEP, que están implementadas en el microprocesador, y las hay software, KPTI (kaiser) y SLAB-Allocator. Nos ha enseñado cómo funciona su exploit. Nos ha mostrado mucho código fuente. Ha aplicado un "ataque" de abuso de use after free (UAF) y otro abuso de "race condition" (que esa parte ya me estaba costando sobremanera). Además, ha explicado otros problemas con los que nos podemos encontrar. Entre otros convertir algo no-determinístico en determinístico. Ha hecho una demo en la que aplicando lo expuesto en la charla ha elevado privilegios de un usuario normal a root. También ha recomendado limpiar las cosas para dejarlas como estaban.

La última charla de la temporada 2019 ha sido por parte de David Pérez y José Picó, de Layakk (@layakk) en la que nos han desgranado cómo funciona las comunicaciones (por no usar el término telefonía) 5G.

RootedCon 2019 - David Pérez y José Picó - Seguridad 5G
RootedCon 2019 - David Pérez y José Picó - Seguridad 5G

Han hecho una pequeña introducción hablando de seguridad y de algunos ataques teóricos. Han recordado un poco la historia de las distintas generaciones (incluyendo, aunque fuese entre comillas, la 1G). Para las especificaciones de la 5G han estudiado la release 15, y por lo tanto cualquier actualización posterior podría corregir algunos de los aspectos hoy explicados. 5G busca que todos los dispositivos, sean cuales sean, estén conectados (además de teléfonos, electrodomésticos, coches... lo que sea). Han explicado la arquitectura de 5G, en la que los elementos desaparecen para convertirse en servicios. Además, se ha creado una pila de protocolos, en la que existe autenticación y cifrado. Además de hacerse tunneling en las comunicaciones. La norma establece que se soporte como mínimo tres tipos de redes virtuales (networking slicing o rebanadas): móviles, latencia baja y bajo consumo (IoT), que podrían estar disponibles o no. Es posible estar conectado a dos rebanadas distintas a la vez. Han mostrado algunos ataques que funcionaban en 4G que en ciertos casos muy concretos se podrían llegar a aplicar en 5G. El IMSI ha cambiado de nombre, ahora se le llama SUPI, el cual en la UE está permitido mandarlo en claro en tres casos determinados, entre otros para llamadas de emergencias. También han explicado qué hace falta para que un dispositivo se autentique en la red y los métodos que podría usar para hacerlo. Algunos ataques que han nombrado son el IMSI-Catching (que funcionaba antes del 5G), ToRPEDO, Piercer (para 4G resuelto en 5G) y de trazabilidad. Han nombrado la herramienta Tamarin Prover. Han mostrado un ejemplo en el que la propia red llegue a descartar un nodo suyo (forzando así un DoS sobre ese nodo). Y hay ataques que dada la libertad que da la especificación para su implementación depende de cómo la haya configurado el operador de la red que se puedan aplicar los ataques que nos han descrito.

Y esta ha sido la última jornada de RootedCon 2019. Como siempre, ha sido placer enorme haber venido. Como ya he dicho antes, muchas gracias a la organización por todo. ¡Ah! ¡También a los voluntarios! Espero que la hayáis disfrutado tanto como yo y espero, como todos los años, veros en la siguiente edición. ¡Nos vemos!