domingo, 5 de marzo de 2017

Crónica RootedCon 2017: Día 3

Y después de dos días intensos, hemos empezado la última jornada de la edición 2017.

He podido hacer más networking, conociendo a más compañeros con los que he compartido muy buenos momentos. También me he dado cuenta de que ha habido unas cuantas charlas que me han costado un poco más seguirlas. Supongo que siempre hay alguna que cuesta un poco más que otra.

La primera charla la han dado Roberto Muñoz (@SkyeInTheWild) y Daniel García aka cr0hn (@ggdaniel).

RooteCon 2017 - Daniel García y Roberto Muñoz - Docker puede no ser tu amigo
RootedCon 2017 - Daniel García y Roberto Muñoz - Docker puede no ser tu amigo
Han descrito qué es docker (y qué no es: no es una VM). Es un gestor que crea imágenes de un despliegue, las despliega y se pueden ejecutar como copias de aislamiento. Al final una descripción rápida sería: es un chroot "bonito y fácil". Han explicado cómo se puede configurar y han destripado el contenido de una imagen, que tiene formato .tar. Al explicar cómo se puede manipular la imagen, nos han mostrado diversos ataques. Para ese fin, han hecho una demo con una herramienta de botón gordo que han montado para tal fin que permitiría, a todos los efectos, terminar troyanizando la máquina destino.

La siguiente charla la ha dado Ricardo J. Rodriguez (@RicardoJRdez) y del que también ha formado parte de este proyecto Victor Sánchez (@DonBallabriga) [gracias a Javier (@javifields) por mencionarles con sus cuentas de Twitter]:

RootedCon 2017 - Ricardo J. Rodriguez y Victor Sánchez - DNI 3.0
RootedCon 2017 - Ricardo J. Rodriguez y Victor Sánchez - DNI 3.0
Ha empezado poniendo ejemplos de robos de identidad reales y las distintas consecuencias para los afectados. Las razones por las que se suelen robar esas identidades, que de media obtienen 8.000 €. Después ha continuado contando la historia del DNI, de cómo se diseñó y las distintas evoluciones, llegando a la versión electrónica 2.0 y quedándose en la 3.0. Nos ha desgranado el estándar de NFC que utiliza (13,56 MHz) y varios vectores de ataque. Uno de ellos ha sido que enviando un código de 6 dígitos por fuerza bruta (código impreso en la tarjeta) se pueden conseguir todos los datos que están almacenados en una de las zonas del DNI y que son precisamente los que vienen impresos en éste. Incluyendo las imágenes de la firma manuscrita y la foto. Nos ha hecho una demo de un programilla que se ha montado para lanzarla contra el suyo propio.

Un descansillo con una conchas Codan!!!!

Después de desayunar, Raul Siles (@dinosec) nos ha hablado de cifrados en What's Up:

RootedCon 2017 - Raul Siles - WhatsApp End to End Encryption Desmystified
RootedCon 2017 - Raul Siles - WhatsApp End to End Encryption Desmystified
Esta charla es de las que más me ha costado entender. De hecho, poco he podido tomar nota. Nos ha hablado de cómo cifra What's Up las comunicaciones. Entre otros protocolos de cifrado utilizados está Signal, Diffie-Hellman (y derivados). Ya finalizando ha hablado sobre las últimas noticias relacionadas con la aplicación móvil.

Al finalizar Raul, tuvimos la charla de Yihan Lian y Zhibin Hu:

RootedCon 2017 - Yihan Lian y Zhibin Hu - Smarter Peach: Add eyes to peach fuzzer
RootedCon 2017 - Yihan Lian y Zhibin Hu - Smarter Peach
Otra que me ha costado entender (no puedo negar que nosotros los españoles a veces tampoco pronunciamos muy hasta allá). Nos habló sobre las fortalezas y debilidades de un fuzzer llamado Peach.

Después de comer vino Hugo Teso (@hteso) a hablarnos sobre herramientas propias:

RootedCon 2017 - Hugo Teso - Swett Tools O'Mine
RootedCon 2017 - Hugo Teso - Swett Tools O'Mine
El resumen sería que si queremos hacer algo, ¿por qué no montarnos nuestras propias herramientas? Entre otras que nos ha mostrado, ha sido una GUI para Radare2 que nos va a liberar muy pronto. Y que nos las construyamos a partir de las librerías a las que tengamos acceso en vez de usar herramientas públicas, que ya se sabe cómo se comportan y por lo tanto son más fácilmente detectables. Como por ejemplo, meterpreter, que tiene su propia firma. Poco a poco, a medida que iba pasando la charla, nos ha ido mostrando sus propias creaciones, tanto de software como de hardware. 

Después ha venido Pepe Vila (@cgvwzq), que nos ha hablado de loophole:

RootedCon 2017 - Pepe Vila - Loopchole: Timing attackks on shared events loops in chrome
RootedCon 2017 - Pepe Vila - Loopchole events in Chrome
Nos ha hablado de algunos problemas que se pueden encontrar en Chrome y de un paradigma de programación: EDP (Event Driven Programing). Algunos ataques a la arquitectura, cuando hay multiproceso cada uno de ellos está sandboxeado y que los iframes comparten proceso. Los distintos ataques que se pueden hacer, con los que se puede inferir información del navegador / usuario se pueden hacer con publicidad maliciosa o algún popup. 

La última ponencia nos la dio Pablo San Emeterio (@psaneme) en la que hizo se subiera al escenario a Román (@patowc):

RootedCon 2017 - Pablo San Emeterio y Román Ramírez - Inteligencia Privada: Más allá de Stix
RootedCon 2017 - Pablo San Emeterio y Román Ramírez - Inteligencia Privada
Ha empezado hablando de la organización de RootedCon y de algunas cosas de las que ya habló Mikko (@mikko) hace unos días. Nos ha contado el origen de la charla, entre otros Román y David Barroso (@lostinsecurity). También de las tendencias, en las que los malos están organizados y especializados, además de ser creativos. Además, de las diferencias que hay entre los equipos rojo y azules, siendo más numerosos (o con más capacidad, o con más ventaja) los primeros. No se puede dejar de contar las distintas dificultades según el tipo de ataque y qué se busca (la pirámide de la foto). Entre otros elementos para generar la inteligencia privada están los bloqueos de ejecuciones por defecto, es decir: usar listas blancas para indicar qué se puede ejecutar. O, como ya se ha contado en otras ocasiones, mitigar los ataques haciendo pensar al malware que se encuentra en un entorno de análisis: si tiene contramedidas para evitar estos entornos, no cumplirá su función. Y si siempre se ejecuta, mandar la muestra a todas las herramientas. Después hizo una demo.

Y aquí se terminó la octava edición de RootedCon. El multitrack de este año ha podido estar bien, pero la pena es que hay que seleccionar charlas y como norma general me quedaría con las principales. Una vez más, espero poder asistir el año que viene a la novena edición. Y para todos aquellos que he conocido: ¡ha sido un inmenso placer! 

¡Hasta la próxima!

viernes, 3 de marzo de 2017

Crónica RootedCon 2017: Día 2

Hoy hemos podido disfrutar de la segunda jornada de la RootedCon 2017. Otro día que nos lo hemos pasado genial.

Hemos comenzado con unos cuantos comunicados de Román. Unos más agradables que otros, pero finalizados éstos, hemos podido disfrutar de cada una de las ponencias. 

La primera de todas ha sido de Abel Valero (@sanguinawer), en la que nos ha hablado de Radare 2.0 de una forma muy amena. 

RootedCon 2017 - Abel Valero y Radare 2.0
RootedCon 2017 - Abel Valero y Radare 2.0
Ha comenzado contando a qué distintos grupos pertenece. Después, entrando en materia, nos ha dicho de una forma muy resumida cómo funciona la herramienta, qué puede analizar, unos pocos comandos y parámetros de los que consta (consola, GUI, APIs...). Además, es capaz de analizar cualquier arquitectura. Eso sí: por lo que he entendido hay que hacerlo en la misma para la que el binario hay que estudiar. El API que nos ha presentado se llama R2PIPE. Además de alguna demo en video, nos ha descrito cómo destripó un ramsonware llamado Cerber. 

La siguiente charla no era la incluida en el calendario en papel (que trataba sobre DNI 3.0). En este caso tuvimos una charla por parte de Toni de la Fuente (@ToniBlyx) en la que nos habló sobre ataques a sistemas en la nube:

RootedCon 2017 -  Toni de la Fuente y How to survive to an attack in the cloud
RootedCon 2017 -  Toni de la Fuente y How to survive to an attack in the cloud
Nos habló de los distintos servicios para alquilar servidores en la nube: Amazon AWS, Microsoft Azure, etc. Nos mostró una herramienta que construyó para analizar un problema que tuvo con el servicio de Amazon. Insistió en que ahora se usa más infraestructura virtualizada más que la física. Para cada una de estas empresas mostró el despliegue de los CPDs (no usó esta expresión, pero para que se entienda) en sus respectivos mapamundis. Es muy importante saber la separación entre lo que nosotros somos responsables y de qué es responsable nuestro proveedor. Nos mostró cómo se podían encontrar claves que permiten crear servicios (a costa de sus propietarios) en repositorios del tipo git

"Robando" entre 3 y 5 minutos de reloj del descanso, Hugo Teso (@hteso, que mañana sábado va a tener su propia ponencia) resumió su paso por la Rooted y nos ofreció poder trabajar con él y un equipo especializado con el fin de resolver todos todos los problemas que nos mostró en esas anteriores ediciones. 

RootedCon 2017 - Hugo Teso y trabajar en un avión
RootedCon 2017 - Hugo Teso y trabajar en un avión

La siguiente charla nos la dieron el Dr. Alfonso Muñoz (@mindcrypt) y Miguel Hernandez (@MiguelHzBz).

RootedCon 2017 - Dr Alfonso Muñoz y Miguel Hernandez - BB.DD de grafos
RootedCon 2017 - Dr Alfonso Muñoz y Miguel Hernandez y las BB.DD de grafos
Ésta iba sobre dos bases de datos de grafos: Neo4j y OrientDB. Nos han desgranado cómo funciona en lo que a seguridad se refiere, qué hay que hacer para desprotegerla a posta, tal y como se encontraron al hacer la investigación. Sobretodo el hecho de que las que se encontraron accesibles a Internet y encontraron acceso a los datos había que haber forzado ex-profeso el cambio para permitir ese acceso. Nos contaron un caso real en el que tuvo que participar el GDT (@GDTGuardiaCivil) para mitigarlo. Nos hablaron de unas cuantas mitigaciones para llevar a cabo. 

La siguiente charla antes de comer fue por parte de Jaime Peñalba (@nighterman) en el que nos habló sobre bugbounties. 

RootedCon 2017 - Jaime Peñalba y The worst bugbounty ever
RootedCon 2017 - Jaime Peñalba y The worst bugbounty ever
Nos contó un caso real que sufrió un amigo suyo y él mismo con respecto a unos bugbounties de Shopify. Puso una tabla en la que se mostraban lo que pagaban por cada tipo de error encontrado. Nos habló del uso de fuzzers para estos casos y de que a veces hace falta un wrapper (nombró uno: libFuzzer). También mostró las reacciones de varias persona después de participar en este tipo de programas, tanto positivas como negativas.

Después de comer tuvimos la charla de Roam Rathaus, de Beyon Security (@beyondsecurity):

RootedCon 2017 - Noam Rathaus y su Why today's researchers cannot just publish vulnerabilities
RootedCon 2017 - Noam Rathaus y su Researchers cannot publish vulns
Nos ha hablado de cosa que ya nos ha avanzado Jaime: bugbounties que no se pagan como corresponden. Reacciones de la empresa afectada fuera de lugar (hasta amenazas de denunciar si se hace un disclousure). Y las distintas formas de dar a conocer el descubrimiento: contactando con el fabricante, con bugbounties, con intermediarios (como su empresa) y vender el descubrimiento en el mercado negro. Ha descrito los pros y contras de cada uno de ellos. 
Be real Al finalizar la charla, Román (@patowc) nos ha presentado un proyecto, "Be real talent", una empresa que han montado Alfonso, Juan, Omar y él mismo para "identificar nuestro propio talento".

RootedCon 2017 - Román Ramirez, Alfonso Muñoz Juan y Omar - Be real Talent
RootedCon 2017 - Román Ramirez, Dr Alfonso Muñoz, Juan y Omar - Be real Talent

Después de mostrarnos esta empresa de reciente creación, Chema Alonso (@chemaalonso) nos ha presentado una prueba de concepto para robar contactos de dispositivos iOS.

RootedCon 2017 - Chema Alonso - DirtyTooth: It's only rock'n roll, but I like it
RootedCon 2017 - Chema Alonso - DirtyTooth
Nos ha mostrado un altavoz que se puede usar por bluetooth. Pero al hacer una prueba de concepto con dos voluntarios con iPhone, con lo que había que hacer la prueba, resulta que estos no avisan de que te pueden estar copiando los contactos, incluso esa opción viene activada por defecto. El dispositivo, incluso ha cambiado el modo de ser sólo altavoz a "manos libres" (sin serlo) cambiando su tipo de perfil (de los que no ha hablado también). Además, resulta que desde la versión 2.1 de bluetooth el token de pareado es optativo. Nos ha mostrado un croquis de cómo está construido el dispositivo y un panel de control donde se ven los contactos copiados, incluso indentificando el número de telefono del usuario (un UID viene a cero [0]).

Antes del descanso se ha hecho un sorteo de un dron. 

Después del descanso, Javier Soria nos ha dado su charla "Hace falta un firewall cerebro-verbal!!"

RootedCon 2017 - Javier Soria y ¡Nos hace falta un firewall cerebro-verbal!!
RootedCon 2017 - Javier Soria y ¡Nos hace falta un firewall cerebro-verbal!!
Nos ha puesto diversos métodos de autenticación y accesos a lugares: lockpicking, huellas dactilares, reconocimiento facial 2D y 3D, identificación por Wifi o geoposicionamiento, botnets de IoT y webcams, Se habló de WPA2 (que es un nombre comercial, oficialmente 802.11i). O de ZigBee, una implementación inalambrica parecido al Wifi. O de usar ASs y BGP para usarlos como proxy. También nos habló de forense e ingienería social. 

Para finalizar, tuvimos una vez más un caso legal en el que personas reales sufrieron mucho. En este caso, Selva Orejón (@selvaorejon) y Edu Sánchez (@eduSatoe) nos han hablado del caso de un individuo que ha hecho sufrir (supuestamente) a muchas personas:

RootedCon 2017 - Eduardo Sanchez y Selva Orejón - ¡¡Ooosint Nena!! Vamos a por tí, Mr Ripley
RootedCon 2017 - Eduardo Sanchez y Selva Orejón - Vamos a por tí, Mr Ripley
Como se puede ver en la foto, en su caso han trabajado muchas más personas, como  por ejemplo, Ruth Sala (@Ruth_legal). Aquí nos han explicado como un individuo supuestamente (ya se sabe: hasta que no haya sentencia firme) ha conseguido engañar durante 21 años a, como mínimo, 67 personas haciéndolas creer que las quería para después robarlas, así, una tras otra, a lo largo de todo ese tiempo. Nos han contado cómo han podido hacer la investigación teniendo en cuenta las victimas que han ido encontrando y han estado dispuestas a denunciar o responder, porque hay ¿muchas? que no quieren o no pueden. Incluso una de ellas está acusada con posible pena de cárcel como consecuencia de este individuo. Además de la investigación del mundo real: estudio caligráfico, psicológico/psiquiatrico, etc también está la investigación de cada una de las identidades digitales creadas por esta persona, que podía tener hasta 6 o 7 al mismo tiempo. Nos han hablado sobre una herramienta creada para identificar alguno de los dispositivos usados y su localización. Entre otras APIs, se usó una de Google, que según qué datos entregados (2 MACs cercanas de Wifis y potencia de señal, o dirección IP pública) se podía identificar la zona por donde se encontraba. O identificar el dispositivo a través del navegador. Un caso muy curioso que me sonaba haber leído sobre esta persona en un libro.

Y... esta ha sido la segunda jornada de Rooted 2017. Mañana sábado, último día y espero que sea igual de bueno que estos dos que ya hemos pasado. ¡Hasta mañana!

jueves, 2 de marzo de 2017

Crónica RootedCon 2017: Día 1

Como ya va siendo habitual en los últimos años, he podido asistir a uno de los eventos con más afluencia (¿1.300 personas el año pasado? He oído que este año han caído 300 entradas más por lo que si es así serían... ¡1.600 entradas!) y de los más veteranos (¿junto con NoConName?) que tenemos en el panorama nacional.

Tal y como se hizo el año pasado se ha llevado a cabo en los cines del Kinepolis en Pozuelo de Alarcón, Madrid:

RootedCon 2017 - Cines Kinepolis
RootedCon 2017 - Cines Kinepolis

También lo tradicional es llegar pronto, momentos en los que tuve la oportunidad de hacer la tradicional foto del "rollo" promocional del evento en el hall: 



gMe he cruzado con muchos compañeros de otros años, entre los que estaban Pablo F. Ilesias (@pydotcom), Longinos (@l0ngin0s), Oscar (@dot_Ike), Juanillo (@tr1ana), Javi (del GDT: Grupo de Delitos Telemáticos de la Guardia Civil) además de todo el equipo de RootedCon, que como de costumbre nos ha dado una calurosa bienvenida. Casi me dejo a David (@ESFERARED)

El evento ha comenzado, como de costumbre, con la keynote que la ha presidido Román (@patowc) insistiendo en que Rooted está conformado por un equipo y no sólo él:

Rooted2017 - Keynote - El equipo de RootedCon
Rooted2017 - Keynote - El equipo de RootedCon

También hizo  incapié en que han sido catalizadores de otros muchos eventos en España, un pequeño apunte sobre el coste de las entradas y en qué se ha empleado el dinero de las mismas, o los distintos cambios y evoluciones que va a sufrir el evento. Como no podía ser de otra forma, ha hablado de los patrocinadores que sustentan el evento. Y una sorpresa: un corto realizado y dirigido por Bea Cabrera: Drones Don't Fly When The Sky Is Grey (video).

Rooted2017 - Drones Don't Fly When Sky Is Grey
Rooted2017 - Drones Don't Fly When Sky Is Grey
Tampoco debería de olvidarme de una plataforma de pagos para usar el saldo del móvil para hacer algunos traspasos de dinero. En este caso, lo han habilitado para hacer las votaciones: Coowry.

Finalizada la keynote, los ponentes, los protagonistas del escenario, empezaron a mostrarnos sus trabajos.

Miko Hypponen (@mikko), que ya se había subido al escenario porque estuvo en el corto, empezó su charla World War i.

Rooted2017 - Mikko Hypoonen y World War i
Rooted2017 - Mikko Hypoonen y World War i
Muchos de los temas que tocó se pueden resumir en que lo que antes se pagaba con dinero ahora se paga con nuestros datos y nuestra privacidad. Una frase recurrente era "data is the new oil". Y que siempre estamos siendo escudriñados: qué hacemos, dónde, cuándo, cómo somos, Dejó caer una pregunta: Si hemos perdido la batallada de la privacidad, ¿lo hemos hecho de la seguridad?  "Es importante entender al enemigo porque está cambiando constantemente" (traducción más o menos libre). También insistió en que si los gobiernos usan bichos contra la delincuencia hay que poder auditar y monitorizar ese uso. O, cómo se puede atacar a una empresa a través del departamento de recursos humanos. O qué se hizo con la BB.DD robada de LinkedIn. Después se pasó a hablar del IoT los PLCs y los ICSs, Entre otros ejemplos puso lo sucedido con Mirae y las responsabilidades de las empresas de no diseñar sistemas más robustos o si debe (o no) haber legislación sobre cómo de robustos tienen que ser los electrodomésticos conectables a Internet.

Después del descanso en el que cayeron unas cuantas conchas Codan, como de costumbre, tuvimos la siguiente charla. 

En esta estuve en dos emplazamientos, cosillas que pasan muy de vez en cuando: en el primero y poco después de empezar cambié (algo que volvería por la primera zona al terminar esta charla de la que voy a hablar ahora).

Paul Vixie nos dio la charla después del descanso, Scaling Properties of Software and System Security:

Rooted2017 - Paul Vixie y Scaling Properties of Software and System Security
Rooted2017 - Paul Vixie y Scaling Properties of Software...
Habló sobre cómo se intentan cosas de seguridad que no entendemos. También nos enseñó unas cuantas diapositivas sobre diversos aparatos conectables y sus distintos problemas que tuvieron en algún momento. O que el hecho de que los fabricantes tengan muchos márgenes no ayudan demasiado a la seguridad (o no tienen por qué ayudar). Nos habló sobre la predicción de la superficie de ataque o sobre la necesidad de hacer un diseño orientado a la seguridad. 

Al finalizar su charla se hizo el primer cambio en la organización: un multitrack, por lo que tuvimos charlas en dos salas. Yo me quedé en la principal, en la que Mikael Chala nos habló sobre operadores móviles:

Rooted2017 - Mikael Rodríguez Chala y Seguridad en Operadores Móviles Virtuales
Rooted2017 - Mikael Rodríguez Chala y Seguridad en Operadores Móviles Virtuales
Empezó mostrando de una forma muy simplificada de qué consta la infraestructura de una red móvil. Además, también nos contó de una forma muy resumida algunos ataques para interceptar datos transmitidos en este tipo de redes. Un término que nos dio y que era el que daba casi todo el sentido a la ponencia era HLR. Una BB.DD de las operadoras que no debería de poder accederse a Internet y que nos da muchos datos del usuario (ya sea número de móvil o IMSI).

Rooted2017 - Mikael Rodríguez Chala y datos del HRL
Rooted2017 - Mikael Rodríguez Chala y datos del HRL
Una herramienta que te permite sacar algunos de estos datos es HRLLOOKBACK (según nos dijo, 100 de forma gratuita por correo). Según la operadora virtual, tienen su propio HLR y devuelven toda la información o capan algunos datos sensibles.

Aquí nos fuimos a comer David, Pablo y sus compañeros. 

Al terminar de comer, que hice de avanzadilla, se hicieron otros dos multitacks más hasta el siguiente descanso, de los cuales me volví a quedar en la sala principal. 

En este bloque la primera la dieron Fernando Rubio y Victor Recuero, de Microsoft (@MicrosoftES). 

Rooted2017 - Fernando Rubio y Victor Recuero, - Advanced Threat Analytics - Detección de amenazas en Directorio Activo
Rooted2017 - Fernando Rubio y Victor Recuero, - Advanced Threat Analytics
Hay que conocer al enemigo y ahora toca proteger las identidades. Después de una intrusión las primeras 24-48 horas son las más importantes. Evidentemente, se buscan las credenciales de administración  ya que pueden hacer de todo. Nos han hecho dos demos básicas: Un simple ldap bind con vulnerabilidad y un pass the hash/ticket (para kerberos). Todo esto viene para presentarnos una herramienta (Microsoft Threat Advanced Analytics) preparada para detectar ciertos comportamientos que se consideran que no se deberían de dar y, a su vez, hace un aprendizaje de qué hace cada usuario o perfil con el fin de informar a un administrador en el caso de que haga un comportamiento que no sea habitual (como, por ejemplo, un login desde una sede en la que nunca ha estado).

Después, Alon Meczer nos habló del malware HummingBad, para Android:

Rooted2017 - Alon Meczer y Following HummingBad
Rooted2017 - Alon Meczer y Following HummingBad
Nos habló sobre cómo funcionan los anuncios y la publicidad en Android y los intermediarios que hay entre el que quiere mostrar sus publicidad y el que quiere que su aplicación muestre banners de lo que sea. Además, también nos contó los distintos métodos para monetizar: clicks/taps, impresiones, vídeos, anuncios a pantalla completa o banner... Nos habló sobre cómo paso de infectar un terminal a tener miles controlados.  La publicidad está relacionada con la infección de los dispositivos, entre otros métodos, engañar al usuario para que un botón de cerrar haga la instalación sin que se de cuenta. Además, encontró bastantes más aplicaciones muy similares a la analizada y al destriparlas pudo comprobar que por algunos parámetros que tenía se podría afirmar que pertenecían al mismo desarrollador. 

Al finalizar, se hizo el descanso antes del RootedPanel, en el que tuvimos la oportunidad de ver cuatro jefes del Grupo de Delitos Telemáticos de la Guardia Civil (@GDTGuardiaCivil):

Rooted2017 - Grupo de Delitos Telemáticos (GDT) de Guardía Civil - Historia
Rooted2017 - Grupo de Delitos Telemáticos (GDT) de Guardía Civil
La mesa redonda, desarrollo histórico de la función de delitos telemáticos en la Guardia Civil. Hemos tenido la oportunidad de ver a César Lorenzana (Comandante), Anselmo del Moral (¿?), Óscar de la Cruz (¿Teniente o Comandante?) y a Juan Antonio Rodriguez Álvarez de Sotomayor (¿?). Cada uno ha contado su experiencia en el departamento y cómo funcionaba en su época de mando en el mismo. Han indicado que en ocasiones hace falta ayuda externa fuera del cuerpo. "El conocimiento lo tiene la empresa". El resumen es que en ocasiones sí hacen falta personas que colaboren con ellos.

Y así es como hemos terminado la primera jornada de la RootedCon 2017. Mañana, segunda jornada, más y seguro que como mínimo igual de estupenda que hoy.

lunes, 13 de febrero de 2017

Simuladores DD-WRT, OpenWRT, Gargoyle...

Este post va a ser corto (espero): estoy estudiando cambiar el firmware de un repetidor de wifi, en mi caso, un TP-Link (TL-WA750RE). Sabiendo que se le puede poner un OpenWRT me puse a buscar a ver cómo se hacía, qué características tienen, qué problemas daban, etc, me encontré con otra posibilidad: Gargoyle.

Teniendo dudas de cómo son, hice una búsqueda y me encontré con una entrada de otro blog en el que ponían un listado de los distintos simuladores disponibles, entre otros, de los firmwares arriba mencionados.

¿Por qué quiero cambiarlo? Sobretodo porque con una actualización me encontré con que la seguridad de la red se tumbaba completamente porque tiene WPS activado y no hay ningún sitio donde desactivarlo. Es más, se me ocurrió hacer un escaneo de puertos, tanto para TCP:

nmap -O  {DIRECCION_IP} 

Starting Nmap 7.00 ( https://nmap.org ) at 2017-02-11 17:52 Hora estándar romance
Nmap scan report for {DIRECCION_IP} 
Host is up (0.0018s latency).
Not shown: 998 closed ports
PORT      STATE SERVICE
80/tcp    open  http
49152/tcp open  unknown
MAC Address: {DIRECCON_MAC} (Tp-link Technologies)
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6
OS details: Linux 2.6.23 - 2.6.38
Network Distance: 1 hop

como para UDP:

nmap -sU {DIRECCION_IP}

Starting Nmap 7.00 ( https://nmap.org ) at 2017-02-11 18:54 Hora estándar romance
Warning: {DIRECCION_IP} giving up on port because retransmission cap hit (6).
Nmap scan report for {DIRECCION_IP}
Host is up (0.0010s latency).
Not shown: 995 closed ports
PORT      STATE         SERVICE
53/udp    open|filtered domain
434/udp   open|filtered mobileip-agent
1040/udp  open|filtered netarx
1900/udp  open|filtered upnp
19075/udp open|filtered unknown
MAC Address: {DIRECCON_MAC} (Tp-link Technologies)

Nmap done: 1 IP address (1 host up) scanned in 1047.96 seconds

De hecho, buscando alguno de estos puertos, me encontré con un blog en el que habían destripado un enchufe "inteligente", el TP-Link HS110, y la herramienta tplink-smartplug para tirar contra éste.

Veré qué consigo y si es interesante lo contaré por aquí.

martes, 24 de enero de 2017

Asterisk y CLI: I

He estado jugando un poco con mi Asterisk. Y me puse a buscar cómo hacer algunas cosas como, por ejemplo, marcar un número desde la consola (lo que en ocasiones se le llama CLI). Para acceder a la consola, en mi caso, tengo que ser root y ejecutar:

# asterisk -r

Aunque el prompt es

nombreSistema*CLI>

no lo voy a poner en el post.

Uno de los comandos que me encontré era

console list devices.

Y me llamó la atención que me mostró unos datos que no había visto nunca:

 === Configured Devices ======================================
 =============================================================
 ===
 === ---------------------------------------------------------
 === Device Name: default
 === ---> Active:           Yes
 === ---> Input Device:     default
 === ---> Output Device:    default
 === ---> Context:          default
 === ---> Extension:        s
 === ---> CallerID Num:     extensiónRara
 === ---> CallerID Name:    nombreRaro
 === ---> MOH Interpret:    default
 === ---> Language:         en
 === ---> Parkinglot:
 === ---> Muted:            No
 === ---> Auto-Answer:      No
 === ---> Override Context: No
 === ---------------------------------------------------------
 ===
 ===========================================================

Además, si intentaba hacer una llamada a una de mis extensiones con el comando:

console dial extensionCreadaPorMi

se recibe una llamada procedente del numeroRaro. Eso sí, no me ha dejado llamar a mi móvil.

Vamos a buscar qué significa esa configuración y si puedo cambiarla a mi gusto.

En efecto: esta configuración se encuentra en console.conf.  Incluso en mi caso tiene exactamente esta misma configuración, por lo que podría cambiarla evitando tener valores por defecto no deseados. Que será lo que haga:

;
; Any configuration context defined beyond the [general] section configures
; specific devices for use.
;

[default]
input_device = default       ; When configuring an input device and output device,
output_device = default      ; use the name that you see when you run the "console
                             ; list available" CLI command.  If you say "default", the
                             ; system default input and output devices will be used.
autoanswer = yes/no
context = default
extension = s
callerid = nombreRaro <(extensionLargaLarga>
language = en/es/fr...
overridecontext = yes/no
mohinterpret = default
active = yes/no                 ; This option should only be set for one console.
                             ; It means that it is the active console to be
                             ; used from the Asterisk CLI.

Además, me puse a cambiar algunos de los filtros del trunk, restringiendo ciertas llamadas, En algún momento lo mejoraré aún más, para las que he forzado que no se hagan, vayan por otro camino.

 Una prueba que hice que no me funcionó fue

console send text "hello world"

pero como era una pequeña chorrada tampoco es cuestión de dedicarle mucho tiempo.

Otra de las pruebas  que hice era para, en teoría, forzar a una extensión ejecutar una de las aplicaciones de asterisk. Por ejemplo:

channel originate SIP/{channel} extension wait(5)

con un resultado inesperado. Si no tengo ningún canal activo en esa extensión (y aun teniéndolo también me lo hace) se inicia una comunicación con una locución indicando que se ha producido un error. Me da dos opciones para pulsar: una de ellas darme un mensaje que no está definido, y la otra llamar a una centralita Digium. El SIP/ {channel} se puede obtener a partir de

core show channels

y tiene que haber al menos una llamada en curso en la centralita.

Así, poco a poco pude jugar un poco con la consola y las llamadas en curso. Hacía tiempo que no me ponía a toquetear con estas cosas. Espero que pueda volver a darle mucho más partido a este sistema.


viernes, 6 de enero de 2017

Mikrotik routerboard 411UAHR III: Completando la configuración

Hoy, día de Reyes, vamos a completar la configuración del dispositivo RB411UAHR. Ésta se ha hecho en varias fases.. Eso significa que el artículo lo escribí  en un momento determinado, después cambié algunas cosas porque me había encontrado con problemas o hice mejoras y más adelante (justo ahora mientras estoy escribiendo esta parrafada) voy a completar datos. Intentaré que se quede lo más ordenado posible para que no sea el típico caos de añadir datos que después no pegan ni con cola.

Solucionando el problema del acceso de los DNSs. Tal y como edité el anterior artículo, esos eran valores que equivaldrían a los datos del fichero hosts. Los DNS se ponen desde

/ip dns set listaDNSs

Añadiendo lista de servidores DNS a Mikrotik
Añadiendo lista de servidores DNS a Mikrotik
¡Ojo! La lista de las direcciones IP tiene que ir separada por una coma (,) pero sin espacios entre cada una de las direcciones. 

Además, me he encontrado con una utilidad 

/system route check DIR_IP

que te dice cuál sería el siguiente salto a nivel de direccionamiento. Por lo que si pones una dirección de fuera de la red (por ejemplo, la dirección IP de tus DNSs en internet), debería de indicarte el gateway

Según estoy viendo, existe "otro" ping. Al menos el comportamiento es distinto. En este caso, si lo ejecuto como 

/ping address=IP_2_PING

sí que responde, y además lo muestra en una lista. A diferencia que si accedo desde

/tools ping IP_2_PING

muestra sólo dos líneas con la velocidad en bps.

Por lo tanto, se puede dar por corregida esta incidencia.

Para la fecha y hora, quería configurarle un servidor NTP: 0.es.pool.ntp.org (de memoria). Pero a pesar de encontrarme con problemas para encontrar dónde se hacía, acabo de ver desde

/system clock print

que muestra la fecha, hora y timezone correctamente. Lo dejaré para más adelante (a ver si es que se han perdido utilidades al actualizar).

También es importante: no nos olvidemos de cambiar las contraseñas de los usuarios (en algún momento terminé creando alguno directamente) tanto de los nuevos como de los que vienen por defecto.

Ahora vamos al lío: voy a configurar una de las tarjetas wifi. Este es uno de los casos que he ido cambiando cosas, me he encontrado con otros problemas, etc.

Desde

/interface wireless print

vemos las tarjetas instaladas y su configuración:

Ver tarjetas inalambricas en Mikrotik
Ver tarjetas inalambricas en Mikrotik

Como podemos cometer el error de configurar la tarjeta (en mi caso va a ser la 1) sin seguridad (como me ha sucedido al configurarla y activarla) lo primero que se debería de hacer es ir a

/interface wireless security-profile

Esta sección nos permitirá crear un perfil de seguridad. Es decir: el perfil que indicará, entre otras cosas, el tipo de cifrado que se usará, la contraseña, etc. Un perfil que después se podrá asignar a la(s) tarjeta(s) que deseemos. Tendremos que buscar los distintos parámetros que necesitemos. Tipo de cifrado, clave(s) (wpa/wpa2...) el nombre que le vamos a asignar a esa configuración en concreto (para luego usarla), etc. Me he basado en lo que me indican en la wiki para adaptarlo a mis necesidades. Aunque he hecho unos cuantos cambios este debería de ser un ejemplo válido:

add name=nombre_molon mode=dynamic-keys supplicant-identity=nombre_molon_supplicant authentication-types=wpa2-psk,wpa-psk unicast-cipher=aes-ccm wpa-pre-shared-key="123abc123abc123abc" wpa2-pre-shared-key="123abc123abc123abc" management-protection=allowed

Y ahora ya podremos configurar los parámetros de la tarjeta de red. No nos olvidemos de indicarle qué perfil queremos usar para la seguridad:

/interface wireless
set 1 disabled=yes hide-ssid=yes wps-mode=disabled band=2ghz-b/g/n ssid=red_inalambrica mode=ap-bridge allow-sharedkey=no adaptive-noise-immunity=ap-and-client-mode antenna-mode=ant-a basic-rates-a/g=54Mbps
set 1 security_profile=nombre_molon disabled=no

Importante acordarse del wps-mode, que se me había quedado activado. Sólo lo pondremos si queremos reventar la seguridad que nos otorgan las claves WPA/WPA2.

Tampoco hay que olvidarse de ponerle su propia dirección IP a cada una de las tarjetas wifi con las que trabajemos. Recordemos que se hacía:

/ip address add interface=nombreInterfaz address=direccionIp netmask=mascaraRed 

No des por hecho que están puestas. Muchos cambios de aquí para allá pueden liarte. Y esto podría ser una de las razones por las que no eres capaz de conectarte a esa tarjeta de red en concreto.

Falta otro paso más: activar la comunicación entre las distintas tarjetas del sistema. Por ejemplo, entre las dos tarjetas integradas en el sistema. Eso significa que si se intenta hacer un ping de una de las tarjetas a la otra no vamos a obtener respuesta. También me he encontrado algún ejemplo (o eso parece) en el que usan NAT para hacer esa comunicación. Primero miraré cómo hacerlo con las opciones de bridge. Además, en algún caso he visto un ejemplo en el que configuraban WDS. Aunque me ha costado encontrarlo (y lo tenía en una de las páginas ya abiertas), WDS fundamentalmente convierte varios APs en un hub/switch.

/interface bridge add=nombreBridge
/interface bridge port add interface=ether1 bridge=nombreBridge
/interface bridge port add interface=wlan1 bridge=nombreBridge

Varias cosas sobre el bridge:

  • Su dirección MAC está toda a ceros en consola. En la GUI me aparece con la MAC de la tarjeta ethernet. Habrá que estudiar si se le pone una (por ejemplo, impersonalizando algunas de las que tiene el dispositivo) o si deja tal cual está.
  • He visto cómo le asignan una dirección IP al bridge (como una tarjeta más): 
/ip address add interface=nombreBridge address=ipBridge netmask=netMask comment=descripcion


Con esto he conseguido que un equipo conectado a la wifi pueda salir a Internet a través del punto de acceso. Pero no me deja(ba) hacer ping a otros dispositivos dentro de la misma red. Incluyendo desde el mismo Mikrotik. Hay que tener mucho cuidado al activar y desactivar las distintas direcciones IP que se tengan configuradas. Para solucionar este problema: buscamos en

/ip route print

Veremos que tenemos la dirección del gateway en una línea en la siguiente línea las distintas tarjetas con una sóla dirección IP. Pues fundamentalmente es como si esa dirección IP dijera por dónde va a salir. Ahí, en nuestro caso, tendremos que conseguir que ponga aquella que tiene asignado el bridge. Una forma puede ser ir a

/ip address set NUMERO_IP disabled=yes

para cada una de las que no queremos que aparezcan. Después las podemos volver a activar, pero así se fuerza a que ponga la que queremos que sea la principal. Seguro que hay otras formas, pero esta es una de ellas.

Con respecto a al cliente NTP, he tenido que hacer un ping al servicio 0.es.pool.ntp.org para obtener su dirección IP porque no me está dejando poner su URL (aunque hay vídeos donde sí se ve que se puede hacer).

/system ntp client set enabled=yes primary-ntp=193.145.15.15 server-dns-names=listaDNSs

Y ya tendríamos el equipo puesto en hora (casi) siempre en punto.

Es posible que toque hacer algún cambio más ya que la señal que me aparece en uno de los móviles para la tarjeta mini-PCI es mínima. De todas formas, para la integrada no va nada mal.

A medida que vaya solucionando estos problemas lo iré avisando. Aunque para ello tenga que mirarlo en la interfaz web o la herramienta WinBox que según entiendo al fin y al cabo parsea la interfaz web en una GUI para Windows. 

domingo, 1 de enero de 2017

Mikrotik routerboard 411UAHR II: Configuracion puerto serie

Una vez el dispositivo de Mikrotik está montado y ya tengo el cable nullmodem para conectarme (actualicé el artículo añadiendo en la lista este último), es hora de arrancar el aparatejo.

Probaré a usar como emulador de consola el putty. Y los parámetros que he indicado son:

  • Velocidad: 115200 bps
  • Data bits: 8
  • Bit de parada: 1
  • Paridad: No
  • Control de flujo: según las instrucciones, no funciona del todo bien el control de flujo. Primero probaré a no ponerlo y después veré si tira poniéndolo y después, si acaso, pongo el que nombran: RTS/CTS.
Por lo que quedaría así:

Configuración de putty para acceder al Mikrotik RB411UAHR por nullmodem/puerto serie
Configuración de putty para acceder al Mikrotik RB411UAHR por nullmodem
También es importante ir a la consola de administración de dispositivos, y mirar en la sección de Puertos (COM y LPT) para saber cómo se llama el puerto con el que vais a trabajar (yo lo tengo que cambiar).

Después vamos al árbol de Session y seleccionamos Serial:

Putty para iniciar serial en RB411UAHR
Putty para iniciar serial en RB411UAHR
Al iniciar la sesión no aparecerá nada hasta que no encendamos el cacharro. En mi caso es la primera vez que lo inicio. Y esto es lo que me ha aparecido:

Mirkrotik arrancado en puerto serie
Mirkrotik arrancado en puerto serie
Varias cosas que debería de hacer:
  • Actualizar: me sonaba haber visto que la última versión andaba por la 6 y pico. Como aparece la 5.25, toca actualizar. 
  • Presionar una tecla para acceder al setup. Además, el kernel no lo ha cargado correctamente. 
  • Mirar el usuario y contraseña por defecto. 
Por lo tanto, miraré si puedo configurarlo para que lo conecte a la red cableada y se baje automáticamente la actualización.

Para el primer acceso, usuario por defecto es admin y su contraseña vacía. En la página oficial de Mikrotik ofrecen distintas formas para acceder (entre otras las que he usado yo).

Al introducir las credenciales obtenemos:

Primer inicio de sesión en dispositivo Mikrotik
Primer inicio de sesión en dispositivo Mikrotik
Ahora hay que cambiar la dirección IP por defecto: 192.168.88.1.

Para la consola me ha costado poder acceder a la shell. Me estaba ofreciendo información pero no sabía si era para poder interactuar. Hasta que en momento determinado, la he visto. Ahora, ¿Cómo le indico qué quiero hacer? Los comandos cls, clear, help... No ayudan. Pero en el mismo instante en el que le mandamos el caracter "?" (sin comillas) nos muestra un menú. Si seleccionamos uno de los contenidos de se menú nos lleva a esa "carpeta" (actúa como tal). Y así sucesivamente:

Menú de Mikrotik
Menú de Mikrotik
Lo que no sé es qué diferencia hay entre cada uno de los colores de los elementos mostrados. Si hago un print obtengo la tabla de las direcciones IP:

Mikrotik: ip address print
Mikrotik: ip address print
Y así puedo cambiar la dirección IP:

set 0 comment "comentario" address direcionIP netmask mascaraRed interface ether1

Cambiar IP por defecto a Mikrotik
Cambiar IP por defecto a Mikrotik
Y hay que poner el gateway. Tengo mis dudas de que sea esta la opción, pero según el manual, para el entorno gráfico hay que usar éste, por lo tanto, lo daré por hecho y a ver qué pasa:

add gateway IP_GATEWAY

Configurar gateway en Mikrotik
Configurar gateway en Mikrotik
Y los DNSs, eliminando el que viene por defecto (la direccion IP que venía por defecto):

remove 0
add address IP_DNS1
add address IP_DNS2

Configurar DNSs en Mikrotik
Configurar DNSs en Mikrotik
[Inciso]
Este artículo ya lo tenía escrito, pero no publicado: esta sección realmente añade servidores DNS, sino entradas estáticas (por eso estamos en "static") al más estilo hosts. Aunque lo explicaré en el próximo artículo (esto es un auto-spoiler), la resolución de nombres se puede añadir en /ip dns set servers listaServidores
[/Inciso]

Ahora tengo que buscar dónde está el ping y una vez encontrado, conectar el cable de red.

Al ir a lo que equivaldría a /tools/ping IP_DNS_EXTERNO no obtengo resultados, por lo que el gateway no está del todo bien configurado. Resulta que haciendo más pruebas es extraño: los DNSs que siempre uso sí que me devuelven datos desde otros equipos, desde el RB no, pero sí que hay resultados con los de Google (8.8.8.8, 8.8.4.4). 

Quiero revisar los temas de las licencias, porque me da que si no lo gestiono bien, me puedo llevar la desagradable sorpresa de que se resetee él solo a las 24 horas de haberlo encendido. Pero buscando bastante me he encontrado con que con la wiki oficial dice que "los dispositivos RouterBOARD vienen con una licencia preinstalada, si has comprado un dispositivo RouterBOARD, no hay que hacer nada relacionado con las licencias". Por lo tanto, con respecto a este tema ya puedo estar tranquilo. 

Fin día 1

Día 2:

Mientras, más cosas a tener en cuenta: el reloj. Mientras estaba entrando de nuevo al sistema, me he acordado del reloj, que está desactualizado (ahora estamos en 1970). Buscando en el manual, indican que a partir de la versión 6.27 se puede hacer automáticamente (autodetect). Una vez más, la actualización ayudará mucho. Y aun así, también está el cliente ntp. 

Antes de nada: actualización (y veamos si puede descargarse las cosas teniendo en cuenta que sólo consigue hacer ping a algunas redes)

De acuerdo a lo que me indican, una actualización de todo el sistema no la puedo hacer con la consola. Por lo tanto, tiraré vía web. 

En la página oficial de descargas buscamos el modelo de nuestro dispositivo en la lista, tal y como he marcado de ejemplo en la imagen:

Paquetes de descarga de actualizaciones de Mikrotik
Paquetes de descarga de actualizaciones de Mikrotik

Después, desde la interfaz web, vamos al menú File, y seleccionamos el fichero *.npk. En mi caso, también he seleccionado el fichero .zip. Puede que hubiera sido mejor haberlo hecho en dos pasos. Nada más reiniciar se procede a la instalación:

Actualización del Mikrotik 01
Actualización del Mikrotik 01
Y el proceso:

Actualización del Mikrotik 02
Actualización del Mikrotik 02
Para que al reiniciar:

Mikrotik actualizado
Mikrotik actualizado

/system routerboard upgrade

Y al reiniciar ya lo tenemos. 

Los siguientes pasos los haré en el próximo post para evitar alargar este mucho más. Entre otros terminaré de hacer alguno de los pasos que ya he comentado y que se han quedado en el tintero.

¡¡¡Por cierto!!! ¡¡Feliz año nuevo!!