Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - WHK

#251
Creo que tu problema va más allá de escapar la cadena, tu problema está en el concepto del uso de cadenas dinámicas desde php hacia una variable de jquery, eso es una pésima práctica.

<?php
$string "<h6>¿ves aquella esquina? tu madre y ' tu hermana ahí trabajan!</h6>";
$string str_replace("'""\'"$string);
$string str_replace('"''\"'$string);
$string htmlspecialchars($string);
?>


Eso tiene XSS ya que no estás usando la secuencia de escape de javascript como lo indica el estandar, por lo contrario, solo estas reemplazando algunos caracteres y escapando codigo html en una cadena de tipo javascript, asi que estás doblemente equivocado.

Para comenzar, la etiqueta <h6> no tiene porque venir desde php y pasar por javascript para ser escrito, esto debe ser parte del template de html y no del código dinámico, la frase debe estar en plano sin etiquetas html. Por otro lado, la obtención de la frase debiese ser obtenida a traves de una solicitud ajax o si no a traves de etiquetas ocultas. javascript no puede contener código html y php no debiera entregar valores con html.
#252
Pues generalmente ese tipo de vulnerabilidades los ves con mucho mas frecuencia en desarrollos que no hacen uso de frameworks, ya que al hacer todo a mano tambien hay que preocuparse de toda la seguridad de manera manual, y en mas de una ocación se te pasará algún detalle de seguridad, por eso el uso de frameworks hace que sea menos viable un ataque efectivo de tipo inyección ya que están preparados para evitar ese tipo de cosas. Eso no quiere decir que los desarrollos que usan frameworks no sean vulnerables, pero por lo menos no a cosas tan básicas.

Si quieres hacer un desarrollo pequeño manualmente tendrás que preocuparte manualmente de los tipos de datos, filtrado de datos, prevencion de vulnerabilidades, etc, en cambio si usas un framework solo tendrás que preocuparte por la lógica y las vistas nada más, no tienes que preocuparte por la escalabilidad o en cosas básicas como en una inyección sql.

Si estás recien aprendiendo te recomiendo aprender otros lenguajes como java y usar frameworks como spring, ya que este integra mecanismos de seguridad automatizados mucho mas avanzados que php, por ejemplo, usas templates thymeleaf que escapa automaticamente los caracteres para evitar xss, el spring security te da mecanismos de seguridad contra csrf, manejo de autenticaciones, autorización a secciones, etc.
#253
Las buenas prácticas dicen que no debes escapar ningun caracter de entrada, solo los de salida o de envío.

Cada lugar utiliza su propia secuencia de escape de caracteres, el agregar backslash a caracteres especiales no es "porque si", es un estándar definido para evitar vulnerabilidades y que todo funcione bien, pero no todos los estandares y secuencias de escape son iguales.

Lo primero es lo primero, hay que saber que no se deben abusar de los backslash o reemplazo de comillas cuando no se requiera por un estandar a modo de secuencia de escape, por ejemplo:

SQL utliza como secuencia de escape el backslash, asi que si haces una consulta sql manual desde php no debes hacer un reemplazo de caracteres manualmente, para eso existe mysql_real_escape_strting(), HTML utiliza como secuencia de escapes el htmlentities, asi que cuando vayas a exponer contenido sobre HTML debes utilizar la secuencia de escape que viene integrado con php que es htmlspecialchars() y ENT_QUOTES, si vas a incrustar contenido dentro de variables de javascript de manera dinámica debes utilizar la secuencia de escape de caracteres de ecmascript que son los caracteres unicode \u0000 o hexadecimales de tipo \x00 o backslash, pero ojo, en javascript la secuencia de escape no es la misma que la de un sql, no todo se arregla con un backslash, por ejemplo, puedes tener un xss con un simple salto de línea y no lo podrás escapar con un backslash, para eso ya existen funciones que escapan los caracteres especiales.

Una secuencia de escape de caracteres está diseñado por lo general para lenguajes interpretables como bash scripting, php, javascript, html, etc, y estas secuencias impiden conflictos de rompimiento de cadenas, esto provoca una inyección, por ejemplo:

Digamos que tengo esta frase: "Mi nombre es: $nombre y mi apellido es $apellido", entonces, que sucede si en nombre pongo: "nombre y mi apellido es x", entonces la frase quedaría así: "Mi nombre es: nombre y mi apellido es x y mi apellido es $apellido", ves? he inyectado dos apellidos porque no existía un delimitador en la palabra nombre ni en apellido, entonces para evitar estas situaciones existen las secuencias de escapes, por ejemplo, en este caso puedo añadir un - entre cada espacio en blanco, entonces quedaría asi: "Mi nombre es: nombre-y-mi-apellido-es-x y mi apellido es $apellido". Como puedes ver, ahora si se puede diferenciar el nombre del apellido real.

Con los lenguajes de programación sucede lo mismo, si en SQL los valores de tipo texto están encerrados en comillas, entonces como puedes ingresar una comilla como valor? esta rompería la cadena de cierre e inyectarías instrucciones sql, para eso se antepone un backslash, para asegurarse que quieres ingresar una comilla como valor y no rompa la cadena. En HTML pasa lo mismo, si quieres que se  vea una etiqueta html no la escribes tal cual o el navegador la interpretará, para eso existen los htmlentities, sino, inyectarás código html provocando un xss.

En resumidas, no debes agregar backslash asi porque si a cualquier texto o reemplazar caracteres, para eso existen los estandares y si agregas caracteres donde no debes puedes abrir problemas de seguridad, los backslash no se usan porque si, se usan para evitar rompimiento de cadenas y en cada lenguaje o situación el escape es distinto y en cada caso existen funciones nativas que te ayudan a hacer esos escapes.

Por ejemplo, digamos que quieres insertar una cadena de texto de manera dinámica dentro de una etiqueta script en html, debes uilizar dos tipos de secuencia de escape distintos, debes utilizar escape para html y para javascipt potqe javascript estará dentro de html:

<script>var cadena = '$cadena';</script>

Primeramente $cadena debe estar escapado para javascript, el cual debe evitar todo caracter especial y ser reemplazado por valores en hexadecimales, luego de eso debe ser escapado en htmlentities para evitar una inyeccion en html (aunque no se pueda inyectar debido a la transformación de caracteres especiales en hexadecimal pero es por buena práctica). Por ejemplo:

<script>
for(var i = 0; &lt;= 100; i++){
   var cadena = '\x0C\x3ch1\x3e Texto';
}
</script>


Como puedes ver, la cadena de texto contiene salto de línea y caracteres html y fueron escapados, pero si te fijas tambien, el for de javascript debiera decir "<=" pero está escapado en htmlentities debido a que el código que se encuentra dentro de la etiqueta <script> debe ser interpretada por el motor que interpreta html y luego que decodifica su contenido lo evaluará como código javascript. Que de todas maneras funcione sin escapar no quiere decir que sea correcto, para ello los navegadores web utilizan una tecnología llamada "tolerancia a errores", eso quiere decir que cuando deben interpretar el código lo corrigen de manera automática dentro de lo posible y luego lo pasan a memoria, por ejemplo, si escribes una etiqueta sin cerrar en xhtml esta se toma como inválido pero el navegador lo muestra de todas maneras, pero hablando estrictamente, el caracter "<" dentro de html sin escapar es un error de sintaxis y el navegador no debiera mostrar el contenido del sitio web, pero de todas maneras lo hace pero no está correcto.

la cadena en javascript va a memoria en mdo plano, eso quiere decir que sin escapar, en la memoria el valor de la cadena equivaldrá al texto con el salto de linea mas la etiqueta html, asi que cuando javascript necesite usar esa cadena y mostrarla sobre un espacio html debe escaparlo.

La solución no pasa por eliminar caracteres o detectar cosas peligrosas como con htmlpurifier o algun ids, la idea es programar como corresponde utilizando los estandares como se debe evitando inyecciones usando las secuencias de escapes como se deben, con eso no debieras porque tener vulnerabilidades de tipo inyección ni debieras porque estar eliminando caracteres o detectando textos peligrosos. Por ejemplo, si en el foro quiero escribir una etiqueta <script> ¿porqué debiera detectarlo como peligroso e impedir que lo escriba?, la idea mas bien es permitirme hacerlo y que esta sea guardada y mostrada de manera segura sin alterar el texto original, eso es una buena práctica en el desarrollo.

Vamos, para todo esto no necesitas hacer nada manualmente, de todo eso se encargarn los frameworks, generalmente debes utilizar secuencias de escape para todo cuando no usas frameworks. Por ejemplo, en codeigniter usas active record y no necesitas usar secuencia de escape para sql, con jquery y valores dinamicos por etiquetas no necesitas escribir valores directamente en javascript asi que no necesitas escaparlos y jquery puede insertar textos ya escapados con .text().

Saludos.
#254
Hacking / Re: Incinera tu sitio WEB!
30 Julio 2020, 09:56 AM
Nopues, primero termina de construir el sitio xD solo es un proyecto hecho en Java Spring con un template que no hace nada xD, ni si quiera el buscador funciona.
#255
Hacking / Re: Incinera tu sitio WEB!
30 Julio 2020, 02:59 AM
Cita de: Shell Root en 29 Julio 2020, 15:29 PM
Tipo de encryptación.
Se supone que cada petición debe de validar un hash diferente, algo como Tokens CSRF, en cada petición cambia el token y debe de validarse así se evita automatización de peticiones. Corrigeme si estoy mal WHK!

Asi es, ese formulario debiera tener una captcha con un hash de validación único, como recaptcha. En ves de tener que programar todo el formulario de contacto agregandole captchas y demás, sale mucho mas fácil y eficiente poner el correo de contacto ofuscado y que la misma gente envíe el correo desde sus propios clientes.
#256
Hacking / Re: Incinera tu sitio WEB!
28 Julio 2020, 21:19 PM
CitarEste sitio web esta hospeado en 260MB la url es https://cleanet.260mb.net
TXT: https://cleanet.260mb.net/hackme.txt

Bien, claramente no podrá crear un registro TXT en su subdominio porque es un hosting por subdominios, asi que no podrá crear el registro. Creo que de todas maneras en estos casos si valdrá un archivo .txt.

El sitio WEB es casi en su totalidad estático y casi no tiene secciones, asi que es muy poco lo que se puede revisar, a demás, es un hosting compartido asi que tampoco se puede hacer mucho a su infraestructura, pero, si tiene un formulario de contacto.

Pude ver dos acciones distintas en el sitio WEB, uno encargado de hacer el envío del mensaje de contacto y otro para cambiar el lenguaje, extrañamente cuando quieres cambiar el lenguaje a un lenguaje inexistente la pagina web se muestra en blanco en ves de arrojar un error o simplemente mostrar un lenguaje por defecto, supongo que efectivamente hay un error pero errors_display está deshabilitado desde php.

El formulario de contacto tiene un problema, actualmente para enviar un correo debes resolver un valor en AES y luego enviarlo a traves de una cookie, muy ingenioso ya que te exije tener habilitado javascript, pero esto no evita bots. La validación del lado de PHP es estática, asi que en la práctica da igual si utilizas el valor de AES del momento o uno que ya haya sido utilizado, el servicio te arroja un estado de "enviado" cada ves que reenvías la misma solicitud utilizando el mismo hash en AES:

Probando sin la cookie:

ncat --ssl --crlf -v cleanet.260mb.net 443

POST /email.php HTTP/1.1
Host: cleanet.260mb.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: */*
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 36
Origin: https://cleanet.260mb.net
Connection: Close
Referer: https://cleanet.260mb.net/

asunto=test&mensaje=test&anonimo=on


Respuesta del servidor:

<html><body><script type="text/javascript" src="/aes.js" >
</script><script>function toNumbers(d){var e=[];
d.replace(/(..)/g,function(d){e.push(parseInt(d,16))});
return e}function toHex(){for(var d=[],d=1==arguments.length&&
arguments[0].constructor==Array?arguments[0]:arguments,e="",
f=0;f<d.length;f++)e+=(16>d[f]?"0":"")+d[f].toString(16);
return e.toLowerCase()}var a=toNumbers("f655ba9d09a112d4968c63579db590b4"),
b=toNumbers("98344c2eee86c3994890592585b49f80"),
c=toNumbers("03b479870acf0ba0ff959ab28fb1dfe9");document.cookie="__test="+toHex(slowAES.decrypt(c,2,a,b))+";
expires=Thu, 31-Dec-37 23:55:55 GMT; path=/";
location.href="https://cleanet.260mb.net/email.php?i=1";</script>
<noscript>This site requires javascript to work, please enable
javascript in your browser or use a browser with javascript support</noscript>
</body></html>


Probando con una cookie estática múltiples veces:

ncat --ssl --crlf -v cleanet.260mb.net 443

POST /email.php HTTP/1.1
Host: cleanet.260mb.net
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0
Accept: */*
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 36
Origin: https://cleanet.260mb.net
Connection: Close
Referer: https://cleanet.260mb.net/
Cookie: __test=17544cb0f7e91786eec69621b893d683;

asunto=test&mensaje=test&anonimo=on


HTTP/1.1 200 OK
Server: nginx
Date: Tue, 28 Jul 2020 19:00:38 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: close
Vary: Accept-Encoding
Cache-Control: max-age=0
Expires: Tue, 28 Jul 2020 19:00:36 GMT

4
sent
0


Ok, este hash de la cookie la he reutilizado varias veces y el servidor me sigue diciendo que el mensaje ha sido enviado, asi que esto puede provocar un abuso del servicio.

No se sabe exactamente si PHP del lado del servidor hace el envío de un correo o almacena los mensajes en un txt, pero si se envían correos a traves de la función mail() entonces hay un problema serio y es que el envío masivo de correos puede provocar que caigas en listas negras o den de baja tu hosting y termines con tu sitio web abajo.

También intenté verificar si el formulario de correos tiene inyección de cabeceras:

asunto=test%0a%0cReply-To:%20test@demo.com&mensaje=test%0a%0a.%0a&anonimo=on

Ya que mail() de php adjunta las cabeceras de manera plana separadas por saltos de línea \r\n, pero no se si realmente funcionó porque no puedo hacer que me llegue una copia del correo, asi que podrías validar tu mismo, si realiza el filtrado de saltos de línea o no.

También pude ver un directory listing: https://cleanet.260mb.net/lang/ , esto no causa ningún problema, pero si puede dar problemas serios si tienes algún directorio oculto que no esté protegido, por ejemplo, alguna carpeta donde almacenes los mensajes del formulario de contacto o algún plugin de php de terceros que pueda ser llamado de manera directa, como por ejemplo: https://cleanet.260mb.net/plugins/PHPMailer-master/src/

Saludos.
#257
Hacking / Incinera tu sitio WEB!
28 Julio 2020, 05:04 AM
Hola a todos!, se me ha ocurrido una buena idea para que todos podamos aprender de seguridad de manera didáctica, real y sin meternos en problemas. La idea es la siguiente:

¿Eres dueño de un sitio WEB?

Haz pasar por el fuego a tu sitio WEB!



Danos la oportunidad de revisar la seguridad de tu sitio entregandonos de manera voluntaria la URL, claramente debes ser el dueño y para asegurarnos de ello debes crear un registro TXT en tu dominio con la palabra "elhacker.net", si lo haces, entonces entre los mismos usuarios del foro le daremos un vistazo a tu sitio web y eso nos permitrá intercambiar ideas y técnicas para aprender mutuamente, y de pasada podrás corregir tus vulnerabilidades antes de que alguien más las encuentre y las aproveche para un ataque real no controlado.


¿Quieres ser el Pentester?

O para los que no conozcan el término: El atacante.



Sólo se pide algo de sentido común, acá la idea no es botar un sitio o hacerle daño, la idea es demostrar una vulnerabilidad, publicarlo en este mismo hilo y demostrar como lo hizo. Asi que:

- No se permiten ataques DOS ni DDOS ni nada que indisponga al sitio WEB.
- No se permite robar información de la base de datos.
- No se deben modificar archivos o datos de la db.
- La vulnerabilidad debe ser comprobable más que teórica.
- Publicar vulnerabilidades reales, nada de que le faltan cabeceras x frame options y basuras similares.
- Solo se debe revisar mientras exista el registro TXT en su dominio.

Cómo revisar si el dominio contiene el registro TXT correcto?: Desde el bash se debe ejecutar:

$ dig -t txt dominio.com

Si usas windows puedes usar la PowerShell:

PS> Get-Dns -Name dominio.com -Type TXT


¿Reglas?

Se vale todo, menos afectar la integridad o privacidad del mismo sitio. Esto quiere decir que no solo debemos restringirnos a una revisión web, tambien se vale revisar subdominios, puertos, etc, todo aquello que sirva para poder llegar al sitio WEB en cuestión (si, incluyendo la del proveedor de hosting).


¿Entregables?

Vamos, esto es un foro, el que quiera puede publicar sus hallazgos en un simple post o puede hacer un pdf a modo de informe, todo dependerá de quien lo haga, acá no hay un "esperable" o un "entregable", eso depende de cada uno.

De todas maneras, si se recomienda poder dar posibles soluciones por cada vulnerabilidad que encuentre (dentro de lo posible).





Vamos, esto es bien fácil, si tienes un sitio WEB permítenos que le demos un vistazo, eso es todo y los que lo revisemos podremos aplicar técnicas reales sobre sistemas reales. Muchas veces nos encontramos con CTF que no reflejan la realidad o solo debes estar adivinando cosas, la idea es poder ganar experiencia real en sistemas reales con vulnerabilidades reales.

Alguien se apunta?, solo basta con entregar su URL y agregar el registro TXT, si el dominio no tiene el registro TXT entonces abtenerse de revisarlo porque puede que realmente no sea el dueño del sitio WEB.
#258
Pues claro que se puede, pero hackear es un término demasiado ámplio, todo depende de que quieras hacer exactamente. Una cámara de seguridad puede estar construida de muchas maneras, algunas mas hackeables que otras, todo dependerá del caso, es como decir que si puedes hackear un movil, el tema es que version de movil es, que sistema tiene, que quieres hacer con el movil, etc.

Las camaras pueden ser análogas o digitales, pueden ser solo transportadora de datos o integrar software como las camaras wifi, si por ejemplo quieres saber si un video puede ser interceptado o poder ver lo que la cámara ve, dependerá del modelo, del software, etc etc. Por ejemplo:

Si es análogo necesitarás cortar los cables, decodificar la señal con algún PCB y conectarlo a algún sistema de video análogo.

Si es digital tendrías que interceptar el cable de red y hacer un switch a modo de repetidor e intentar capturar paquetes tcp y decodificar, ver que protocolo usa, saber si es plano o usa ssl, etc.

Si es remoto tendrías que llegar a su red, conectarte a su red con su clave y luego intentar acceder al software, pero para eso necesitas encontrar alguna vulnerabilidad en su sistema de red y no todas las camaras usan el mismo sistema.

Si está dentro de una red al igual que tu entonces es mas facil porque ya puedes llegar directamente al software, pero es dificil que logres llegar a un mismo segmento de red que una camara, normalmente están separadas o protegidas por zonas. Para llegar tendrias que vulnerar la red primero.

Hay otras cámaras que están expuestas directamente a internet y puedes llegar a ellas simplemente escribiendo su dirección ip, pero esto ya es un problema de instalación del usuario. Sitios que recopilan esto hay por montones: http://www.insecam.org/

La gran pregunta es... que quieres hacer realmente con estas cámaras, que buscas o cual es tu finalidad, si solo quieres entretención viendo videos de camaras entonces hay muchos sitios por internet para ello.

Saludos.
#259
Java / Re: Iniciandome en Java
28 Julio 2020, 03:58 AM
Intentar leer un .jar es como intentar leer un binario compilado de c, puedes hacerle reversing y todo pero nunca tendrás el código original.

Los archivos .jar son semicompilados, igual que un paquete semicompilado de .net, realmente no es una compilación a bajo nivel donde puedas inyectar todo a la memoria o hacer que la CPU lo interprete desde el kernel, los .jar son distintos, necesitan de una máquina virtual que los cargue, los interprete y los ejecute.

Asi que, no podrás leer y modificar el archivo jar a menos que lo descompiles e intentes crear un compilado nuevo. Debes buscar los fuentes .java, los .class realmente son objetos binarios semicompilados, como los archivos .a cuando compilas en c.

Dale un vistazo a esto:

http://java-decompiler.github.io/
https://github.com/linchanggui/dex2jar-2.0

Saludos.
#260
Pues facil,

document.write('<span>' + payload + '</span>');

Cuando llames a esa función el DOM escribirá en la misma posición desde donde es llamado, asi que si lo escribes dentro de una división entonces verás su contenido ahi mismo.

Si necesitas escribir la etiqueta de manera dinámica después de toda la carga del DOM (lo cual es lo más recomendado) debes utilizar los selectores https://developer.mozilla.org/es/docs/Web/API/Document/querySelector .

Debes recordar que agregar elementos llamando desde javascript antes de la finalización de la carga del DOM es una mala práctica debido a que el HTML debe ser totalmente independiente a la aplicación de javascript, asi que tu código debiera realmente ir a buscar cada nodo por su id y luego manipularlo a conveniencia. Si no usas ningún framework client side como ReactJS puedes usar jQuery.

Saludos.