LATEST ARTICLES

February 19th 2020

Extraer las claves wifi WPA / WPA2 con Fluxion

Número de lecturas: 952
{lang: 'es-419'}

Extraer las claves wifi WPA / WPA2 con Fluxion.

A veces, nos podemos encontrar con la situación que necesitemos averiguar las keys wifi de una red a la que (actualmente) no tenemos acceso.

Seguro que muchos conocéis la herramienta linset de vk496, muy buena para ataques MITM (main in the middle) a WPA y WPA2. Sin embargo ya tiene sus años, y no parece que el autor le apetezca actualizarla.

Estamos de suerte, una aplicación llamada Fluxion es su sucesora. Esta herramienta de auditoría de seguridad e ingeniería social, tiene menos errores y más funciones. Con ella puedes recuperar la clave WPA / WPA2 (hakear wifi), de un objetivo lanzando un ataque de ingeniería social (phishing).

 

Extraer las claves wifi WPA / WPA2 con Fluxion

Lo primero que hacemos es instalar fluxion (necesitas git).

Clonamos el repositorio de github.

Abrimos la carpeta de la herramienta Fluxion, y la ejecutamos.

El script verifica que tu sistema tiene todas las librerías, y aplicaciones (ajenas) necesarias para que Fluxion funcione correctamente. Si aparece una pantalla similar a la imagen inferior… necesitas instalar los complementos faltantes.

Ejecutar Fluxion

Ejecutar Fluxion

Note preocupes, no pasa nada, Fluxion instalará por ti todo lo necesario con el siguiente comando (si está en los repositorios de tu sistema).

 

En sololinux.es no fomentamos el pirateo, ni ayudaremos a sacar claves wifi wpa, ni claves wifi wpa2. Por tanto si has llegado a este punto del articulo es porque sabes lo que haces, y siempre bajo tu responsabilidad.

Lo que sí que podemos hacer es explicarte los pasos a seguir, son más simples de lo que puedan parecer, ya lo veras.

  • Buscar una red inalámbrica objetivo.
  • Lanzar el ataque Handshake Snooper.
  • Capturar el Handshake (apretón de manos).
  • Lanzamos el portal cautivo.
  • Necesitas generar un AP falso que imite el punto de acceso original.
  • Con un servidor DNS, se redirigen todas las solicitudes a nuestro sistema (al portal cautivo).
  • Se crea un servidor web, que solicita a los usuarios que inserten de nuevo su clave WPA / WPA2.
  • Debes desautentificar todos los clientes del objetivo para que se conecten a la AP del portal cautivo.
  • Los intentos de autenticación en el portal cautivo se verifican con el archivo Handshake.
  • Una vez tengas una clave correcta, el ataque termina de forma automática.
  • La clave se guarda y los clientes se conectaran a su AP original.

Como puedes comprobar su uso es simple. Recuerda que hackear keys wifi que no sean tuyas, puede estar penado por ley. Tu sabrás lo que haces.

Fuente:

sololinux.es

December 10th 2019

¿Qué es eso de la programación defensiva?

Número de lecturas: 744
{lang: 'es-419'}

Últimamente me he topado en varios sitios con el concepto “Defensive programming” o programación a la defensiva para los hispanohablantes y como parece que es un concepto que se está poniendo poco a poco de moda he decidido preparar un artículo hablando acerca de él. Espero que os resulte interesante y que os proporcione otra visión sobre la forma en que escribís vuestro código. Es probable que muchos de los conceptos de los que aquí hablo ya os resulten familiares; la “programación defensiva” se basa en ellos para conseguir que el código sea resiliente a los fallos que se produzcan en el futuro.

Así que sin entretenernos más vamos a adentrarnos en este concepto tan interesante de la “defensive programming”.


Programación defensiva. El concepto

La programación defensiva podemos entenderla como una forma de programar en la que el desarrollador anticipa los problemas que pueden surgir en el código. Gracias a esta previsión de la que nos dota esta metodología es posible prevenir futuros fallos y, lo que es más importante, conseguir que si finalmente acaban apareciendo, el programa no falle estrepitosamente.

Es decir, la programación defensiva no se basa en la utopía de escribir código que nunca falle, sino en la premisa de que cuando nuestras aplicaciones fallen (recuerda, nadie es infalible) el error se produzca dentro de un entorno lo más controlado posible. Si la programación defensiva fuera un dicho popular estaríamos hablando de

Caer con estilo

Para lograrlo, el código que escribamos deberá:

  • Fallar de forma segura, es decir tras el fallo no deberían quedar ficheros abiertos o bloqueados o transacciones contra la base de datos a medio terminar.
  • Fallar de forma clara, proporcionando siempre un código de error y un mensaje que explique lo que originó el fallo de modo que detectar el fallo y solucionarlo sea mucho más sencillo. Además, proporcionar una pila de llamadas e invocaciones siempre es una gran idea.

Por qué necesitamos la “programación defensiva”

Como comentaba líneas antes, cuando escribimos código nadie es infalible y, de hecho, por mucho cuidado que pongamos siempre habrá casos extremos (los conocidos casos frontera) que no hayamos tenido en cuenta y que provocarán que nuestra aplicación falle en el futuro.

Por tanto, la programación defensiva tiene algo de pragmatismo, es decir, de ayudar a tu yo del futuro a enfrentarse a problemas que hoy no estás viendo.

Este concepto de pragmatismo es desarrollado en el libro Pragmatic Programmer de Andrew Hunt y viene a proponernos que siempre:

  • Protejamos nuestro código de nuestros propios fallos y de todos aquellos que otros desarrolladores puedan provocar.
  • Validemos con tests el funcionamiento de nuestras aplicaciones.
  • Y puesto que es imposible contemplar en los tests todos los casos posibles que pueden suceder, controlemos el flujo de las excepciones y los códigos de error de cara a lograr esa “caída con estilo” de la que os hablaba antes.

Realmente esta idea de “programación defensiva” puede sonarnos a obsesión pero con los años aprendes a que no hay mejor forma de irse a dormir tras subir a producción que saber que el código está protegido contra cualquier fallo que suceda.

Photo by Ben Hershey on Unsplash

Algunas pautas para seguir la programación defensiva

Ahora que ya tenemos claro lo que es la programación defensiva quiero dejaros unas pautas que os pueden ayudar a sentiros más seguros con el código que escribáis y a seguir esta idea de “defensive programming”.

Una de las metodologías que podéis comenzar a emplear desde ya en vuestros desarrollos es TDD.

Su idea subyace en escribir siempre primero los casos de prueba unitarios para a continuación desarrollar la funcionalidad y ver si cumple las pruebas planteadas.

Por tanto, siempre tendremos una base sólida de pruebas automáticas que nos permitirán asegurarnos de que “nada se ha roto” a medida que el tamaño de nuestra aplicación crezca o refactoricemos la funcionalidad de los componentes. Si queréis, podéis pensar TDD como una metodología en la que cada componente crece en dos direcciones: funcionalidad y casos de prueba, de modo que los segundos aseguren el correcto funcionamiento del componente.

Además seguir una buena metodología TDD también nos ayudará a conseguir diseños poco acoplados pues nos obligaremos a aislar cada una de las funcionalidades cuando escribamos los casos de prueba. Esto nos permitirá tener un control mucho más detallado de cada funcionalidad y, lo que es más importante, asegurarnos de que obtenemos los resultados que esperábamos en cada llamada.

Independientemente de que sigáis la metodología TDD, es importante que revisemos siempre los casos frontera de la funcionalidad que estéis escribiendo.

Por casos frontera entendemos aquellos casos que no están dentro de la funcionalidad normal del componente sino a los que puede llegarse en determinadas ocasiones.

Por ejemplo si una función espera recibir un número natural, ¿qué sucede si le enviamos un número negativo? O si estamos trabajando con campos de texto, ¿se guardan correctamente los emojis en base de datos para us posterior visualización?

Son este tipo de condiciones o casos a las que deberemos prestar más atención cuando realicemos las pruebas ya que es aquí donde suceden la mayoría de los fallos. Por tanto, no os limitéis a preparar pruebas con condiciones esperadas (algo en lo que es muy fácil caer si no somos lo suficientemente críticos con nuestro código) sino pensad en los casos rebuscados e incluso “malintencionados” pues es ahí donde podremos detectar los puntos débiles de nuestra aplicación.

Otra forma de plantearte la programación defensiva es ponerte siempre en el peor caso. De este modo siempre estarás prevenido o alerta sobre casos que a simple vista no pueden parecer tan evidentes.

Por ejemplo, algo que me sucedió recientemente por haberme “confiado”. En el procesamiento de una llamada POST de una API todo funcionaba de forma perfecto (y pasaba todos los tests que se me habían ocurrido para esa funcionalidad) pero sin embargo, el caso más absurdo de todos provocaba fallo: un cuerpo de petición vacío.

Es por eso por lo que la programación defensiva nos insta a ir siempre con todos nuestros sentidos activos de modo que podamos anticiparnos a los futuros fallos de nuestra aplicación. Realmente, más que una metodología de trabajo como puede ser el ya mencionada TDD es una actitud ante la forma en que escribimos nuestro código con el objetivo de añadirle un extra de seguridad; es por eso que me ha resultado tan interesante: basta con tan sólo cambiar el chip para aplicarla, no se necesita ningún conocimiento especial.

Otra de las forma en las que podemos asumir esta idea de la programación defensiva es obligarnos a escribir código limpio y optimizado, de modo que su mantenimiento y la corrección de fallos sea mucho más sencillo.

Algunos consejos que nos pueden ayudar a escribir código limpio son:

  • Emplear patrones de diseño e intentar adoptar los principios SOLID en nuestros diseños. Los primeros nos permitirán resolver situaciones de una forma estándar (y optimizada) con la que la mayoría de desarrolladores ya estarán familiarizados mientras que los segundo nos ayudarán a obtener aplicaciones con bajo acoplamiento y mucho más fáciles de extender y mantener.
  • Familiarízate con el lenguaje de programación que estés empleando, no te quedes sólo en la superficie. Tómate tu tiempo en leer código de otros desarrolladores, artículos y publicaciones donde se emplee tu lenguaje favorito y descubre nuevas formas de hacer las cosas y todas las herramientas de las que dispones. Tanto Javascript como PHP están constantemente añadiendo nueva funcionalidad y recursos sintácticos para simplificar el código, por lo que no te quedes atrás.
  • Nombra bien los elementos. No hay nada como seguir una buena metodología de nombres para variables, funciones y clases a la hora de mantener el código. Si una función envía un email nómbrala apropiadamente y no recurras a nombres cortos para los elementos pensando que son más elegantes. A la larga agradecerás haber premiado que sean más descriptivos que cortos.
  • No confíes en nada ni des nada por supuesto. Muchos de los errores que suceden en el futuro se deben a dar por supuestos elementos que dependen de terceros por lo que no asumas que siempre serán correctos. Mejor prepara tu código ante posibles casos en los que no recibas lo que esperabas. Esto suele ser muy habitual en el tratamiento de datos introducidos por usuarios o en ficheros de inicialización, donde cometer fallos suele ser bastante habitual.
  • ¡DRY! Es decir, Don’t repeat your self. Evita duplicar funcionalidad por distintas partes del programa. Aíslala y agrúpala en un componente que puedas probar y que te permita realizar modificaciones en un único archivo sin tener que realizar el mismo cambio múltiples veces. Además, familiarízate con los sistemas de caché que tienes a tu disposición de cara a evitar calcular el mismo dato una y otra vez penalizando el rendimiento de la aplicación.
  • Loggea los errores. Otro de los elementos que nos ayudarán a resolver fallos futuros es loggear aquellas partes de nuestro programa que estén más propensas a fallar, de modo que, cuando finalmente se produzca un error podamos recorrer la traza de lo que sucedió y resolverlo más rápidamente.

Photo by NeONBRAND on Unsplash

Conclusiones

Como ya comentaba en un párrafo anterior, todo lo que he leído acerca de la programación defensiva me ha llevado a la conclusión de que se trata de una metodología destinada a ayudarnos a anticipar los fallos, no sólo los del presente (es decir, aquellos que encontramos a medida que desarrollamos el código) sino en el futuro de modo que, cuando se produzcan, nuestra aplicación este preparada adecuadamente para responder a ellos.

¿Verdad que no hay nada más desagradable que encontrarnos con un 500 en una aplicación web con el que no contábamos en ningún momento? Es aquí donde la programación adquiere todo su sentido y por lo que conviene tenerla en mente mientras desarrollemos. Los beneficios a la larga son realmente grandes.

Fuente:

View story at Medium.com

October 22nd 2019

Como utilizar target=”_blank” en un link con Angular

Número de lecturas: 1476
{lang: 'es-419'}

En un desarrollo estaba utilizando siempre botones para navegar pero surgio la necesidad de crear un link que se debe abrir en otra página. En este caso se debe realizar lo siguiente.

Primero se define la ruta.

//app.routes.ts

{ path: 'partido/:id', component: PartidosComponent },
Luego en el componente .html se lo detalla de la siguiente forma, donde lo que nos interesa es esto:
[routerLink]="['/', 'partido', calendario.fixture_id]"
El primer campo indica desde donde inicia la ruta en este caso desde la raiz del dominio: / , luego se detalla el nombre que se definio en la ruta en este caso: partido y finalmente el parámetro si es que se necesita: calendario.fixture_id
Se lo puede ver en funcionamiento en este sitio:
Fuente:
https://alligator.io/angular/navigation-routerlink-navigate-navigatebyurl/
October 9th 2019

Simjacker: un ataque mediante la SIM

Número de lecturas: 1124
{lang: 'es-419'}

Simjacker: vigilancia de teléfonos basada en la SIM.

Hace poco los expertos de AdaptiveMobile Security descubrieron un método de ataque en teléfonos móviles que se puede llevar a cabo utilizando una computadora normal y un módem USB barato. Mientras que algunos métodos antiguos para la vigilancia de teléfonos móviles requerían un equipo especial y una licencia operativa de telecomunicaciones, este ataque, llamado Simjacker, se aprovecha de una vulnerabilidad encontrada en las tarjetas SIM.

Todo se debe a S@T Browser

La mayoría de las tarjetas SIM que se han puesto a la venta desde principios del 2000, incluidas las eSIM, incluyen un menú sobre el operador. Este menú ofrece información sobre el saldo, opción de recarga, soporte técnico y, a veces, funciones adicionales como el tiempo o, incluso, el horóscopo. En los teléfonos antiguos aparece en el menú principal. Por su parte, iOS lo esconde en los ajustes (en Aplicaciones SIM) y en los teléfonos Android se trata de una aplicación llamada SIM Toolkit.

El menú es básicamente una aplicación (en concreto, varias aplicaciones con el nombre SIM ToolKit [STK]), pero estos programas no se ejecutan en el mismo teléfono, sino en la tarjeta SIM. Recuerda que tu tarjeta SIM es una computadora diminuta con sistema operativo y programa propios. STK responde a comandos externos, por ejemplo, al presionar un botón del menú del operador, y hace que el teléfono ejecute ciertas acciones, como enviar mensaje SMS o comandos USSD.

Una de las aplicaciones que incluye el STK se llama S@T Browser y se utiliza para ver páginas web de un cierto formato y páginas ubicadas en la red interna de la operadora. Por ejemplo, S@T Browser puede suministrar información sobre el saldo de tu cuenta.

La aplicación S@T Browser no se ha actualizado desde el 2009 y, aunque en los dispositivos modernos sus funciones las ejecutan otros programas, S@T Browser se sigue usando de forma activa o, al menos, sigue instalada en muchas tarjetas SIM. Los investigadores no han mencionado las zonas geográficas ni las empresas de telecomunicación en concreto que venden tarjetas Sim con esta aplicación instalada, pero aseguran que hay más de mil millones de personas repartidas en no menos de 30 países que las utilizan, y es precisamente en S@T Browser donde se encuentra la vulnerabilidad de la que estamos hablando.

Los ataques Simjacker

El ataque comienza con un mensaje SMS que contiene una serie de instrucciones para la tarjeta SIM. Siguiendo estas instrucciones, la tarjeta SIM solicita al teléfono móvil su número de serie y el identificador de celular de la estación base en cuya zona de cobertura se encuentre el suscriptor y envía un SMS de respuesta con esta información al número del atacante.

Las coordenadas de las estaciones se conocen (e incluso están disponibles en línea), por lo que el identificador de celular se puede utilizar para determinar la ubicación de los suscriptores que se encuentren a menos de unos cien metros. Los servicios basados en la ubicación dependen del mismo principio para determinar la ubicación sin asistencia satelital, por ejemplo, en interiores o cuando el GPS esté desactivado.

El usuario no se percatará de ningún tipo de manipulación que se realice en la tarjeta SIM. Ni los mensajes SMS entrantes con comandos, ni las respuestas con los datos de la ubicación del dispositivo aparecen en la aplicación de mensajería, por lo que es muy probable que las víctimas de Simjacker ni siquiera sepan que alguien las está espiando.

¿A quién ha afectado Simjacker?

Según AdaptiveMobile Security, los espías han estado rastreando la ubicación de usuarios de varios países no especificados. Y en uno de esos países, terminaron comprometidos entre 100 y 150 números al día. Como norma general, estas solicitudes se suelen enviar solo una vez a la semana; no obstante, los movimientos de algunas víctimas están mucho más monitoreados. De hecho, el equipo de investigación descubrió que varios usuarios recibían cientos de SMS maliciosos a la semana.

Los ataques Simjacker pueden ir mucho más lejos

Los investigadores han descubierto que los cibercriminales no usaban todas las funciones que ofrecía S@T Browser en la tarjeta SIM. Por ejemplo, el SMS se puede utilizar para hacer que el teléfono llame a cualquier número, envíe mensajes con un texto aleatorio a números arbitrarios, abra enlaces en el navegador o, incluso, desactive la tarjeta SIM, dejando a la víctima sin teléfono.

Esta vulnerabilidad da lugar a posibles y numerosas situaciones de ataque, donde los criminales pueden transferir dinero por SMS a un número de cuenta, llamar a números de pago, abrir páginas de phishing en el navegador o descargar troyanos.

Esta vulnerabilidad es especialmente peligrosa porque no depende del dispositivo en el que se inserte la tarjeta SIM vulnerable, sino que el conjunto de comandos STK está estandarizado y es compatible con todos los teléfonos e, incluso, con los dispositivos IdC con SIM. Para algunas operaciones, como realizar una llamada, algunos dispositivos solicitan la confirmación del usuario, pero muchos otros, no.

¿Cómo puede un usuario evitar los ataques Simjacker?

Por desgracia, no existe ningún método independiente para que los usuarios eviten los ataques de tarjeta SIM. Es responsabilidad de las operadoras móviles garantizar la seguridad de sus clientes. Sobre todo, deberían evitar utilizar aplicaciones de menú de SIM desactualizadas, además de bloquear los códigos SMS que contengan comandos peligrosos.

Pero también hay buenas noticias. Aunque no se necesita ningún hardware caro para ejecutar el ataque, sí requiere amplios conocimientos técnicos y capacidades especiales, por lo que es poco probable que cualquier cibercriminal pueda utilizar este método.

Además, los investigadores notificaron al desarrollador S@T Browser, SIMalliance, sobre la vulnerabilidad y, como respuesta, la empresa expidió una serie de directrices de seguridad para los operadores que utilizan la aplicación. Los ataques Simjacker también se notificaron a la Asociación GSM, una organización internacional que representa los intereses de los operadores móviles de todo el mundo. Por tanto, se espera que las empresas tomen todas las medidas de protección necesarias en cuanto tengan la oportunidad.

Fuente:

kaspersky.com