Universidad Estatal de Adams. Cómo hackear sitios web. Parte 2

Universidad Estatal de Adams. Cómo hackear sitios web. Parte 1

Hablemos de nuestro próximo ataque. Te diré cómo te identifican los servidores. Para hacer esto, el protocolo HTTP se usa entre el navegador y el servidor sin guardar el estado, cuando la comunicación con el servidor se produce por pares de solicitud-respuesta independientes. Por lo tanto, el servidor lo olvida tan pronto como se establece la conexión, y en la próxima sesión ya no recuerda quién es usted.



Sin embargo, √©l te recuerda mientras usas la aplicaci√≥n web, porque cuando pones las cosas que quieres comprar en la cesta, puedes continuar comprando y volver para ver el contenido de tu cesta. La implementaci√≥n de "recordar" ocurre usando cookies de identificaci√≥n de sesi√≥n. Tan pronto como inicie sesi√≥n en el servidor, genera una cookie, que es una secuencia √ļnica de letras y n√ļmeros, y la env√≠a a su navegador, que almacena esta cookie localmente en su computadora. Despu√©s de eso, el navegador devuelve cookies al servidor con cada una de sus solicitudes para una sola sesi√≥n. Al recibir estas cookies, el servidor comprende qu√© tipo de usuario est√° accediendo a ella con esta solicitud. Esta es la forma m√°s com√ļn de identificar al usuario que usa la aplicaci√≥n web.

El siguiente tipo de ataque se llama scripting entre sitios, XSS. La idea detr√°s de este ataque es que un atacante obliga a un sitio web a mostrar c√≥digo malicioso, generalmente en forma de JavaScript, que luego se ejecuta en el navegador del usuario. Tal ataque puede perseguir cualquier prop√≥sito, pero se usa con mayor frecuencia para obtener el identificador de sesi√≥n de la v√≠ctima. El valor de la ID de sesi√≥n es que puede considerarse como una contrase√Īa, ya que te identifica. Al capturar el identificador de sesi√≥n, un atacante puede disfrazarse usando un servidor proxy para comunicarse con el servidor de destino. Los objetivos de tal ataque pueden ser el deseo de hablar en su nombre, automatizar algunas acciones, por ejemplo, spam, en su nombre o introducir un virus.

Al buscar la vulnerabilidad de secuencias de comandos entre sitios XSS en una aplicación web, está buscando un campo de entrada en el que pueda poner alguna información, enviarla al servidor y ver qué resultado se mostrará en la ventana del navegador.



Ingresé incorrectamente la ubicación del edificio, indicando Plachy Hall, la dirección de la sala del equipo de baloncesto de nuestra universidad. El servidor web recibe esta información y se da cuenta de que el profesor de informática es un "nerd" que no puede vivir en la ubicación de un equipo deportivo y muestra un mensaje de error: "¡Plachy Hall está equivocado"!

Los cuadros de b√ļsqueda son los m√°s vulnerables a este respecto, donde puede ingresar algunos t√©rminos bastante oscuros y luego ver lo que obtiene a cambio. Muy a menudo, se le da una pista que enumera las posibles opciones correctas que un atacante podr√≠a aprovechar.

Lo siguiente que debe hacer es verificar si puede inyectar su código malicioso y luego ejecutarlo. Intentaremos organizar un ataque XSS usando JavaScript.



El c√≥digo JavaScript siempre se distingue abriendo y cerrando la etiqueta del script, as√≠ como el operador OR. Los desarrolladores de aplicaciones no son completamente est√ļpidos, por lo que configuraron un mecanismo de filtrado llamado "desinfecci√≥n". Se incrusta en el c√≥digo, comprueba si hay caracteres peligrosos y los elimina siempre que sea posible. La prueba de desinfecci√≥n JavaScript m√°s simple se ve as√≠:

<script>alert(‚ÄúTesting‚ÄĚ)</script> 

Pero los hackers son un poco más inteligentes, por lo que tienen ha.ckers.org/xss.html . No tengo tiempo para mostrarle este sitio, pero allí puede encontrar las formas más sofisticadas para eludir los controles que los desarrolladores de aplicaciones intentaron insertar en sus programas para eliminar caracteres peligrosos. Entonces, hay algunas formas bastante inteligentes que permiten que un hacker ingrese a la aplicación.

Entonces, hablemos sobre c√≥mo ser√° el ataque XSS. Tenemos un servidor web para las "P√°ginas de la Facultad", donde vamos a ingresar el c√≥digo malicioso. Tenemos a Eve, que va a hackear, pero nos perdimos algo en esta diapositiva: nos olvidamos de la v√≠ctima. Lo bueno de un ataque XSS es que no necesita contratar a nadie para hacer esto. Quiero decir, esta vez no voy a ser una v√≠ctima, porque Eva tiene mi contrase√Īa y puede hacer lo que quiera con mi cuenta. Por lo tanto, Eve deja el gran juego y ya no persigue a los ni√Īos peque√Īos. Llevemos a nuestra v√≠ctima al escenario (risas de la audiencia, porque en la diapositiva aparece una fotograf√≠a de uno de los profesores de la facultad).

Ahora que la víctima ha ocupado su lugar, veamos cómo se desarrolla el ataque. Supongamos que Eve logró alojar el código JavaScript malicioso en el servidor donde nuestra víctima va a ingresar usando su cuenta.

Esto es importante, porque tan pronto como la víctima inicie sesión en el servidor, recibirá un identificador de sesión que Eva intentará interceptar, esta es una parte muy importante del ataque. Entonces, la víctima solicita una página web que contiene código JavaScript malicioso, este código se ejecutará en el navegador de la víctima y le enviará a Eva el identificador de sesión.



Habiendo recibido el identificador de sesi√≥n, Eve puede usar su servidor proxy y hacer lo que quiera, disfraz√°ndose de v√≠ctima. La √ļnica pieza que falta en el mosaico es el JavaScript malicioso en s√≠, que el hacker debe insertar en la p√°gina y que debe capturar nuestra ID de sesi√≥n de v√≠ctima y pasarla al atacante.

Es muy simple Tenemos un código JavaScript que comienza y termina con la apertura y cierre de la etiqueta:

 <script> 

La primera línea de código crea una imagen de la misma manera que en JavaScript, una imagen se crea dinámicamente para cualquier página. Usted sabe que en el corazón de cualquier imagen hay un archivo que contiene la imagen, por lo que debemos decirle al navegador a dónde ir para obtener esta imagen. Esto se indica en la segunda línea, donde se encuentra el enlace al sitio del hacker, sin embargo, el navegador cree que este es exactamente el lugar donde se encuentra la imagen deseada. Irá al sitio web de Eve y pedirá document.cookie, porque cree que este es el archivo de imagen que necesita.

Pero este no es un archivo de imagen, sino un identificador de sesión que estamos tratando de capturar usando JavaScript. Como puede ver, obtener una ID de sesión es bastante simple. La tercera línea, que no se usa en el código para llevar a cabo un ataque XSS, contiene una alarma que activa una ventana emergente en el navegador con un mensaje de ataque. Esto se hace específicamente para nuestro ejemplo, porque la víctima pasa por alto un verdadero ataque XSS.



Entonces, invitemos a Eve y veamos cómo atacará las secuencias de comandos entre sitios.

Eve Hacker: ¡Gracias Dr. Loveland! Lo primero que tengo que hacer es cerrar algunas cosas que no necesitamos. Ya no necesitamos el proxy Burp Suit, así que lo estoy cerrando. En segundo lugar, necesito volver a configurar el navegador web y cambiarlo para usar la configuración predeterminada del sistema proxy.

Ahora vamos a la p√°gina de inicio de sesi√≥n del sitio web del Dr. Loveland, porque si recuerdas, tengo su contrase√Īa y puedo ingresar al sitio en cualquier momento en lugar de ella. Como mencion√©, la Dra. Loveland es bastante perezosa, usa un certificado SSL caducado, por lo que tengo que confirmar las excepciones de seguridad para ir a la p√°gina de inicio de sesi√≥n. Como s√© la contrase√Īa, puedo editar su p√°gina web. Como ya sabemos, en la p√°gina para editar informaci√≥n personal hay una vulnerabilidad en la l√≠nea Ubicaci√≥n del edificio, "Ubicaci√≥n del edificio", y es aqu√≠ donde voy a ingresar mi JavaScript malicioso.



Simplifiqué este ataque, por lo que en realidad no enviaré el código al servidor, sino que llamaré a una ventana emergente con un mensaje de que alguien está tratando de atacarme. Ahora que he preparado el escenario para el ataque, volveré a la página de autorización y cerraré sesión. Ahora solo tiene que esperar hasta que aparezca una víctima que quiera usar esta aplicación.



(Eve se pone una gorra de béisbol, haciéndose pasar por el profesor Stephen Eldridge)

Acabo de regresar de una reuni√≥n fascinante donde, durante las horas libres, discutimos qu√© autom√≥vil deber√≠a tener prioridad en el estacionamiento: un Subaru o un Jeep, y luego se nos ocurri√≥ que la diferencia podr√≠a ser un techo corredizo en el autom√≥vil. As√≠ que ahora necesito iniciar sesi√≥n y verificar mis datos de contacto, porque no me gustar√≠a perder la pr√≥xima reuni√≥n "fuera de clase" porque mis datos no estaban disponibles. Entonces, inicio sesi√≥n en mi aplicaci√≥n web con el nombre de usuario saldrich y mi contrase√Īa.



Entonces, todo se ve como siempre, no veo nada malo en mi página como profesor de matemáticas, toda la información de contacto está en orden.

¡Dios mío, mi reloj muestra que solo quedan 2 minutos para la próxima reunión! Ahora voy a conocer al Dr. Loveland, así que necesito ir a su página y ver si puedo desenterrar algo de ella para mencionarlo en la reunión. Entonces, hago clic en el enlace de Susan Loveland, llego a su página y ... Dr. Eldridge, ¡su página está pirateada!



(El profesor Eldridge se quita la gorra de béisbol y se convierte en Eva)

Ahora que tengo su ID de sesión, puedo usar mi servidor proxy y disfrazarme, Dr. Eldridge, de hacer lo que quiera en su nombre. ¡Le doy la palabra, Dr. Loveland!

Susan Loveland: gracias Eve! Quería mencionar que nuestra aplicación de la página de la facultad se desarrolló sobre la base de uno de los marcos web más nuevos: Python Django Web Framework, que tiene un excelente sistema de desinfección de datos de entrada que elimina los caracteres peligrosos del código JavaScript. Por lo tanto, para que Eve lleve a cabo su ataque, excluí comprobar el valor del campo Ubicación del edificio para la presencia de dichos personajes.



¬ŅQu√© tan exitosos son los ataques de secuencias de comandos entre sitios? Aproximadamente el 80-90% de los sitios web tienen un mecanismo de gesti√≥n de vulnerabilidades del lado del cliente. La incapacidad de resistir los ataques XSS es la vulnerabilidad m√°s com√ļn de las aplicaciones Web 2.0 que interact√ļan m√°s con los usuarios finales.

Probablemente haya escuchado acerca de uno de los scripts de sitios cruzados más famosos de "gusanos", cuyo autor Sami Kamkar se le ocurrió en 2005, cómo evitar el filtrado de entrada de la red social MySpase. Colocó JavaScript en su página, tal como lo hizo Eve con mi página. Este script hizo 2 cosas: agregó a Samy como amigo de la víctima y se copió a sí mismo en la página de perfil de la víctima. Al principio, este ataque fue muy lento, porque solo unas pocas personas fueron a la página de Samy y se hicieron amigos, pero gradualmente el virus se propagó cada vez más y la infección comenzó a crecer como una avalancha. Este ejemplo fue ilustrativo en términos de las capacidades del ataque XSS, ya que más de un millón de solicitudes de amistad en unas pocas horas "bloquearon" el sitio MySpase. Por lo tanto, las consecuencias de estos ataques pueden ser bastante graves.

El √ļltimo tipo de ataque del que quiero hablar hoy son los ataques de control de acceso o ataques de acceso. Con tal ataque, el hacker quiere obtener informaci√≥n a la que no tiene acceso. Hay varias vulnerabilidades dirigidas por el vector de ataque de acceso.
A menudo, los desarrolladores de aplicaciones olvidan que dejaron archivos en el directorio raíz de un documento en un servidor web, y si pueden encontrar su existencia, podrán ver estos archivos, que a menudo contienen información confidencial.
Otra forma de encontrar la vulnerabilidad es mirar con mucho cuidado la URL. Por ejemplo, si ve una direcci√≥n de este tipo app.com/ViewDoc.php?docid=1280149120 , simplemente puede buscar los n√ļmeros al final del enlace para obtener un documento que no est√° destinado a sus ojos.

Muchas aplicaciones est√°n dise√Īadas para diferentes niveles de usuarios y tienen un mecanismo de acceso incorporado que a menudo se basa en solicitudes con los siguientes par√°metros app.com/login/home.jsp?admin=false , por lo que puede intentar ingresar al sitio utilizando el reemplazo de direcci√≥n en la l√≠nea a admin = verdadero.

De hecho, la vulnerabilidad de control de acceso m√°s com√ļn es la implementaci√≥n incorrecta de la funci√≥n de autorizaci√≥n. Ahora Eva demostrar√° esto.

Eve Hacker: Gracias, Dr. Loveland. Para llevar a cabo el √ļltimo ataque, solo necesita mirar con mucho cuidado la URL de nuestra aplicaci√≥n web. Ahora expandir√© la ventana de la aplicaci√≥n para que la l√≠nea con la direcci√≥n en la p√°gina del Dr. Loveland encaje completamente en la pantalla. Tengo que deshacerme de este molesto JavaScript que instal√©.

Vemos que la dirección de la página del Dr. Loveland es localhost / SampleSite / Faculty / index-1.html , y si cambiamos a la página del Dr. Eldridge, la dirección será localhost / SampleSite / Faculty / index-2.html .

¬ŅNo crees que la misma plantilla se usa aqu√≠? Sin embargo, no estoy interesado en estas l√≠neas de direcci√≥n, ya que no tienen la capacidad de ingresar informaci√≥n. As√≠ que quiero llegar al formulario de inicio de sesi√≥n del Dr. Loveland. Si inicio sesi√≥n con su nombre, puedo editar su informaci√≥n personal. Pero echemos un vistazo a la URL de la p√°gina, al final de la cual hay IndexForm-1, y puede adivinar que tal vez haya una oportunidad de acceder al formulario de datos del Dr. Eldridge.



Entonces, la pregunta es si podemos acceder a su formulario sin iniciar sesión en su nombre. Probémoslo. Cambio la unidad a dos para que la dirección tome la forma localhost / SampleSite / Faculty / indexForm-2.html , presione Entrar y aparece una página con la información personal del Dr. Eldridge.



Ante nosotros hay un error que los estudiantes del Dr. Loveland olvidaron corregir: la aplicación tiene una vulnerabilidad que le permite penetrar en la página de otra persona sin ingresar el inicio de sesión de la víctima.
El Dr. Eldridge es una persona muy amable, no quisiera molestarlo, no tengo nada en contra de √©l, pero por el bien de la risa, dejar√© algo en su p√°gina. Perm√≠tanme distorsionar su nombre y apellido, y al mismo tiempo corregir la posici√≥n de "Profesor" a "Profesor j√ļnior".



Ahora enviaré la información personal corregida al servidor, y si ahora entro en la página de Eldridge, entonces podrá ver las correcciones realizadas por mí.



Entonces, Dr. Loveland, si tiene problemas con el Dr. Eldridge cuando decide detenerlo después de las conferencias, ¡solo dígame y eliminaré toda su información!
Susan Loveland: ¡Gracias por el apoyo, Eve! Quiero hablar sobre la vulnerabilidad de control de acceso por solo un segundo más. Para las personas que, como yo, quieren profundizar en el código, explicaré lo que sucedió durante este ataque.



Esta diapositiva muestra c√≥mo completar un formulario con informaci√≥n personal. La √ļltima l√≠nea es exactamente lo que le interes√≥ a Eva. Esta clase protege form_index de las funciones r√°pidas @ login-required y @authUser y comprueba que cualquier persona que quiera cambiar los valores en los campos del formulario debe iniciar sesi√≥n en el sistema para esto. Sin embargo, los desarrolladores olvidaron esto y no agregaron la menci√≥n obligatoria de estas funciones r√°pidas en el contexto de completar el formulario.
El código que se muestra comprueba si el formulario solicitado coincide con la persona que inició sesión en el sistema, pero como no se usó correctamente, Eve pudo detectar esta vulnerabilidad en la aplicación.

Observo que el 78% de todos los sitios tienen vulnerabilidades de acceso. En abril pasado, algunos piratas inform√°ticos descubrieron una vulnerabilidad en el campus universitario de Berkeley: estos eran archivos ocultos que los desarrolladores dejaron en el servidor de documentos del servidor web. Los hackers pudieron ver estos archivos y obtener n√ļmeros de seguridad social e informaci√≥n m√©dica confidencial para m√°s de 160 mil personas. Entonces, ver√° cu√°n graves pueden ser las consecuencias de un ataque de control de acceso.

Me gustar√≠a mencionar algunos hechos m√°s interesantes en el contexto del tema de nuestra conversaci√≥n de hoy. Recientemente, la atenci√≥n del gobierno a la ciberseguridad ha aumentado considerablemente. Por lo tanto, solo en 2008, el Ministerio de Defensa registr√≥ m√°s de 360 ‚Äč‚Äčmillones de intentos de pirater√≠a. Se planea gastar alrededor de $ 75.8 mil millones para mejorar el sistema de ciberseguridad en el campo de las tecnolog√≠as de la informaci√≥n en 2010, que es 7.2% m√°s de lo que se gast√≥ en estos objetivos en 2009. Seg√ļn la revista CNN Money, en 2009 en los Estados Unidos, los especialistas en seguridad de Internet estaban en la cima de las profesiones m√°s buscadas. El ingreso anual promedio de los consultores en el campo de la seguridad inform√°tica ascendi√≥ a 99.7 mil d√≥lares, el m√°ximo - 152 mil d√≥lares. Seg√ļn las previsiones, la necesidad de tales especialistas entre 2006 y 2016 aumentar√° en un 27%.

Quiero decir que la Facultad de Ciencias de la Computación recientemente tuvo la oportunidad de obtener un título de asociado en Informática de Internet y Seguridad de Redes, por lo que este es un gran punto de partida para comenzar una carrera en esta área.

(se pone un sombrero negro)

Eve Hacker: ¬°Quiero interrumpirlo por un momento, Dr. Loveland! Para futuros maestros presentes en esta audiencia, noto que si dominas esta especialidad y alg√ļn d√≠a te encuentras en una situaci√≥n en la que no recibes el aumento salarial prometido, siempre puedes recurrir a la mafia y realizar un hack de contrato para ellos. Este ser√° un excelente aumento en el salario de un profesor de inform√°tica.

(se quita el sombrero)

Susan Loveland: Quiero agradecer a las personas que hicieron una contribuci√≥n seria a la creaci√≥n de la presentaci√≥n de hoy, los desarrolladores de las "P√°ginas de la Facultad". Creo que gracias a su arduo trabajo, podr√© dejar a esta audiencia sin las esposas y la escolta de la polic√≠a del campus. El √ļnico miembro "sobreviviente" de este grupo es Ryan Goldsworthy, quien jug√≥ un papel importante en el desarrollo de estas p√°ginas. Quiero agradecer al Dr. Stephen Eldridge por su sentido del humor y por enviar una p√°gina personal para demostrar los ataques, agradecer a los jefes de departamento que han contribuido generosamente a mi proyecto de P√°ginas de Facultad, y tambi√©n agradecer al Servicio de Computaci√≥n Inform√°tica del campus por protegernos de tales ataques. gente como Eva

Gracias por su atencion


Gracias por quedarte con nosotros. ¬ŅTe gustan nuestros art√≠culos? ¬ŅQuieres ver m√°s materiales interesantes? Ap√≥yenos haciendo un pedido o recomend√°ndolo a sus amigos, un descuento del 30% para los usuarios de Habr en un an√°logo √ļnico de servidores de nivel de entrada que inventamos para usted: toda la verdad sobre VPS (KVM) E5-2650 v4 (6 n√ļcleos) 10GB DDR4 240GB SSD 1Gbps de $ 20 o c√≥mo dividir el servidor? (las opciones est√°n disponibles con RAID1 y RAID10, hasta 24 n√ļcleos y hasta 40GB DDR4).

VPS (KVM) E5-2650 v4 (6 n√ļcleos) 10GB DDR4 240GB SSD 1Gbps hasta la primavera sin cargo al pagar por un per√≠odo de seis meses, puede ordenar aqu√≠ .

Dell R730xd 2 veces más barato? ¡Solo tenemos 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV desde $ 249 en los Países Bajos y los Estados Unidos! Lea sobre Cómo construir un edificio de infraestructura. clase utilizando servidores Dell R730xd E5-2650 v4 que cuestan 9,000 euros por un centavo?

Source: https://habr.com/ru/post/438332/


All Articles