Esta noticia hay que cogerla mucho mucho, muchísimo con pinzas.

En primer lugar el titulo de la noticia dice que Telegram le niega la recompensa, pero dentro de la noticia comenta como efectivamente le dio una recompensa de 1000$, lo cual por el fallo que encontró en Bug Bounties es totalmente razonable, y aunque le pareciera poco en ningún momento se le negó la recompensa.

En segundo lugar, cualquier persona que hay hecho Bug Bounties sabe que una vez encontrada la vulnerabilidad si la empresa no quiere no se debería de publicar, tú puedes pedir permiso y según la empresa y las condiciones del momento te dirán si puedes o no puedes hacerlo.

Mala actitud por parte del Bug Hounter, en mi opinión no hay noticia.

Un saludo.

A parte de lo que te han comentado los compis te aconsejaría darle duro a los Labs de PortSwigger: "No tienes permitido ver enlaces. Registrate o Entra a tu cuenta"

Te aconsejaría aprender a utilizar la herramienta BurpSuite, leer un poco de que va cada vulnerabilidad y entonces realizar los retos, si te ves muy estancado siempre estan las soluciones.

Tambien es muy útil darle duro a Hack The Box, es un nivel algo más avanzado, asi que elige máquinas fáciles y no desesperes.

Un saludo.

Primer resultado al buscar en Google:
No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
Segundo resultado al buscar en Google:
No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
Tercer resultado al buscar en Google (este tiene buena pinta):
No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
Cuarto Resultado al buscar en Google:
No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
Quinto Resultado al buscar en Google:
No tienes permitido ver enlaces. Registrate o Entra a tu cuenta

Bueno y asi sucesivamente,

Yo al contrario de lo que te comentan pienso que rootear el móvil es sin ninguna duda peligroso, no es como entrar como superusuario en un ordenador, las aplicaciones de Android tienen su propio directorio donde guardan una gran cantidad de información sensible, en la forma en la que está montado otra aplicación no podría acceder a esa información, pero en caso de rootear todas las aplicaciones podrían acceder a la información del resto de aplicaciones.

¿Qué diferencia hay con un ordenador? Simplemente el uso que le damos, probablemente tengas una aplicación bancaria en tu móvil (que guarda tu usuario y tu contraseña) y algún otro jueguecito (o cualquier aplicación), que obviamente no sabes que es lo que hace y te la has instalado sin dudar porque los móviles funcionan así.

Por esto te recomiendo la opción Liberty, que te permite elegir que aplicaciones correrán como superusuario y que aplicaciones no.

Un saludo.

Rollth

Depende mucho de como este todo hecho por detrás, que tengan una misma IP pública no significa necesariamente que esten alojadas en el mismo servidor. En caso de que lo estuvieran, podrías escalar privilegios y una vez hecho esto acceder a la información de la máquina víctima.

En caso de que no, dependiendo de como este montado, podrás hacer movimiento lateral dentro de la red hasta llegar a tu destino.

Sin embargo, si estas haciendo auditoría, piensa que generalmente esas otras páginas Webs están fuera de Scope y no se suele tener permiso para atacarlas.

Pues existen muchas formas,

Con conseguir hacer click en un dominio/servidor tuyo ya tendrías la IP pública,

Si quieres hacerlo con un fichero adjunto se me ocurren dos cosas de primeras:

1º Un word con macros que haga una petición HTTP a tu servidor.
2º Un ejecutable que haga una petición a tu servidor, si sabes programar en C con la librería LibHTTP no deberías de tener mucho problema.

También puedes echarle un ojo a este código No tienes permitido ver enlaces. Registrate o Entra a tu cuenta y cambiar lo que te parezca.

Saludos.

Hola,

Con el contexto que nos has dado es difícil saber por qué ese código es vulnerable a XSS, la función que estás utilizando encodea los siguientes caracteres  <, >, &, ", pero dependiendo de la versión no encodea ', por lo que dependiendo del caso podría ser vulnerable.

Por otro lado, según donde lo estes poniendo ni hará falta una comilla para poder ejecutar código.

echo "<img src=".htmlspecialchars($_GET['campo'], ENT_QUOTES, 'UTF-8').">";

Fijate que aquí uses la función que uses va a ser vulnerable a XSS.



Como te comento dependerá mucho de tu caso, si nos puedes dar más información mejor que mejor, si no, la herramienta que dice que es vulnerable debería decirte que Payload ha usado y ahí podrás ver como solucionarlo.

Un saludo.

Hola,

La verdad es que me extraña que tarde tanto como comentas, tal vez el script que estes utilizando no sea lo más optimo posible, te aconsejo sacar el "hash" con rar2john y de ahí crackearlo con john the ripper (o hashcat si tienes una buena gráfica), tal vez así vaya más rapido.

Por otro lado, si sabes más o menos por donde puede tirar la contraseña podrías probar a crearte un diccionario, pydictor es otra buena opción.

Un saludo

Cualquiera que tenga que ver con sistemas, programación, redes y demás te vendrá bien, aunque no aprenderás hacking como tal te dará muy buenos conceptos, el resto esta en ver como aprovechas tu tiempo.

Saludos.

Si alguien encontrase una forma de saltarse el 2FA de instagram lo reportaría para cobrar un Bug Bounty, no te lo daría a ti para que puedas entrar en el instagram de tu novia.

Puedes probar a pillarlo haciendo algún tipo de phishing o de engaño a la persona a la que le ha llegado el 2FA.

Saludos.

Entiendo que te refieres al cambio de tu IP pública, en ese caso puedes hacer varias cosas:

- Como bien has dicho utilizar NOIP
- Contratar algún DNS y hacer que el puerto que te interese apunte a tu IP, en caso de que se cambie de IP con tan solo cambiar a donde apunta el DNS bastaría.
- Pedir a tu ISP que te reserve una IP fija y asi asegurarte de que tu IP pública no cambia.

Un saludo.

Buenas PuntoCL,

En el caso de un payload que se conecta a ti de forma reversa no deberías de tener problemas en caso de que la empresa cambie de IP. Si te sientes más seguro siempre puedes  dejar un Backdoor en la web para poder ejecutar código de nuevo cuando quieras.

Saludos.

Muy buenas,

Sí, se puede realizar SQL injection en páginas ASPX. Las diferencias que te puedes encontrar respecto a una página escrita en PHP son muy pocas, te dejo algunos TIPs:

• Es posible que las XSS normales no te funcionen por el WAF que incluyen los servidores IIS, una forma de realizar Bypass es incluyendo esto en las XSS Stored: "＞＜script＞alert(0)＜/script＞
• Si quieres explotar una subida de ficheros insegura no lo harás con ficheros .php, si no con ficheros .aspx .asp o .config
• Cuando quieras realizar fuzzing de directorios puedes usar listas para servidores IIS: "No tienes permitido ver enlaces. Registrate o Entra a tu cuenta"
• Los servidores IIS suelen tener problemas con mayúsculas y minúculas, puedes jugar con eso para byppasear un código 403 o conseguir ver el código fuente de los ficheros: "/coDe403" o "content.ASPX"
• En caso de tener un LFI deberás buscar ficheros de Windows en lugar del clásico /etc/passwd
• Puedes utilizar Davtest para intentar subir una shell
• Puedes intentar explotar la vulnerabilidad ms10-070: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
• Puedes intentar listar directorios y ficheros a través de los Shortnames: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta

Saludos.

Recuerdo este Post de hace 5 años, me parece increible como después de tanto tiempo conseguiste volver a un camino que te motivaba.

Felicidades

Feliz navidad a todos.

 

No tienes permitido ver enlaces. Registrate o Entra a tu cuenta

No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
Yo he hecho los dos de webs y son sencillitos, los demas me han dado pereza.
Para el segundo te aconsejo usar Burp y echarle un ojo a las cookies, seguro que puedes sacarlo 

Muchas gracias por la pista! Llevo ya un par de horas probando y a lo único que he llegado ha sido a esto:



Aún fijándome en las cookies como bien dices no termino de ver lo que se me pide. En la pestaña proxy de burp me aparece la cookie codificada, la decodifico y ni con esas entiendo lo que espera de mi el ejercicio 

Tampoco busco la solución porque si no resuelvo este, el resto de ejercicios tampoco los resolveré, pero buscando en internet solo he encontrado información acerca de XSS. Entiendo el concepto que hay detrás pero no entiendo como espera el ejercicio que lo aplique.

Donde puedo aprender más sobre como resolver este tipo de ejercicios? Gracias de antemano y perdón por las molestias

Bueno en este caso una XSS no te servirá de nada, fijate que dentro de la página normal hay ciertos usuarios a los que puedes "espiar", hay un boton que dice spy. Si le pulsas ahora mismo no tendrías privilegios suficientes.
Tienes que intentar modificar la cookie para si tener estos privilegios cuando le des a espiar, y entonces es cuando te dan tu respectivo token.

Saludos.

Yo he hecho los dos de webs y son sencillitos, los demas me han dado pereza.
Para el segundo te aconsejo usar Burp y echarle un ojo a las cookies, seguro que puedes sacarlo 

Muy buenas Underc0ders,

hoy venía a hablaros de algo que he visto varias veces y me gustaría compilarlo todo y dejarlo aquí ya que pienso que podría serle útil a alguien. Se trata de lo que yo he llamado DoU (Denial of Users), o en Castellano, Denegación de Usuario, refiriendome de esta forma al bloqueo de un usuario ya sea o bien de forma temporal o bien de forma permanente, y aunque es algo de lo que ya se ha hablado nunca he visto un buen tutorial sobre el tema, además incluire algo que yo no había visto por la red.

Bueno, lo primero que vamos a hacer es armar nuestro laboratorio, aquí seré breve, basicamente lo que tenemos que hacer es montar un servidor web con php y una base de datos, también pueden usar algún tipo de hosting free que lo dan ya todo montado.

Crearemos una tabla en nuestra base de datos, que mantendrá la siguiente estructura.

Para ello podemos usar el siguiente Statment.

CREATE TABLE `users` ( `id` INT(4) NOT NULL AUTO_INCREMENT , `usuario` VARCHAR(100) NOT NULL , `password` VARCHAR(100) NOT NULL , `email` VARCHAR(100) NOT NULL , `bloqueo` INT(4) NOT NULL , `ip` VARCHAR(100) NOT NULL , PRIMARY KEY (`id`)) ENGINE = MyISAM;

Os dejo también por aquí todo el código que he usado para hacer las POCs (Ya se que el código es muy mal, pero lo hice rápido para hacer las pruebas)

No tienes permitido ver enlaces. Registrate o Entra a tu cuenta

Una vez subamos todo el código debemos modificar el config.php con nuestros datos y ya podremos acceder a "url.es/pruebas.php"


Si quieren hacer las pruebas pueden hacerlo en el laboratorio que preparé yo mientras esté online.

No tienes permitido ver enlaces. Registrate o Entra a tu cuenta

El primer caso que nos encontramos es una medida de evasión en la que las páginas webs bloquean a un usuario tras un numero de intento de sesión fallidos. Esto se hace para evitar ataques de fuerza bruta.

Para volver a poder tener acceso a la cuenta normalmente hay, o bien que realizar algún tipo de proceso vía email, o bien esperar una cantidad de tiempo, por lo que en este caso se trataría de un bloqueo temporal, a pesar de esto, puede ser dañino si se hace en ciertos momentos clave.

Para realizar la PoC vamos a registrar a un usuario, en mi caso test01, con credenciales test01.


Lo siguiente que haremos será logearnos con el usuario test01 y unos credenciales incorrectos, capturando la petición con BurpSuite y enviándola al intruder.

(Para los que no hayan usado BurpSuite aconsejo mirarse los No tienes permitido ver enlaces. Registrate o Entra a tu cuenta)

Una vez capturada la petición lo configuraremos para que vaya probando contraseñas diferentes, como si un ataque de fuerza bruta se tratase, en mi caso lo he hecho a través de una lista numérica.


Una vez configurado lanzaremos el ataque, como se puede observar la lista es de mil números, para asegurarme que hace el número de intentos necesarios para que bloquee al usuario.


Una vez hecho esto podemos comprobar que al intentar acceder con el usuario y contraseña correctos nos devolverá una alerta diciendo que el usuario ha sido bloqueado.

Este segundo caso funciona igual, la única diferencia es que en lugar de bloquear al usuario, bloquea la IP, por lo que si repetimos el proceso anterior nosotros seremos bloqueados, pero el usuario legítimo podrá seguir accediendo. Este tipo de bloqueo suele ser temporal.

Ahora crearemos de la misma forma un usuario que será test02 y accederemos a la segunda sección de bloqueo de usuarios por IP.

En este caso lo que haremos será en un servidor nuestro propio, crear una página que al entrar envíe muchas peticiones al login desde el cliente del navegador, de tal forma que al entrar el usuario legítimo en nuestra página maliciosa quedaría bloqueado.

Igual que en la ocasión anterior vamos a interceptar la petición para observar como es.


Una vez interceptada la petición tenemos la información suficiente para preparar nuestro código, quedando de la siguiente forma.

    <!DOCTYPE html>
    <html>
    <head>
    <title>Ataque ejemplo</title>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
    </head>
    <body>
    <script>
    var paso;
    for(paso = 0; paso < 100; paso++){
    $.post("http://testparauc.atwebpages.com/login2.php", // URL al que se envía la información
    {
    username: "test02", // Nombre de la Variable y Usuario
    password: paso // Nombre de la Variable
    },
    function(){
    alert();
    });
    }
    </script>
    <img src="https://globbsecurity.com/wp-content/uploads/2015/06/1330457418383.jpg">
    </body>
    </html>

Una vez subido nuestro código se lo enviaremos a la víctima, donde el verá lo siguiente.


Después de ver esto si intenta entrar en la página la aplicación detectará que ha hecho demasiados intentos y habrá bloqueado su IP.


El siguiente caso es algo que descubrí en una auditoría, donde si creas un usuario con el mismo nombre que otro ya existente el primero queda bloqueado y no se puede acceder. Esto es así por 3 motivos.

• Los valores no están identificados como únicos en la base de datos, por lo que en una columna puede haber dos filas con un mismo valor de una columna.
• Al registrar un usuario o modificarlo la aplicación no comprueba si ese nombre usuario o email ha sido creado anteriormene
• En la consulta en lugar de hacer SELECT * FROM usuarios y después seleccionar la parte que nos interesa, se hace SELECT password FROM usuarios, de tal forma que si hay varios usuarios iguales no devuelve un solo String, y al hacer la comparación dará siempre falsa

Para comprobar esto vamos a crear un usuario con usuario: test03 y contraseña: test03 y después accederemos normalmente para comprobar que funciona.

Una vez hecho esto volveremos a crear un usuario con usuario: test03 y contraseña: bloqueo, una vez hecho esto intentaremos acceder y veremos que no somos capaces de hacerlo con ninguna de las dos combinaciones.


Hasta aquí lo que venía a contarles y espero que les sea útil en algún momento.

También me pueden seguir en Twitter si les hace ilusión: No tienes permitido ver enlaces. Registrate o Entra a tu cuenta

Saludos.

Estoy con Gabriela, un trabajo que es simplemente explendido.
Una lectura aconsejada para todos y ya estoy esperando la tercera parte.
Te doy +1 en Karma

Saludos.

No tienes permitido ver enlaces. Registrate o Entra a tu cuenta
Hola gente !
Les cuento, estoy desarrollando un script en Python, el cual cumple su funcion, pero estoy haciendolo de una manera poco eficiente. Muestro primero la manera en la que lo estoy haciendo asi se entiende la pregunta despues 

user1 = "Mike"
pass1 = "123456"

user2 = "John"
pass2 = "456345"

variable1 = "cadena de texto"
variable2 = "cadena de texto"
variable3 = "cadena de texto"
variable4 = "cadena de texto"

Login(user1, pass1)
# validas para user1
Funcion(variable1)
Funcion(variable2)
Logout()
Login(user2,pass2)
# validas para user2
Funcion(variable3)
Funcion(variable4)
#etc etc son como 10 usuarios con 6/7 variables cada uno y esto se haria larguisimo

Lo que hace el script es llamar a una funcion digamos "loguear" con los parametros (user,pass).
Luego utiliza unas variables que son validas SOLO para una u otra cuenta, es decir si logueo con la cuenta N°1 utiliza las variables 1 y 2 y si loguearia la cuenta N°2 utiliza las variables 4 y 5
Mi objetivo es que en lo que sigue del programa, dependiendo de que cuenta se haya logueado use solo las que les corresponde.
Se que seguramente tenga que usar una lista o array pero de las maneras que he intentado, no me cuadra.

Saludos a todos y GRACIAS de antemano !

No termino de entender cual es tu intención, pero hay una cosa que  no me dejará dormir esta noche.
¿Estás harcodeando usuarios y contraseñas en python?
¿Y lo muestras en un foro de seguridad informática?

Espero no ser el único que se está echando a llorar.

Saludos.