sábado, 9 de diciembre de 2017

Mikrotik routerboard 411UAHR IV: Antenas

Hace mucho, mucho tiempo (casi un año) que monté el router Mikrotik 411UAHR.

Tal y como comenté, los pigtail (MMCX/RP SMA Jack bulkhead) seleccionados no eran los adecuados:

Mikrotik Routerboard 411UAHR - Pigtail MMCX/RP SMA Jack bulkhead
Mikrotik Routerboard 411UAHR - Pigtail MMCX/RP SMA Jack bulkhead

Así, meses después (allá por abril o mayo), conseguí comprar los pigtail adecuados.

Por lo tanto, me hice con los siguientes elementos:
Este sería el material:

Mikrotik - ACMMCX y MMCX-NFemale
Mikrotik - ACMMCX y conversor RP-SMA a NFemale
Así es el conversor a NFemale de cerca:

Conversor RP-SMA a NFemale válido para la caja Mikrotik CA411-711
Conversor RP-SMA a NFemale válido para la caja Mikrotik CA411-711

Y así el pigtail:

Pigtail ACMMCX
Pigtail ACMMCX 

Por no poner otra foto con el primer resultado, nos podemos remitir a la que estoy mostrando al principio de este artículo.

Así es como queda instalado el pigtail:

Mikrotik con el nuevo pigtail sin enroscar
Mikrotik con el nuevo pigtail sin enroscar

Una vez enroscadas las tuercas, podemos conectar los conversores:

Mikrotik - ACMMCX y conversores instalados
Mikrotik - ACMMCX y conversores instalados

Puede que cueste un poco ponerlos: hay que afinar muy bien. De hecho, si no recuerdo mal, antes de poder enroscar los conversores, había que oir un pequeño "click". En caso contrario, no se podrían enroscar.

Al final, ya podremos instalar las antenas, quedando estas de una forma consistente:

Mikrotik con las antenas instaladas
Mikrotik con las antenas instaladas
Como se puede observar, no quedan colgando. Espero que esta solución al primer problema os sea de utilidad, por si os hiciese falta. 

viernes, 8 de diciembre de 2017

HoneyCon 2017

Hace unas semnas estuve en la HoneyCon 2017. Aunque estuve escribiendo el post para esta casa (expresión que si no recuerdo mal, usa Pablo (@PYDotCom), conocí a Rodolfo Miguel y me ofreció hace la crónica conjunta. Así, aquí pongo el enlace a la publicación

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.