sábado, 30 de marzo de 2013

#RootedCon 2013 (2)

¡Saludos!

   Cuando esteis leyendo esto probablemente ya estaré en Almería, maldiciendo en arameo por no tener una conexión en internet. Continuemos por donde lo habíamos dejado... segundo día, viernes.


    El viernes empezó bien fuerte con los hermanos Tarasco de la empresa Tarlogic , que era patrocinador plata del evento. Qué puedo decir de estos dos cracks. Ya los conocía por algunas de sus herramientas y reportes de vulnerabilidades que había visto por ahí, pero verlos en acción sólo hizo incrementar mi fascinación por ellos. La charla "OWISAM - Open Wireless Security Assesment Methodology" iba enfocada a mostrarnos un protocolo a seguir a la hora de realizar auditorías a redes Wifi. Ellos mismo lo definieron como un OWASP pero de la seguridad en las comunicaciones inhalambricas. Es un proyecto abierto en el cual todos podemos colaborar de alguna forma y que podemos ver aquí .


    Además tambíen mostraron una herramienta que tuvieron que crear desde 0 para auditorías wifi. La herramienta, "Wireless Audit Framework", es una joya. Por lo que nos mostraron allí, deja a inSSIDer a la altura del betún. Geolocalización, Análisis de cobertura, Análisis de riesgos basándose en la metodología OWISAM, etc.


    Después Jesús Olmos (@Sha0coder) nos mostró la herramienta en la que está trabajando, "ChromeHack", un plugin para Chrome destinado a las auditorías de seguridad web. Me gustó bastante la pinta que tenía. Permite interactuar con la web enviando los parámetros desde un diccionario. De esta forma podemos hacer fuzzing aplicado a distintos objetivos. Por ejemplo, en el caso de un login podemos hacer fuerza bruta, o en el de un buscador podemos lanzar un diccionario con distintas SQLi para ver por donde peta (esta idea de usar diccionarios y después que sea el usuario quien decida qué contiene el diccionario la voy a usar en "Bacillus", la herramienta en perl que estoy desarrollando actualmente, fue una auténtica inspiración ver esta charla x'D). 

   Para discriminar peticiones que han dado resultado la herramienta implementa funciones estadísticas (Gauss). Un plus que tiene la herramienta es la facilidad con la que se puede manejar. Una vez que tienes activo el plugin pudes clickar, por ejemplo, sobre un formulario y seleccionar un diccionario con el que fuzzearlo.


    Tras el descanso, las ponencias se reanudaron con David Barroso (@LostinSecurity ) y su "Gentil viaje al interior de las extorsiones mediante DDoS". La charla fue muy amena, con momentos de risa (como el vídeo de el Gwapo y su servicio de DDoS). En líneas generales se estuvo comentando cómo funcionan las mafias que se dedican a pedir un dinero a cambio de que no te tumben la web por un tiempo indefinido. También se habló de la implantación del Malware as Service, donde pagando una tarifa contratas los servicios, de por ejemplo una botnet por horas.  O pagar por descargar exploit dentro de un exploitpack.

  Algo de lo que me dí cuenta es en esta charla es que los foros están muy controlados. Se sabe perfectamente qué se mueve por la mayoría de los foros underground. 

  El siguiente en liza fue Sebastían Guerrero (@0xroot) que es un clásico en estas ponencias. Nos estuvo hablando de sus últimas investigaciones en terminales android. Ya vereis la charla cuando salga (como ya sabreis yo no uso smart phones, asi que en esta charla, junto con otra del sábado estuve bastante perdido).

   Para cerrar la tarde del viernes tuvimos charla de Jose Luis Verdeguer ( @Pepeluxx ) que nos habló de seguridad en FreePBX (y asterisk) y de posibles ataques a realizar, y por último Roberto Baratta que nos habló de eFraude


5 0verl0ad Labs: marzo 2013 ¡Saludos!    Cuando esteis leyendo esto probablemente ya estaré en Almería, maldiciendo en arameo por no tener una conexión en internet. C...

viernes, 29 de marzo de 2013

Codificación doble para evadir filtros

¡Saludos!

      Lo primero es avisaros de que voy a volver al desierto en semana santa, asi que no sé si tendré acceso a internet, por lo que voy a intentar escribir entre esta noche y mañana algunos posts (como los resúmenes de los días 2 y 3 de la rooted) y dejar la publicación programada. Como no me fío, voy a probar primero con este post, a ver qué tal funciona lo de programar la publicación. Y una vez dicho esto, pasemos  a lo interesante.



     Este truco para evadir filtros es muy viejo (creo recordar que hasta salía en la vulne de IIS que explicaban en las primeras revistas Hack X Crack) pero nunca está de más volver a traerlo de vuelta para meterlo en nuestro arsenal de métodos de bypassing.

      En ocasiones nos encontramos que una petición que nosotros enviamos a una web es procesada de forma secuencial por distintas entidades. Primero nuestra petición es procesada por una de esas entidades, y el resultado es enviado a una segunda entidad que lo procesa, y así sucesivamente. Por poner un ejemplo, en el caso de un login en PHP, si simplificamos, podemos ver que primero mandamos una petición por el protocolo HTTP, la cual es resuelta en el servidor, y éste envía el resultado al script PHP, que volverá a procesarla, y de ahí a la base de datos. Si todo esto era una petición POST, en la cual pasábamos las variables user y password, el contenido de dichas variables ha sido procesado en cada etapa.


   Con la doble codificación lo que se pretende es que alguna estapa en la que es procesada la petición se decodifique y ejecute lo que queramos. Por ejemplo, imaginemos que tenemos un WAF que detecta los XSS. Podemos intentar meter una doble codificación, de tal forma que el WAF no detecte que se trata de un intento de XSS (por que esta condición no está asignada en las reglas). Despues de pasar sin problemas el filtro, será decodificado y se ejecutará nuestro XSS. De forma esquemática:

Enviamos esta petición:

Dependiendo de la configuración de las reglas, o de cómo sea el filtro empleado, no será detectado y el contenido se enviará a una primera entidad (el propio servidor, por ejemplo) que decodificará el contenido:
Y ahora esto le llega a la aplicación web que lo mostrará, de tal forma que ya incluiría nuestro XSS.

   Esta técnica como ya dije es muy vieja, pero sigue estando viva, sobretodo para explotar vulnerabilidades de Path Traversal, donde cuando intentamos mandar una petición con ../  no lo conseguimos porque el servidor lo interpreta antes de que llegue a la aplicación vulnerable.


Byt3z

PD: si a alguien se le da bien el diseño gráfico y quiere diseñar un logo para la herramienta que estoy codeando, que envíe un correo a la dirección del blog, o me contacte vía Twitter.
5 0verl0ad Labs: marzo 2013 ¡Saludos!       Lo primero es avisaros de que voy a volver al desierto en semana santa, asi que no sé si tendré acceso a internet, por lo ...

martes, 26 de marzo de 2013

Ayuda con un proyecto (I need you)

Saludos,

***********************************
Editado: Gracias a      he encontrado un módulo llamado Sniffer::HTTP que hace lo que yo necesito. En concreto en la documentación oficial muestran un script llamado "Live-HTTP-Headers.pl" (se encuentra en CPAN, facil de localizar :P)  que hace EXACTAMENTE lo que yo no podía. Asi que me ha venido como anillo al dedo.  También doy gracias a toda la comunidad en general, por haberme bombardeado a ideas, se agradece un montón
*********************************

 
      Quiero codear una herramienta para auditorías que me permita torturar jugar con el protocolo HTTP. La cuestión es que estoy intentando implementar un sniffer para el puerto 80, cosa que debería de ser bastante sencilla. Pero no, me estoy topando con un problema que no consigo solventar de forma alguna. He preguntado en distintos foros especializados en PERL, he llamado por teléfono a un par de conocidos que suelen usar PERL para sus tareas, y nada. Nadie consigue darme una solución para un problema tan sencillo. ¿Y cual es mi problema?


      Mi problema es que cuando recibo las cabeceras procedentes del servidor también se me cuela el contenido HTML, o si se trata de una imagen, su source (que son caracteres rarunos, como es lógico). Y yo lo único que deseo son las cabeceras (y si hay contenido POST, pues lo que se envíe). Lo primero que pensé fue: "esto es fácil, si no mal recuerdo al final de las cabeceras viene el doble CRLF, asi que me hago un regexp que me lo localice borro el resto". Fácil mis cojones. Por algún oscuro motivo que no consigo descubrir, no chutaba. Asi que tiré del plan B: cojo todo lo que viene encapsulado por el puerto 80, y me hago un array con split(), usando como referencia el doble CRLF, de tal forma que me quedo con la primera parte (que en teoría correspondería a las cabeceras) y descarto el segundo elemento que en teoría contendría "la basura" que no quiero. Mis cojones.

      De forma aleatoria a veces funcionaba, a veces no. En este momento me planteé que quizás no siempre se usase el doble CRLF, sino que por algún retorcido motivo no se ajustasen a ese estándar, asi que lo que hice fue imprimime por pantalla todo y cuando encontrase un doble CRLF me lo susitutyera por un "xxxx". De esta forma podría ver en pantalla un "xxxx" por cada doble CRLF que me enviasen. Y... siempre aparecía. Incluso cuando me colaba "basura" (el documento HTML, el source de las imagenes....) aparecía el "xxxx". Asi que no sé porqué diablos no me funcionaba mi idea de hacer split().


     A continuación tiré de una idea más sucia: pasar todo lo que sacaba del paquete sniffado, trocearlo linea por línea, y si encontraba en una línea un "xxxx" (que estaba sutituyendo los dobles CRLF) rompiera el bucle con un GOTO.


   Esta idea parecía buena... y en la mayoría de los casos me funca, pero aun así hay veces que no. Adjunto aquí algunas capturas:


   En esta primera captura vemos que el método "sucio" de filtrado funciona perfectamente, y me saca las cabeceras (tanto del cliente como del servidor) perfectamente. Sin embargo si continúo navegando, me encuentro con cosas como esta:

  Ahí se pueden ver que se ha colado parte del source de una imagen, cuando no debería de aparecer. El código fuente del PoC para sniffear es este de aquí . Necesitais descargar libpcap (y libpcap-dev) para poder instalar los módulos de perl que os hacen falta. Y ejecutarlo como root para poder tener acceso a las interfaces de red.


  En fin, ya que absolutamente nadie me ha podido ayudar, espero que algún lector se le ilumine la bombilla y me eche una mano, porque estoy desesperado. Si se os ocurren ideas, posteadlas en los comentarios, o pedime mi skype por twitter y charlamos. Cualquier idea, por pequeña o estúpida que sea (joder, más estupida que usar GOTOs no puede haber x'D), es bien recibida, no tengais miedo.


Byt3z

5 0verl0ad Labs: marzo 2013 Saludos, *********************************** Editado: Gracias a   @ mjimeneznet    he encontrado un módulo llamado Sniffer::HTTP que hace...

lunes, 25 de marzo de 2013

Phishing - Un ejemplo universitario


  En una sociedad donde el phishing está a la orden del día moviendo ingentes cantidades de dinero es muy importante para los ciberdelincuentes tener grandes cantidades de cuentas de correo a la espera de recibir su ciber basura.

  En esta entrada, siguiendo el ejemplo de las añejas "Un ejemplo universitario", voy a mostrar como un atacante con malevolas intenciones puede obtener direcciones de correo válidas de todos los alumnos de la universidad. Además también tendrá al alcance información como su nombre y carrera que cursa. Con estos datos ya es posible crear perfectas estafas con falsas ofertas de trabajo personalizadas y empezar a difundir "trabajo", empecemos:


  """
  Somos un estudiante que conoce los recursos que ofrece nuestra universidad y sabemos que ésta tiene una página accesible a cualquiera mediante la que se puede buscar información de los usuarios. En ella existe un formulario para especificar más la búsqueda siendo posible buscar usuarios por nombre, correo, o su titulación:


 Al realizar una simple búsqueda, por ejemplo "titulación = ingenieria informatica", vemos que se los listan todos los usuarios matriculados en dicha carrera:


 Además se puede acceder a la información de cada alumno por separado ofreciéndonos valiosos datos como los comentados antes, entre ellos su correo electrónico:


 Nosotros, usuarios conocedores de los peligros de la red, sabemos que esta situación es perfecta para lanzar una campaña de phishing por toda la universidad y de forma personalizada, pues podemos ofrecer, por ejemplo, ofertas de trabajo a determinadas carreras, especificando además el nombre del usuario a que va dirigido. Es decir, al hacerlo mas personal el correo aumentamos enormemente las posibilidades de que la inocente víctima caiga en nuestras redes.

 Para aumentar las víctimas del ataque seria necesario conocer todas las carreras disponibles, información que la aplicación también nos proporciona, ¡¡ES PERFECTO!! :


 Ahora ya siendo conocedores de todos estos vectores de ataque, podríamos crear una aplicación que carrera a carrera fuera realizando búsquedas y "clasificando" a los usuarios mediante su nombre, correo y titulación en una base de datos para tenerlos accesibles de forma más directa. Aquí entra en juego el lenguaje más serpenteante, Python.


  Una vez están los usuarios almacenados en la base de datos, mediante simples consultas obtenemos los datos necesarios para realizar nuestro perverso ataque:



  Tenemos la información, pero ahora, ¿cómo la aprovechamos? Acudiendo en nuestra ayuda tenemos  S.E.T. que nos ofrece un framework para ataques de ingeniería social, con lo que, aprovechando la nueva relase del Backtrack Team (Kali Linux) vamos a trastear con la herramienta.

  Primero escogemos Social-Engineering Attacks pues es lo que vamos a intentar hacer engañando a nuestra inocente víctima:


  Acto seguido nos preguntará por el tipo de ataque, marcamos la quinta opción Mass Mailer Attack:


  Ahora se nos ofrece la posibilidad de atacar a una única víctima o varias a partir de un fichero. Puesto que nuestra genial aplicación en Python nos permite exportar a ficheros los correos obtenidos, el segundo camino es el seleccionado (E-Mail Attack Mass Mailer):


 Para acabar introducimos la localización del fichero con los correos, una dirección válida ya sea de gmail o nuestro propio servidor de correo, con lo que ya estaremos en disposición para especificar los datos del mensaje y enviarlo:



  Con esto solo nos quedará esperar que nuestros inocentes destinatarios caigan en nuestro malvado y sombrío ataque.

"""

  En resumen, el phishing es un problema presente en nuestros días y va a estarlo durante mucho tiempo debido a que no es fácil erradicarlo. Desde mi punto de vista hay que educar a los usuarios, no puede ser que para advertirles de los peligros utilicemos métodos tan "avanzados" como este que muestra una captura de Jose Selvi. Hay que enseñarles, aunque sea mediante créditos de libre elección, pues en nuestros días todos los estudiantes utilizan Internet pero ni una cuarta parte es consciente de como hacerlo correctamente, peligros como los puntos de acceso falsos, el uso de https, actualización del sistema y su software (no puede ser que los ordenadores de toda la facultad, en los que los profesores introducen sus datos para dar clases utilicen una versión de nuestro colega Java de hace más de un año) y así un gran etc de conceptos básicos que deberíamos conocer todos los que nos movemos en la red de redes.

 Con todo esto me despido, nos leemos en breve ;)


5 0verl0ad Labs: marzo 2013   En una sociedad donde el  phishing  está a la orden del día moviendo ingentes cantidades de dinero es muy importante para los ciberdelinc...

viernes, 22 de marzo de 2013

#RootedCon 2013 (1)

¡Saludos!

       Ya poco más se puede decir sobre la Rooted, celebrada del 7 al 9 de Marzo en Madrid, porque todos los blogs han hablado de lo que allí se hizo, en mayor o menor grado. En mi defensa, he de decir que desde el doming 10 hasta el jueves de la semana pasada estuve enfermo, MUY enfermo, hasta el punto de que el jueves me tuvieron que ingresar. Ya estoy recuperado, asi que tengo tiempo (y ganas) para poder escribir por aquí y trastear.


      A parte de las charlas, que me han impresionado, lo que más impacto me ha dejado de la experiencia ha sido la cercanía de los ponentes a la hora de conversar, y no sólo  los ponentes, sino  todo el mundo en general. He "desvirtualizado" muchos rostros, demasiados nicks para poner sin que se me olvide alguno.

  ------------------------------------------------------------------------------------------------


        El primer día de la Rooted Con llegué temprano, bastante más temprano de lo que debería (es lo que tienen que te saquen de un pueblo y vayas sólo por la capital, que no calculas bien los tiempos y las distancias), asi que me tocó esperar un buen rato desde que me registré hasta que empezó el "Keynote" (o lo que de toda la vida hemos llamado presentación). A la hora de registrarte y darte la identificación del congreso también daban un par de regalos: una mochila, un bolígrafo, una libreta (bastante útil para apuntar cosas, y hacer mapas a prueba de alcoholizados para volver a casa), un muñeco de la mascota de Snort y unos guantes (para cuando nos toque vivir debajo de un puente).


     Tras el Keynote vino la primera charla, a manos de David Fuertes, que trataba sobre lo que él denominaba como "Señales Débiles". En resumidas cuentas por Señales Débiles hacía referencia a rastros y comportamientos extraños, que se salen de la norma, y que pueden alertar de que se está bajo un APT. Por ejemplo, si un usuario que nunca ha entrado a los servidores derrepente empieza a conectarse y ha hacer peticiones inusuales en él, puede ser un indicio de que alguien ha podido pivotar dentro de la red y está usando ese usuario.

    En este caso la estadística y el estudio continuado del comportamiento dentro de la corporación es importantísimo para poder establecer reglas que nos permita discriminar de forma rápida entre peticiones legítimas y peticiones que puedan corresponder con un ataque, o que sean un rastro de uno. De tal forma que si conocemos cuales son el tipo de peticiones "normales" y detectamos aquellas que se salgan de lo habitual podamos activar las alertas y revisar si algo está pasando.


   La anécdota de esta charla fue el "efecto demo" que boicoteó la parte "práctica", y no se pudo ver la demo que tenía preparada con CrimePack.



    La siguiente charla de la mañana corrió a cargo de Vicente Díaz (@Trompi), "Birds, bots and machines". En esta ponencia nos descubría el trabajo que había estado realizando haciendo tracking de los bots que aparecían en distintas campañas dentro de Twitter, recopilando una ingente cantidad de información, y estableciendo qué parámetros son más interesantes a la hora de detectar un bot. Esto lo hacía aplicando tratamiento estadísticos a todos los datos recogidos. Posteriormente todo esto lo relacionó con IA.


   Tras el descanso tocó la charla de José Miguel Esparza (@EternalTodo) y Mikel Gastesi (@Mgastesi)
en la que nos hablaron del eCrime  y las botnets, en concreto de Sopelka y Eurograbber. Muy interesante la charla, no os la voy a destripar porque creo que merece la pena el repaso que le meten a Check Point y su informe de chiste sobre Eurograbber.


    La última charla de la mañana fue más por términos económicos, "¿Y si la seguridad afectara al valor contable de la empresa",  a manos de Antonio Ramos.



        La jornada de tarde la abrieron los chicos de Flu-Project (el otro blog donde colabora Aetsu), donde mostraron su herramienta Flu-AD que están empezando a utilizar algunos gobiernos para investigar casos de pederastia. La herramienta tiene una pinta tremenda: pesa sólo 50Kb y para evitar los AV puede cargar los módulos que vaya necesitando se les pasa directamente a la RAM. A parte, todo viene en relación con Metasploit.


    Después Alejandro Ramos (@Aramosf ) nos estuvo hablando sobre cómo funciona SQLite y cómo si no se utiliza la opción "Vacuum" los datos pueden ser extraídos con relativa facilidad. Para la demo pidió algún voluntario para extraerle los datos de la base SQLite de Whatsapp, pero al final todo resultó ser un tongo :(. El "voluntario" estaba ya preparado previamente para hacer el chiste. Igualmente fue divertido.

    La última charla de la tarde para mí fue divertidísima, y fue la de David Meléndez Cano (@TaiksonTexas). Algo más alejada del tema de la seguridad, pero merece la pena ver el video de la presentación. ¡Un artísta! Un router transformado en un todoterreno , y una fonera en un drone. Todo ello (salvo algunos detalles como los motores creo recordar) a partir de trastos que tenía por casa, como los mandos de la Wii. Tuve el placer de alcoholizarme charlar con él en la fiesta, y de verdad, una de esas personas con las que merecen la pena echar un rato.


   Hasta aquí este pequeño resumen del primer día

Byt3z ;)


5 0verl0ad Labs: marzo 2013 ¡Saludos!        Ya poco más se puede decir sobre la Rooted, celebrada del 7 al 9 de Marzo en Madrid, porque todos los blogs han hablado d...

miércoles, 20 de marzo de 2013

Acechando routers

  Cuando se quiere acceder a un router sobre el cual no se conocen las credenciales, bien sea porque, (en un hipotético caso) nos encontramos en una red ajena o hemos encontrado algún suculento objetivo mediante la herramienta Shodan, tenemos un par de alternativas para proceder.

 La primera opción seria buscar, si en un descuido del dueño o administrador, no se ha cambiado el dúo usuario/contraseña de acceso y continúan siendo vigentes los parámetros de fábrica. Para probar esta posibilidad basta con ir a una web como RouterPasswords.com y conociendo el fabricante obtener los datos necesarios:




  La segunda opción seria aprovecharse de una vulnerabilidad en el firmware del router para obtener acceso a éste. En este tipo de situaciones entra en juego RouterPWN que en forma de página web incluye una enorme cantidad de exploits para gran tipo de modelos de router, todo ello ordenado en función del fabricante:


   Su funcionamiento es muy simple, basta con pulsar en el fabricante del dispositivo objetivo y apareceremos en su respectiva sección junto con todos los exploits disponibles de este proveedor. Éstos están ordenados por fecha y acompañados de una breve descripción de su funcionamiento:


   Su funcionamiento es muy sencillo, solo hay que pulsar en [IP] para que nos salga un dialogo donde pondremos la dirección del router y a continuación se lanzará el exploit:


  Si queremos obtener mas información sobre el exploit o el código de éste debemos pulsar en [+] y seremos redireccionados a su fuente, un ejemplo:



  Uno de los impedimentos que puede surgir a la hora de lanzar un ataque de este tipo es desconocer el fabricante del router, pero en routerPWN tenemos un enlace que introduciendo la dirección MAC del dispositivo nos mostrará su fabricante, todo esto a partir de su respectivo OUI:






  También existe una versión móvil routerPWN para Android, la podemos obtener de la siguiente dirección:
https://play.google.com/store/apps/details?id=websec.routerpwn

 o bien mediante un código QR:


  Una vez descargada veremos que básicamente es la aplicación web empaquetada en una aplicación para Android, pues su interfaz y utilización son similares a la versión web:






 Por último para cerrar la entrada os dejo el vídeo de la presentación de la herramienta en la GuadalajaraCON del 2012:




 Y esto es todo, nos leemos en breve ;)


5 0verl0ad Labs: marzo 2013   Cuando se quiere acceder a un router sobre el cual no se conocen las credenciales, bien sea porque, (en un hipotético caso) nos encontramo...

lunes, 11 de marzo de 2013

Cifrando particiones en ArchLinux



  Hace unos días me surgió la necesidad de formatear  porque me aburría la partición de GNU/Linux del netbook e instalar ArchLinux. Gracias a la sabiduría obtenida del podcast de @DaboBlog he desarrollado la costumbre de cifrar las particiones de mi pequeñín (el netbook), puesto que pasa todo el tiempo de un sitio para otro.

  En este punto me dirigí a la web que utilizaba como referencia, con lo que me dispuse a realizar todo el proceso cuando me encontré con un ligero contratiempo debido a la evolución de la distribución linuxera que utilizaba.
  Arch es una distro rolling release que evoluciona constantemente, con lo que el proceso de instalación ha cambiado respecto al del post que seguía y el sistema de arranque también, ya que ahora utiliza el famoso y raudo systemd. Con todo esto en mente me dispuse a realizar el proceso combinando el antiguo post, la wiki y la genial guía de instalación de Arch del Sr @Gespadas.

  Para realizar el cifrado comentado nos serviremos de LVM, con lo que el disco duro quedará dividido en 2 particiones dedicadas a Windows 8, una para el boot de Arch y la restante para el LVM que, éste a su vez, contendrá dos particiones para GNU/Linux como son la raiz y la memoria swap. Por tanto el particionado quedará como sigue:
  [+] /dev/sda1 -> Partición arranque de W8.
  [+] /dev/sda2 -> Partición para W8.
  [+] /dev/sda3 -> Partición boot.
  [+] /dev/sda4 -> LVM para Ñu/Linux.



Cifrando...

  Es recomendable sobrescribir todo el disco duro para que la información existente anteriormente "desaparezca", este proceso podemos realizarlo con dd, aunque tarda bastante tiempo (en función del tamaño del HD):
dd if=/dev/urandom of=/dev/sda
 /dev/sda es el disco duro que se desea borrar, en vuestro caso puede variar, tenedlo en cuenta ya que os podéis reír mucho si os cargáis el que no toca ;)

  Una vez esté todo borrado (o no), vamos a cargar el módulo necesario para cifrar el HD, para ello:
modprobe dm-crypt
  Acto seguido aplicamos el cifrado sobre la partición /dev/sda4:
cryptsetup -c aes-lrw-benbi -y -s 384 luksFormat /dev/sda4
  Una vez hayamos introducido la contraseña deseada podremos continuar con el proceso.

  Puesto que la partición ya se encuentra cifrada, debemos acceder a ésta:
cryptsetup luksOpen /dev/sda4 lvm
   Y procedemos a crear el grupo de volúmenes lógicos:
lvm pvcreate /dev/mapper/lvm
lvm vgcreate vgroup /dev/mapper/lvm
  A continuación definiremos las particiones dentro del grupo especificado antes (vgroup). El tamaño de cada uno viene a gusto de cada uno ;) :
lvm lvcreate -L 2GB -n swap vgroup
lvm lvcreate -l 100%FREE -n root vgroup
  En mi caso le he dado 2 GB a la memoria swap y el resto que quede libre para la partición root (en el netbook no separo home).



Instalando ArchLinux

  NOTA: Estos pasos los voy a definir muy ligeramente, en la guía de Gespadas y en la Beginners' Guide de Arch está todo infinitamente mejor explicado, yo solo me centraré en lo que cambia de una instalación norma a una instalación cifrada.


  Con las particiones definidas, vamos a particionarlas.
[+] La partición boot:
mkfs.ext2 /dev/sda3
[+] Cuando vamos a dar formato a la partición root es donde encontramos la primera diferencia a una instalación normal, pues ahora no trabajamos con /dev/sdaX, sino con /dev/mapper/vgroup-root:
mkfs.ext4 /dev/mapper/vgroup-root
[+] La partición swap es similar a la interior pues también se encuentra en el vgroup:
mkswap /dev/mapper/vgroup-swap
  y la activamos:
swapon /dev/mapper/vgroup-swap

 A continuación montamos las particiones, teniendo en cuenta que la partición root no es /dev/sdaX:
mount /dev/mapper/vgroup-root /mnt/
mkdir /mnt/boot
mount /dev/sda3 /mnt/boot/

  En el siguiente punto toca configurar la red. Puesto que no tiene sentido tratarlo en esta entrada la wiki de Arch será vuestra guía :D
https://wiki.archlinux.org/index.php/Beginners'_Guide#Establish_an_internet_connection
 Con conexión a la red de redes procedemos a instalar la distribución:
pacstrap /mnt base base-devel grub-bios
 Generamos el fichero fstab:
genfstab -p /mnt >> /mnt/etc/fstab
 Nos metemos en la jaula con chroot:
arch-chroot /mnt
 Cambiamos el nombre del equipo:
echo "nombre" >> /etc/hostname
La zona horaria:
ln -s /usr/share/zoneinfo/Europe/Madrid /etc/localtime 
 Configuramos la localización:
echo "LANG=es_ES.UTF-8" >> /etc/locale.conf
locale-gen
El teclado:
echo "KEYMAP=es" >> /etc/vconsole.conf 
Y ahora instalamos el grub:
grub-install /dev/sda 
 A continuación vamos a especificar un par de parámetros en la configuración del grub para que monte correctamente las particiones cifradas:
nano /etc/default/grub
  Buscamos la línea que ponga:
GRUB_CMDLINE_DEFAULT="quiet"
 y añadimos:
cryptdevice=/dev/sda4:vgroup

 Acto seguido generamos el grub.cfg:
grub-mkconfig -o /boot/grub/grub.cfg

Solo nos queda un archivo por modificar respecto a la instalación normal, y éste es /etc/mkinitcpio.conf:
nano /etc/mkinitcpio.conf
  buscamos la línea HOOKS y añadimos:
keyboard fsck encrypt lvm2

  Y ya podemos generar el disco RAM inicial:
mkinitcpio -p linux
 Cambiamos el password de root:
passwd
 Cerramos la jaula (chroot):
exit 
 Desmontamos las particiones que hemos montado antes:
umount /mnt/boot
umount /mnt/
  Y por último antes de reiniciar habilitamos con systemd el servicio para montar particiones mediante LVM:
systemctl enable lvm-monitoring
  Ya podemos reiniciar y proseguir con la creación de usuarios, instalación del entorno gráfico, etc...


 Con todo esto concluyo esta quimérica entrada, pues me he basado fragmentos de varias entradas para escribir ésta que permite cifrar particiones en ArchLinux con el sistema actual (systemd).


Fuentes:


Nos leemos en breve ;)

5 0verl0ad Labs: marzo 2013   Hace unos días me surgió la necesidad de formatear   porque me aburría  la partición de GNU/Linux del netbook e instalar ArchLinux . G...

martes, 5 de marzo de 2013

Aplicaciones Android - Intercepter-NG


  Hace unos días, encontré un post en DragonJar titulado "Dispositivos Android como herramientas para test de penetración" que nos presenta, como su título indica, diversas aplicaciones que pueden ser útiles en un test de penetración. De ellas, algunas ya las he comentado en el blog, pero encontré algunas otras interesantes y a las que dedicaré algunas entradas.

NOTA: Para ejecutar la aplicación es necesario ser root en el dispositivo.

  Una de dichas herramientas es Intercepter-NG, que nos permite capturar tráfico en nuestra red, analizarlo (emulando al gran Wireshark con muchísimas menos opciones), ver cookies o realizar ataques más complejos (SSLStrip).
  La podemos obtener de la web del desarrollador o el enlace directo:
http://intercepter.nerf.ru/intercepter.apk
Este código QR lo he generado yo, no proviene del desarrollador ;)

  La aplicación nos presenta un diseño por pestañas, para que, una vez escogidos nuestros objetivos, aprovechar las distintas funciones que ésta ofrece. Lo primero que haremos sera buscar en la red los equipos conectados, para ello pulsamos el "radar" que aparece en la parte superior izquierda y empezarán a aparecer los equipos de la red:


  Una vez seleccionados los objetivos pulsamos en la flecha verde (izquierda superior derecha), con lo que ya estaremos en el menú de pestañas. Aquí se nos presentan las distintas opciones que nos ofrece la herramienta, la primera de ellas y necesaria para que el resto funcione es el Arp Poisoning (pulsando el botón play):


  Este nos mostrará las páginas a las que accede la víctima:



  En la segunda pestaña (cuyo icono recuerda al de la herramienta Wireshark) obtenemos una visión del trafico similar a la del famoso sniffer:



  La tercera posibilidad que se nos ofrece es el ver las cookies interceptadas:



  Por último nos muestra un panel de opciones donde podemos escoger funcionalidades añadidas como realizar un ataque de SSLstrip o salvar la captura en un archivo:



  Y esto es todo, una aplicación interesante que nos permite llevar un completo sniffer en nuestros dispositivos.

  Nos leemos en breve,

5 0verl0ad Labs: marzo 2013   Hace unos días, encontré un post en  DragonJar  titulado " Dispositivos Android como herramientas para test de penetración " qu...
< >