Blockchain, por sí mismo, no es más que una implementación moderna del concepto “cadena de hashes”, autodenominada cadena de bloques. Consiste en algo tan sencillo como obtener un hash o función criptográfica resumen de un conjunto de eventos (normalmente transaccionales), de tal modo que el receptor de la transacción puede ver si los hashes concuerdan en destino y origen y, por tanto, se mantiene la integridad de la transacción. En otras palabras “que nadie ha metido mano en el proceso”.

Como supongo que os imaginareis, garantizar la integridad es realmente en muchas aplicaciones que requieren de asegurar cada paso. El mejor ejemplo serían las transacciones bancarias y, de hecho, es donde más se aplica. El problema viene cuando supuestos expertos en ciberseguridad en jornadas, desayunos empresariales, y en definitiva cualquier evento y/o “sarao” relacionado hablan y hablan de las bondades de esta “nueva” tecnología revolucionaria tiene para cualquier negocio, desde una PYME tecnológica hasta, si me apurais, una panadería.

Ante la pregunta, ¿necesito blockchain en mi negocio? La respuesta normal es un rotundo NO. No lo necesitas. Si tienes una empresa que fabrica tornillos y garantizar la integridad de tu BBDD es garantizar un excel enlazado de datos de producción recogidos a mano, es mejor que mejores tu captura de datos. Si tu BBDD está en local y no la tienes distribuidas por todo el globo, tampoco te hace falta. Y qué te igual esas supuestas bondades que “expertos” en foros están contando. No conocen ni tu negocio ni muy probablemente el concepto de cadena de hashes o alternativas – que se venían usando antes de este hype – como esquemas compartición de secretos (por cierto, inventado por un ganador del premio Turing, Adi Shamir, nada menos).

Así que ya sabéis, blockchain en bancos y procesos distribuidos críticos que necesiten una trazabilidad. Para todo lo demás, decid de primeras NO al blockchain. En algunos casos tendrán razón, pero en otros tantos no.

The post Blockchain. ¿Tecnología revolucionaria o hype? appeared first on S3lab.

En los sistemas basados en Linux, que utilizan el estándar ELF  como formato binario, la imagen del proceso se crea cargando e interpretando los segmentos especificados en las cabeceras. Pero antes de hablar sobre el proceso de carga es necesario saber que al crear un ejecutable que utiliza dynamic linking (que son la mayoría de los programas), las bibliotecas compartidas necesarias se ubican y se enlazan en tiempo de ejecución, por lo que el linker añade un campo a las cabeceras del programa del ejecutable de tipo PT_INTERP, indicando al sistema la identidad del linker dinámico (a veces también llamado intérprete) que típicamente es /lib64/ld-linux-x86-64.so.2.  Por otra parte, en el periodo conocido como link-time, el programa (o biblioteca) se construye combinando secciones con atributos similares en segmentos. Normalmente, todas las secciones ejecutables y de datos de sólo-lectura se juntan en un mismo segmento, mientras que el resto de secciones de datos y BSS (variables no inicializadas) se combinan en otro segmento. Estos segmentos típicamente se conocen como segmentos de carga porque es necesario cargarlos en memoria en el momento de la creación del proceso, al contrario que otras secciones como la tabla de símbolos (.symtab) o la información de debugging (.debug_info).

A grandes rasgos, el proceso de carga de un binario ELF se descompone en las siguientes tareas:

• 1. En primer lugar, se examinan las cabeceras para verificar que el fichero en cuestión tiene un formato ELF compatible.
• 2. Se recorren las entradas de las cabeceras del programa comprobando si se ha especificado un intérprete (PT_INTERP).
• 3. Para establecer la memoria virtual, se recorren todos los segmentos de tipo PT_LOAD en el fichero y se mapean dentro del espacio de direcciones del proceso. Después se configuran las páginas inicializadas con ceros correspondientes al segmento BSS. También se configuran otras páginas especiales como las páginas de objetos compartidos dinámicos virtuales (vDSO).
• 4. Una vez que el código del programa se ha cargado en memoria y como en este caso suponemos que utiliza dynamic linking, el ELF handler también carga el intérprete en memoria. El proceso es prácticamente el mismo que el seguido para cargar el programa original y que hemos explicado en el punto anterior.
• 5. Por último, la dirección de inicio del programa se configura como el punto de entrada del intérprete en lugar del programa en sí mismo. Esto implica que la ejecución empieza con el intérprete, que se encarga de satisfacer los requisitos de enlace del programa desde el espacio de usuario, es decir, busca y carga las bibliotecas compartidas de las que depende el programa y trata de resolver los símbolos no definidos a las definiciones correctas en dichas bibliotecas. Una vez se ha finalizado este proceso el intérprete puede iniciar la ejecución.

Para una explicación más detallada de este proceso con referencias al código del kernel por favor visitar el arituclo de LWN.net.

The post La carga de binarios en Linux appeared first on S3lab.

Me parece que se me había pasado comentaros pero…

Aunque el hacking empezó como una simple diversión para un grupo de jóvenes entusiastas, mucho ha cambiado desde entonces. Hoy en día, todos los países tienen, en mayor o menor medida, un grupo de respuesta o ataque de este tipo. Los ejemplos más claros serian la NSA y el CERT/CC (en el cual tuve la suerte de poder trabajar temporalmente) de Estados Unidos. Estamos viviendo lo que será recordado como el principio de las guerras digitales, donde los soldados usan teclados en lugar de fusiles automáticos.

Estas afirmaciones no son simples suposiciones o ciencia ficción, ya se han confirmado varios ataques de este tipo, que tenían como objetivo las infraestructuras críticas o datos de inteligencia de diferentes países. El primer caso descubierto fue Stuxnet, en 2010. La finalidad de este malware era hacer explotar los centrifugadores de Uranio de una planta de enriquecimiento nuclear de Iran, modificando los PLCs (Programmable Logic Controllers) de los mismos. Un año después, se descubrió el malware conocido como Duqu. Su objetivo en este caso no era hacer explotar nada, sino que se dedicaba a obtener información que posteriormente podría ser usada para realizar ataques similares a Stuxnet en diferentes sistemas de control industrial.

Tan solo un año más adelante, se descubrieron dos prueba más de estas batallas digitales, los malware Flamer y Gauss. Estos malware dejaban a un lado el apartado industrial y se centraban en obtener otro tipo de información privilegiada. Gauss se focalizaba en el robo de contraseñas y datos bancarios, pero Flamer iba un paso más, monitoreaba todo lo que el infectado escribía, e incluso específicamente guardaba las llamadas realizadas por Skype. Más recientemente, Ukrania ha sufrido dos ataques (Diciembre 2015 y 2016) que tiraron la red eléctrica de determinadas ciudades, utilizando el malware BlackEnergy. El último caso de este tipo apareció en 2017, que el malware Industroyer salió a la luz. A diferencia de los casos previos, este malware es altamente customizable, y permite atacar un gran número de sistemas de control industrial utilizando diferentes protocolos de comunicación.

A pesar de todos estos ataques altamente sofisticados, muchas infraestructuras criticas no están correctamente protegidas, y personas sin un alto conocimiento pueden a llegar a causar grandes problemas. Durante muchos años, este tipo de sistemas basaban gran parte de su seguridad en la conocida como security by obscurity. Principalmente, ocultaban su diseño e implementación para impedir o dificultar los ataques hacia ellos. Aunque basar tu seguridad en este concepto es completamenta incorrecto en cualquier momento, podía llegar a funcionar cuando estos sistemas estaban aislados, pero en la época de la hiperconectividad, esto no tiene ningún sentido. Actualmente existen varios buscadores de dispositivos conectados a la red, que permiten localizar sistemas vulnerables (o sin contraseña) en cuestión de segundos, sin la necesidad de realizar costosos escaneos globales.

Parece que las batallas digitales no son casos aislados, y que cada vez son más comunes. Si quieres estar preparado, te recomendamos empezar ha preocuparte por estas cosas, porque se dispararán varios unos y ceros durante las próximas décadas.

El que avisa no es traidor.

The post Cómo el hacking podría cambiar la historia appeared first on S3lab.

La instrumentación se realiza a través de un compilador JIT. Pin compila el código de la aplicación desde una ISA directamente a la misma sin pasar por una representación intermedia. Las unidades de traducción son trazas, por lo que se compila una traza cada vez, que consisten en una secuencia lineal de instrucciones que termina en: (1) una transferencia de control incondicional, (2) un número predefinido de transferencias de control condicionales, o (3) un número predefinido de instrucciones en una misma traza. El único código que se ejecuta es el generado por Pin, utilizando el original solamente como referencia, por lo que cada vez que el compilador JIT obtiene código, la Pintool (que es como se llaman las herramientas que utilizan Pin) tiene la oportunidad de instrumentarlo antes de ser traducido para su ejecución, guardando el código generado y el de instrumentación en una caché de código.

Todo el software necesario se puede descargar desde la web oficial. Una vez descomprimido, un buen punto de partida es echar un vistazo a los ejemplos disponibles en source/tools/ManualExamples entre los que se encuentra por ejemplo un contador de instrucciones: inscount0.cpp. Si nos fijamos en la función main, además de otras llamadas a funciones, la que más nos interesa en este caso es INS_AddInstrumentFunction, que recibe como parámetros un callback de instrumentación a llamar por cada instrucción y sus respectivos parámetros.

En la implementación de la función Instruction, a través de INS_InsertCall se añade una llamada a la función docount() que simplemente incrementa en 1 una variable global que almacena el número total de instrucciones.

El segundo parámetro de la llamada (IPOINT_BEFORE) resulta interesante puesto que nos permite especificar cuando insertar la llamada a docount(), siendo las alternativas IPOINT_AFTER y IPOINT_TAKEN_BRANCH, aunque en este caso IPOINT_BEFORE es la mejor opción porque solo estamos contando instrucciones. Este es el ejemplo más simple dentro de todos los que nos proporciona Intel, por lo que antes de empezar a desarrollar nuestra Pintool es recomendable examinar el resto de ejemplos.

The post Instrumentación dinámica de binarios appeared first on S3lab.

Me parece que se me había pasado comentaros pero…

Es posible acceder a cualquier contenido a través de una red diferente a la que nos encontramos inicialmente. Con un ejemplo sencillo, si inicialmente nos encontramos en España, podríamos acceder a una página web determinada como si realmente nos encontrásemos en USA. Todo esto gracias a las VPNs (redes privadas virtuales en la lengua de Shakespeare). A grandes rasgos, una VPN nos permite conectarnos a un servidor, este recibirá nuestro tráfico de red, y luego lo enrutará como si fuera el suyo propio. Por tanto, un tercero pensará que dicho tráfico tiene como origen ese mismo servidor, y no nosotros.

Originalmente, las VPNs se crearon con la intención de permitir a las personas que por cualquier situación no se encontraran físicamente en la red de la empresa (e.g., viajes), pudieran acceder a todos los recursos locales de la misma. Actualmente, sin duda ese sigue siendo uno de sus usos, pero su rango de uso ha aumentando considerablemente para el público general. Principalmente, existen dos grupos diferentes: (i) evasión de restricciones, y (ii) acceso seguro en redes hostiles.

Respecto a las restricciones, los ejemplos son claros, acceder a ciertas páginas bloqueadas a nivel empresarial/institucional o acceder a contenido bloqueado en nuestra región. Los casos de personas que usan las VPNs por seguridad, son bastante comunes también. En estas situaciones, las redes hostiles suelen ser redes públicas de cafeterías/aeropuertos o simplemente un ISP en el cual no confiamos demasiado (e.g., por prácticas de man-in-the-middle). Por desgracia, esta última situación está convirtiéndose en algo bastante común en varios países, y hay muchas personas que confían mas en su proveedor de VPN que en su ISP. Existen diferentes tipos de VPNs, pero no todos son igualmente recomendables (si buscamos seguridad y privacidad por lo menos). Comentaremos las ventajas y desventajas de los tipos mas usados en la actualidad por la mayoría de proveedores de VPN:

• PPTP: Resulta muy sencillo de configurar y está disponible de serie en casi todas la plataformas. Esas son las únicas ventajas que se me pueden ocurrir. La seguridad suele brillar por su ausencia en la mayoría de los casos, y han aparecido un gran número de vulnerabilidades desde su lanzamiento en 1999. Como última contra, resulta bastante sencillo bloquear a través de un firewall básico.

• L2TP/IPsec: Puede resultar bastante buena opción, ya que tiene una configuración relativamente rápida y, al igual que PPTP, suele estar disponible sin necesidad de ninguna instalación adicional. En el otro lado de la moneda, se encuentran las afirmaciones de Edward Snowden (que apuntan a que el standard ha sido comprometido por la NSA), y el gran porcentaje de malas implementaciones que se pueden encontrar online (usando pre-shared keys). Al igual que en el caso anterior, resulta bastante sencillo de bloquear por un firewall, ya que el número de puertos usados es relativamente limitado.

• OpenVPN: Personalmente, esta es la opción que mas recomendaría. Es muy segura, altamente configurable, puede saltarse los firewalls fácilmente y como guinda del pastel, es open source. Lo único relativamente negativo, sería el hecho de que no es nativo para la mayoría de plataformas, pero su instalación es muy sencilla y rápida, así que no es nada muy importante.

A pesar de todas las ventajas que puede traer consigo, usar una VPN puede ser peligroso también. Es importante recalcar que la única parte adicionalmente cifrada de la conexión es la de tu equipo a la VPN, una vez allí, todo el tráfico viajará de forma normal. Por tanto, no debemos olvidar que el proveedor de VPN puede perfectamente ver o incluso modificar nuestro tráfico sin gran dificultad. Generalmente, la gran mayoría de proveedores de VPN suelen publicitar que no crean logs de nada, pero hay muchos que no cumplen su palabra. Un caso bastante sonado al respecto, fue el de PureVPN, que permitió el acceso a esos «logs inexistentes» para atrapar a un stalker. Las VPNs gratuitas suelen ir un paso mas, ya que existe la sospecha, y se ha confirmado en algún caso, de que venden los datos obtenidos a terceros (con propósitos publicitarios).

Finalmente, existe la opción de montar nosotros mismos nuestra propia VPN. Hay muchísimas opciones para ello, como Algo VPN  o Openvpn-install, que permiten hacerlo de una forma bastante rápida y sencilla. Muchos habrán pensado en utilizar esta técnica para realizar algo malicioso, pero realmente tiene mas bien poco sentido, ya que generalmente se podrá acabar localizando el origen de todo si esta es la única forma de anonimización.

El que avisa no es traidor.

The post Las VPNs no son capas de invisibilidad online appeared first on S3lab.

Por lo tanto, instrumentación se refiere a la técnica que consiste en añadir código extra a un programa, normalmente con el objetivo de recoger información sobre su comportamiento durante la ejecución y enviarla a rutinas de análisis que se encargan de manipular dicha información para llevar a cabo tareas que van desde profiling, detección de errores o debugging, hasta análisis de malware.

La instrumentación se puede llevar a cabo desde distintos niveles: directamente en el código fuente, en una representación intermedia como bytecode o LLVM IR, o a nivel de binario. Como curiosidad, en los últimos años se han desarrollado varias herramientas de detección de errores como MemorySanitizer que implementan una fase de instrumentación sobre la representación intermedia en tiempo de compilación.

Por otra parte, también es importante mencionar que la instrumentación puede ser estática o dinámica. En una situación en la que solo se dispone de un binario, se puede instrumentar de forma estática mediante binary rewriting como lo hacen herramientas como PEBIL, se puede hacer de forma dinámica sobrescribiendo instrucciones en memoria por trampolines que saltan al código de instrumentación, o siguiendo el concepto de Dynamic Binary Translation (de una ISA a la misma) como lo hace Intel Pin, por ejemplo. Cada uno de los métodos tiene sus ventajas e inconvenientes dependiendo de la tarea que se quiera llevar a cabo (analizar malware tiene requisitos de transparencia que algunas soluciones no pueden cumplir) y de lo recursos disponibles (no vamos a instrumentar el código fuente si no está disponible).

The post Opciones de instrumentación de programas appeared first on S3lab.