Archivo
WEB HACKING – Atacando DOJO Hacme Casino – Controladores inseguros en Ruby OnRails – Parte XXVIII
HacMe Casino es una aplicación deliberadamente vulnerable que se encuentra escrita utilizando el framework Ruby On Rails, hasta este punto se han mencionado algunas vulnerabilidades que se suelen encontrar en muchas aplicaciones web, independiente de la plataforma utilizada, tales como SQL Injections, XSS Stored/Reflected, CSRF, Session Fixation, etc. Sin embargo, para un atacante siempre resulta útil conocer como funciona la plataforma que es utilizada para servir el sitio web, tanto el lenguaje de programación como el servidor, como se ha mencionado en reiteradas ocasiones, la información es la clave, entre más información se cuente sobre un objetivo, es mucho más probable realizar ataques exitosos.
WEB HACKING – Atacando DOJO Hacme Casino – Otras Vulnerabilidades Parte XXVII
Las dos vulnerabilidades que se han explicado anteriormente sobre HacMe Casino, permitían que cualquiera pudiera acceder y manipular de forma arbitraria, la información de otros usuarios en el sistema. En está ocasión se examinarán otras vulnerabilidades existentes en la aplicación para poder analizar su impacto.
WEB HACKING – Atacando DOJO Hacme Casino – Vulnerabilidad CSRF Parte XXVI
En el articulo anterior, ya teníamos acceso a la aplicación utilizando una cuenta de usuario valida, gracias a una vulnerabilidad de SQL Injection que permitía realizar un “ByPass” del mecanismo de autenticación implementado (login/password). Se trata de una vulnerabilidad que, aunque cada vez suele ser más rara de encontrar, sirve para demostrar lo que es una Blind SQL Injection en todo su esplendor…
En esta ocasión, aprovechando que ya se cuenta con acceso a la aplicación, se procederá a analizar las algunas peticiones HTTP de la aplicación para intentar detectar cualquier otra “brecha” que nos permita hacer más “daño”. Para ello, como el lector seguramente ya comprenderá, basta con utilizar un proxy web como por ejemplo Burp Proxy, OWASP Zap o incluso algún que otro plugin de Firefox que sirve, básicamente para lo mismo, como por ejemplo Tamper Data o Live HTTP Headers.
Pasando de Netcat a Cryptcat
Hace algún tiempo escribí algunos posts en los que hablaba sobre el uso de herramientas como Netcat, Socat y SSH para establecer conexiones seguras y no tan seguras con otras máquinas (aquí empieza: http://thehackerway.com/2011/08/03/herramientas-para-hacking-en-entornos-de-red-telnet-parte-i/ ). En esa serie de posts, se hablo sobre los beneficios de utilizar Netcat o Socat y como estas herramientas eran claramente superadas por el todo-poderoso protocolo SSH, sin embargo a día de hoy, aun son muchos los que suelen utilizar Netcat para establecer conexiones con hosts remotos y lo suelen utilizar para “jugar” con el establecimiento de puertas traseras, por este y otros motivos, Netcat es conocido por muchos la “Navaja suiza” de los hackers y administradores, ya que es versátil, facilidad de usar, fácil de instalar y la puedes llevar prácticamente a cualquier parte ya que es muy liviana, sin embargo tiene el mismo problema que tiene Telnet: Los paquetes no se cifran, lo que quiere decir todo lo que se transmita por el canal de comunicación establecido por Netcat, puede ser fácilmente capturado por cualquier sniffer. Ahora bien, la solución a esto, como se ha mencionado anteriormente, es utilizar un protocolo de comunicación seguro como lo es SSH, sin embargo, en esta ocasión quisiera hablar de otras herramientas que funcionan igual que Netcat (es decir, con las mismas opciones y demás) pero que además realiza el cifrado de los paquetes transmitidos en el canal de comunicación, algo que viene muy bien en muchos casos.
WEB HACKING – Atacando DOJO Vulnerabilidades SQL Injection en Hacme Casino Parte XXV
En la entrada anterior, se hablo un poco sobre una aplicación vulnerable incluida en Dojo llamada HacMe Casino, se realizo un proceso de recolección de información muy rápido (de hecho, insuficiente, pero muy ilustrativo) para determinar la plataforma utilizada por la aplicación y se encontró una posible vulnerabilidad de tipo SQL Injection, en esta entrada, se utilizarán herramientas tales como SQLMap para detectar y explotar otras fallas de seguridad encontradas en esta aplicación. Cabe anotar, que en esta entrada y en la próxima, se asumirá que el enfoque seguido es el de Caja Negra es decir, que toda la información será extraída sin disponer del código fuente de la aplicación, en el caso contrario, se utilizaría un enfoque que Caja Blanca en tales casos, el pentester cuenta con el código fuente de la aplicación y en consecuencia podrá realizar un análisis mucho más profundo de las funciones del sistema. Evidentemente, desde el punto de vista de la seguridad ofensiva ambos enfoques son importantes, pero realizar pruebas de caja negra, permite de alguna forma, ponerse en el lugar de un atacante, el cual necesita recolectar toda la información que pueda para entender el sistema y en la mayoría de casos no cuenta con el código fuente. A menos claro, de que la aplicación objetivo sea opensource, en tal caso podría disponer también del código fuente y realizar, del mismo modo, pruebas de caja blanca.
WEB HACKING – Atacando DOJO Enumeración Hacme Casino Parte XXIV
A partir de está publicación y hasta el final, esta serie de artículos será un poco más entretenida, ya que se comenzará a utilizar herramientas comunes para atacar aplicaciones web con ejemplos prácticos. Para continuar desde aquí, con el resto de publicaciones de esta serie, se asume que el lector tiene configurada una máquina virtual con DOJO, tal como se explico hace algunos meses en esta publicación:
WEB HACKING – Vulnerabilidades en XAMPP (Continuación) – Parte XXIII
En la publicación anterior, se han mencionado algunas de las vulnerabilidades más conocidas en XAMPP y dado que no se han mencionado otras que han sido bastante llamativas, la intención de esta publicación es mencionar algunas más y explicar su impacto.
XAMPP 1.7.7
En esta versión del producto, se han encontrado un par de vulnerabilidades del tipo XSS y SQL Injection, en algunas de las páginas por defecto que vienen en el contexto por defecto, que si bien su impacto debería ser nulo en un servidor correctamente configurado, en una instalación por defecto, el resultado puede ser un servidor comprometido.
WEB HACKING – Vulnerabilidades en XAMPP – Parte XXII
Aunque es una muy buena practica, instalar todos los componentes y librerías de un servidor web Apache, para muchos es muy cómodo utilizar “paquetes” que incluyen muchas librerías y software de uso común, como por ejemplo PHP, Perl, MySQL, etc. Este tipo de paquetes, permiten que un desarrollador pueda comenzar a trabajar en su aplicación web rápidamente sin tener que preocuparse demasiado por la configuración del servidor web y de los módulos necesarios para ello. XAMPP es uno de estos paquetes y actualmente se encuentra muy difundido, ya que incluye Apache, PHP, Perl, MySQL, ProFTPD, OpenSSL, PHPMyAdmin, entre otras herramientas y utilidades. Sin embargo, en muchas ocasiones el riesgo que se tiene con este tipo de productos, es que al final, el proveedor siempre intentará que su producto sea compatible con la mayor cantidad de plataformas posibles y para ello, en algunas ocasiones, intentan hacer uso de configuraciones estándar que no son simpre tan seguras u óptimas como debería.
W3AFRemote r01 Liberado…
El día de hoy, después de algunos meses, he liberado la primera versión (espero que mas o menos estable) de W3AFRemote: http://sourceforge.net/projects/w3afremote/.
WEB HACKING – Atacando servidores web vulnerables Tomcat – Parte XXI
Apache Tomcat es uno de los servidores web para Java más conocidos y utilizados, es liviano, fácil de instalar y muy cómodo a la hora de desarrollar aplicaciones web con Java, además es posible utilizarlo para desarrollo de aplicaciones un poco más complejas que la típica aplicación web con JSP, ya que es posible integrar en él implementaciones como MyFaces, Primefaces, RichFaces y otras implementaciones de JSF (librería estándar, definida en J2EE para el desarrollo de aplicaciones web dinámicas utilizando Java).
WEB HACKING – Clasificación de Ataques web – Parte XVII
Los vectores de ataque más utilizados y mejor aprovechados por atacantes en redes como internet, en un gran porcentaje están relacionados con aplicaciones y servidores web vulnerables. Una de las principales razones de esto es lo fácil que es para un atacante acceder a una potencial víctima desde cualquier ordenador conectado y utilizando herramientas tan comunes como un navegador web, además de que en muchas ocasiones por múltiples razones, se le da muy poca importancia a la seguridad de las aplicaciones y esto al final, trae consecuencias muy negativas que suelen traducirse en servidores hackeados. Todo esto no es un secreto para nadie, sin embargo seguimos desarrollando aplicaciones inseguras y por que? Pueden haber muchas razones, sin embargo esto se debe principal, por desconocimiento y falta de interés o motivación para hacer las cosas bien y al hacer las cosas bien me refiero, a que por lo menos, antes de liberar una aplicación en internet que es critica, realizar al menos, una auditoria de seguridad en profundidad.
WEB HACKING – Módulos y Librerias en servidores web Apache – Uso de MOD_CACHE – Parte XVI
Partiendo de la publicación anterior a está, intentaré profundizar un poco más sobre el uso del módulo MOD_CACHE haciendo uso de las directivas disponibles.
Más Directivas para controlar HTTP headers
Ademas las directivas que se han explicado en la anterior publicación existen algunas otras directivas bastante interesantes que permiten realizar operaciones muy concretas sobre algunos headers HTTP que suelen ser muy importantes no solo para las aplicaciones web, sino también para el funcionamiento de algunas características propias del servidor web.
WEB HACKING – Módulos y Librerias en servidores web Apache – Uso de MOD_CACHE – Parte XV
MOD_CACHE es un módulo del servidor web Apache que como casi todos los módulos existentes en este servidor web, existe para cubrir las funcionalidades definidas en los estándares en las múltiples RFC existentes, en este caso concreto MOD_CACHE intenta cubrir las especificaciones técnicas que se describen en la RFC 2616, la cual describe un amplio conjunto de funcionalidades para el protocolo HTTP 1.1, entre las que se incluyen, el uso de las caches y los mecanismos de control, definiendo que tipos de contenidos pueden ser “cacheables” y que tipo de elementos pueden almacenarse en dicha cache.
Review sobre Offensive Security Certified Professional (OSCP).
Offensive Security (www.offensive-security.com) es una organización que se encarga de realizar diferentes tipos de actividades relacionadas con el mundo de la seguridad informática, se destacan principalmente por contar con el equipo de creadores de la famosa distribución BackTrack. Ofrecen servicios de auditoria externa e interna y algunos otros servicios que van por la misma linea, sin embargo, una de las cosas más interesantes que tienen es su catalogo de certificaciones, las cuales son diferentes a las que actualmente solemos encontrar en el mercado. Que es lo que hace diferentes a este tipo de certificaciones de otras tan conocidas y prestigiosas como las CEH, CISA, CISSP, etc.? La respuesta es, su enfoque completamente practico. Con las certificaciones anteriores, normalmente sueles asistir a un curso y presentas un examen que tiene un fuerte contenido teórico, donde la mayoría de preguntas son de selección múltiple. Mi opinión personal sobre ese tipo de exámenes es que no demuestran realmente los conocimientos de alguien, resalto nuevamente las palabras opinión personal y este es uno de los motivos por los que he elegido el “challenge” OSCP de OFFSEC.
WEB HACKING – Módulos y Librerias en servidores web Apache – Usando MOD_PROXY – Parte XIV
Llegados a este punto, se han abarcado algunos de los módulos más interesantes que pueden utilizarse en un servidor web Apache, en esta ocasión se hablará sobre otro módulo que me parece muy útil e interesante, se trata de Mod_Proxy. Este módulo, tal como su nombre lo indica permite crear conexiones de tipo “proxy” esto quiere decir que una conexión entre dos entidades no se realiza de forma directa, sino que en su lugar hay un elemento intermedio por el que pasan todos los paquetes de datos. En algunas publicaciones anteriores en este blog, se ha hablado del uso de túneles SSH para la redirección del trafico entre distintas máquinas, existiendo túneles locales y remotos, pues la filosofía de Mod_Proxy es bastante similar, si bien no es tan robusto y potente como las mencionadas características de SSH, se trata de un módulo bastante útil en determinadas situaciones.
WEB HACKING – Módulos y Librerias en servidores web Apache – MOD_EVASIVE contra ataques DoS – Parte XIII
Actualmente, uno de los ataques más comunes y que prácticamente cualquier persona o grupo de personas puede llevar a cabo contra un sistema en internet, son los ataques de denegación de servicio (DoS) tanto desde una única ubicación (dirección IP) como desde múltiples ubicaciones (DDoS Distributed Denial Of Service), el objetivo obvio de este tipo de ataques, es interrumpir la actividad normal de un servidor durante un periodo de tiempo determinado o de forma indefinida. Se trata de un tipo de ataque que en la mayoría de los casos, solamente requiere “masa”, es decir, una gran cantidad de peticiones en intervalos de tiempo cortos contra un sistema determinado desde una o varias ubicaciones, normalmente los atacantes no necesitan tener conocimientos profundos sobre hacking (o informática general), es por este motivo que en los últimos años este tipo de ataques resultan tan frecuentes.
WEB HACKING – Módulos y Librerias en servidores web Apache – Reglas de OWASP para MOD_SECURITY – Parte XII
Después de haber leído las publicaciones anteriores sobre MOD_SECURITY, ya se contará con conocimientos suficientes para entender su funcionamiento y la potencia de las características que incluye, sin embargo no cabe duda que las características mas robustas en este módulo están relacionadas con el motor de reglas que es altamente personalizable. Como con cualquier Firewall de Aplicaciones, IDS o NIDS, las herramientas por si solas no proveen seguridad, es necesario implementar las reglas necesarias que dependen enteramente de las políticas de seguridad que se tengan, tal como se mencionaba hace algunos meses en las publicaciones relacionadas con SNORT, un IDS por si solo no puede hacer mucho ante diferentes tipos de ataques que se lleven a cabo en entornos de red, sin embargo su verdadera potencia radica en lo robustas que sean las reglas y las alarmas que se configuren sobre la herramienta. Estas mismas premisas que aplican en SNORT, también aplican en este caso a MOD_SECURITY, tener un buen conjunto de reglas es lo que hace que este módulo funcione realmente bien.
adastra
