Universidad Estatal de Adams. Cómo hackear sitios web. Parte 1Hablemos 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?