30 abr 2014

¡Apúntate a nuestra Certificación en Auditoría de Seguridad de la Información!

Buenas a todos, el próximo 30 de Mayo de 2014 arrancaremos desde Zink Security la primera edición de nuestra Certificación en Auditoría de Seguridad de la Información (CASI). Se trata de una formación especializada de 125 horas, que ha sido diseñada y planificada pensando en capacitar a un grupo de profesionales en el ámbito de la auditoría de seguridad de la información.

La formación se encuentra dividida en 6 módulos, impartidos todos los viernes de 16:00 a 21:00h (salvo puentes y festivos).

A continuación os listamos los módulos de los que se compone la formación:
  • Módulo 1: Introducción a la Seguridad de la Información y al hacking ético (20 horas)
  • Módulo 2: Auditoría de Seguridad en equipos informáticos (20 horas)
  • Módulo 3: Pentesting en Aplicativos Web (20 horas)
  • Módulo 4: Auditoría de Seguridad en Redes de Datos (20 horas)
  • Módulo 5: Seguridad y Criptografía (20 horas)
  • Módulo 6: Análisis Forense Pericial en entornos Windows, Linux, Mac OS, Android, iOS y Blackberry (20 horas)
  • Jornada de despedida y examen final (5 horas)
La formación será impartida por profesionales de la talla de Pablo González (Project Manager de 11Paths y Co-Autor de Flu Project), Juan Antonio Calles (Socio fundador de Zink Security S.L. y Co-Autor de Flu Project), Juan Luis G. Rambla (Director del Departamento de Seguridad TIC de Sidertia Solutions S. L.), Ignacio Briones Martínez (Jefe de Equipo de Sidertia Solutions S.L.) y Alejandro Martín Bailón (Consultor Experto en Seguridad Web).

En caso de que solamente estéis interesados en cursar algunos módulos en concreto, también podéis apuntaros y recibiréis una certificación correspondiente a los contenidos abordados en los mismos.

Aspectos clave de CASI:
  • Duración: 125 horas distribuidas en 6 módulos de 20
    horas y una jornada final de 5 horas. También es posible asistir a uno o
    a varios módulos independientes
  • Horario: 16:00 a 21:00 con una periodicidad de Viernes.
  • Inicio: 30 de Mayo de 2014.
  • Finalización: 30 de Enero de 2015.
  • Vacaciones: Habrá un parón vacacional entre los días 11 de Julio y 5 de Septiembre (ambos no incluídos)
  • Lugar: CBCenter. C/Jacinto Verdaguer, 17. 28019 - Madrid (Madrid)
  • Límite de alumnos: 15.
  • Material: Kit de bienvenida (mochila con bolígrafo, cuaderno y material del curso).
  • Repositorio: Repositorio online con acceso a todos los contenidos del curso (libros, presentaciones, software, etc.)
  • Precio formación completa: 1.950euros+IVA. Descuento especial del 5% para estudiantes universitarios, personas en situación de desempleo y miembros de fuerzas y cuerpos de seguridad del estado.
  • Precio por módulo: 400euros+IVA (sujeto a disponibilidad)
  • Público objetivo: Administradores de TI,
    desarrolladores, consultores, auditores, analistas, estudiantes,
    miembros de fuerzas y cuerpos de seguridad, etc.
Para apuntaros a la formación o solicitar más información, podéis poneros en contacto con nosotros a través de nuestra dirección de correo (info@zinksecurity.com) o vía telefónica, y nuestros profesionales os atenderán.



¡Saludos!

    29 abr 2014

    Phishing, ¿Por qué sigues funcionando?

    Hoy en día el phishing sigue siendo una amenaza real con la que muchas compañías luchan en Internet. La imagen de éstas se encuentra en juego, y esto puede afectar a los planes de negocio de éstos. Leyendo el artículo de Sergio de los Santos, http://unaaldia.hispasec.com/2013/02/10-anos-de-phishing-la-eficacia-de-lo_27.html, sigue funcionando debido a la simplicidad de éste.

    Analizando de manera cuidadosa los pilares del phishing podemos entender que, hace diez años se asentaban sobre:
    • Falta de conocimiento de seguridad por parte de los usuarios, ni concienciación sobre el tema ya que comenzaba. La mayoría de los usuarios de Internet no son capaces de distinguir dos páginas distintas, mails válidos o no, incluso comportamientos, ninguna entidad bancaria te pedirá tu contraseña por Internet.
    • Lo que el ojo ve. Cuando una dirección web comienza por ingdirect o por lngdirect (la primera una i, la segunda una L) es difícil de diferenciar por el ojo humano
    • Atención casi nula a los indicadores de seguridad. Certificados caducado, con identidad no validad, sin navegación segura, etcétera, son situaciones del día a día, en la mayoría de los usuarios que utilizan la tecnología. 
    El phishing se va portando a otras plataformas como los dispositivos móviles. La irrupción de los smartphones y todas estas nuevas tecnologías de bolsillo y pantallas reducidas, incluso tablets, abren una nueva puerta a los phishers. A continuación, con fuente de http://www.seguridadapple.com/2013/10/phishing-client-side-attacks-ios-sigue.html. Se presentan distintos conceptos que han sido heredados, en mayor o menor medida, de los ordenadores y que afectan a los smartphones, el nuevo caramelo del phishing:
    • Bar spoofing. Las barras de navegación se ocultan en los navegadores de los smartphones para mejorar la experiencia de usuario y disponer de una mayor superficie en la pantalla para mostrar la información. El bar spoofing, es una técnica utilizada por phishers para engañar al usuario de que la información que se ve en la barra de navegación es verídica. 

    • En las propias aplicaciones los desarrolladores disponer de componentes como el UIWeb View, para Android e iOS, con los que se embebe un navegador como vista dentro de la aplicación. Por ejemplo, la aplicación de Gmail, cuando ejecuta un link no abre el navegador y sí éste tipo de vista.
     
    • Las barras de direcciones no son muy grandes en pantallas de 3.5, 4, 5 pulgadas. Los phishers también lo saben y por ello utilizan una técnica denominada "muestro subdominio que corresponda con dominio real y te robo". El ejemplo es el siguiente, la URL que se muestre aparece sin protocolo (para que sea más estético) y siempre con el valor del dominio más a la izquierda posible, por ello si utilizamos el siguiente subdominio www.mibanco.es.dominiomalicioso.com, con un poco de suerte y colocación podremos dejar solo visible en la barra de direcciones la parte de www.mibanco.es
    En conclusión, se puede entender que las vías y técnicas van mejorando con el paso de los años, aunque en esencia todo es muy similar. El problema viene por un lado de pequeños fallos de diseño desde el punto de vista de la seguridad, y la no concienciación de los usuarios y poco conocimiento sobre el tema. 

    28 abr 2014

    Seguridad en AJAX (Parte III)

    En el artículo anterior hablamos de los detalles sobre componentes y seguridad en AJAX, hoy nos toca avanzar y finalizar la serie. Avanzaremos en XPATH y XML Injection. Los XPATH inyectados en SOAP son una amenaza y es una acción similar a una inyección SQL. El lenguaje utilizado es XPATH y el objetivo del ataque son los documentos XML.

    Algo que hay que tener muy en cuenta son las validaciones de cliente y no realizadas en la parte del servidor. Este hecho es quizá una de las mayores amenazas a las que se enfrenta AJAX y cualquier tecnología que se encuentre en el lado del cliente. Toda petición debe ser validada en el lado del servidor, independientemente de si se hace una validación en el cliente.

    ¿Cómo solucionamos?

    Se propone el siguiente listado:
    • El código de Javascript se debe ejecutar mediante el uso de una sandbox, con lo que todo lo malicioso que se intente ejecutar queda aislado y sin acceso a los recursos de interés de la máquina atacada. 
    • No establecer conexiones con sitios diferentes del nombre de dominio del que se ha obtenido el script de Javascript. De este modo se puede proteger de problemas de seguridad y esta medida se denomina CORS, Cross-Origin Resource Sharing.
    • Los ficheros Javascript que se han obtenido desde un sitio en concreto no deben poder accder a propiedades de otro sitio. 
    • Validación de todos los campos de entrada y comprobación siempre en el lado del servidor, de otra manera cualquier acción que se valide en el cliente puede ser manipulada, por ejemplo mediante el uso de un proxy. 
    • Implantar controles de seguridad como pueden ser autenticación, autorización, e incluso registro de operaciones o logging, siempre en el lado del servidor. 
    • Utilizar métodos POST en vez de métodos GET. 
    • Se debe tener en cuenta los ataques clásicos como SQLi y XSS por lo que buscarlos especialmente y XSRF, los cuales podrán ser solventados mediante un filtrado correcto o utilización de tokens correctamente en el caso del XSRF. 
    • No almacenar jamás datos sensibles o confidenciales en el lado del cliente, este hecho haría que obtenerlos por un atacante fuera algo potencialmente sencillo. 
    • Utilización de métodos criptográficos para transmitir datos sensibles o confidenciales entre el cliente y el servidor. 
    • La lógica de negocio debe tener el principio de mínima exposición y encontrarse siempre en el lado del servidor. 
    • Toda petición realizada con AJAX y que acceda a recursos protegidos deberán encontrarse autenticadas.
    Se puede entender fácilmente que las tecnologías estudiadas en este trabajo, englobadas en la web 2.0 pueden sufrir ataques tal y como ocurría en la web 1.0. La auditoría y el S-SDLC es algo totalmente necesario para minimizar la ocurrencia de las posibles amenazas que se han tratado en el presente documento.

    ======================================================
    - Seguridad en AJAX (Parte I)
    - Seguridad en AJAX (Parte II)
    - Seguridad en AJAX (Parte III)
    ======================================================

    27 abr 2014

    Informe Flu - 173


    Buenas a todos, como cada domingo, os dejamos con nuestros “Enlaces de la semana”: 

    Lunes 21 de Abril
    Martes 22 de Abril
    Miércoles 23 de Abril
    Jueves 24 de Abril
    Viernes 25 de Abril
    Saludos!

    26 abr 2014

    Videos e infografias sobre seguridad en Internet

    Buenas a todos, desde el colectivo que formamos todos y cada uno de los miembros de X1RedMasSegura y con motivo del Concurso de Infografias 2014, del que tenéis más información AQUÍ, hemos lanzado una serie de videos muy interesantes para que podáis utilizarlos libre y gratuitamente en cursos y charlas, con el objetivo de facilitar la llegada del conocimiento sobre los peligros de la red a todos los públicos.

    Os dejamos con los videos a continuación, ¡no os los perdáis!:









    Un abrazo especial a nuestra compañera Blanca por las horas y el trabajo que está poniendo durante todo el transcurso del concurso :)

    Saludos!

    25 abr 2014

    Creando un entorno vulnerable. Parte 4

    Buenas a todos, continuando con la cadena de artículos sobre la creación de un entorno vulnerable, hoy vamos a construir una página web vulnerable a Remote File Inclusion (RFI).

    RFI es una vulnerabilidad característica de las páginas dinámicas en PHP, que permite enlazar archivos por un fallo en el desarrollo de la página (debido a un mal uso de las funciones include, include_once, require y require_once, que posibilitan la inclusión remota de archivos que no se encuentran por defecto en el servidor).

    Vista esta leve introducción, vamos al lío :)

    En primer lugar vamos a crearnos un archivo PHP en la raíz de nuestro servidor WAMP, y de igual manera que en las anteriores ocasiones, llamaremos a nuestro archivo "rfi1.php", matizando con el nº 1 el nivel técnico requerido para bypasear la vulnerabilidad.

    Dentro del archivo introduciremos el siguiente código PHP:



    Si intentamos acceder a la URL sin indicar ningún valor en el parámetro "file", deberíamos ver un error como el siguiente:



    Vamos a poner una imagen como ejemplo, para mostrar su contenido en nuestra página. Cómo veis es un ejemplo un poco burro, pero aclarará rápidamente el funcionamiento de un RFI:



    El problema de este tipo de vulnerabilidad, es que si un usuario sustituye esta imagen por un archivo PHP ejecutable, podrían ejecutar cualquier tipo de código en el servidor, y tomar su control.

    Por ejemplo, ejecutaremos un comando ipconfig, para ello crearemos el siguiente código PHP, al que llamaremos "shell.php":



    Ahora llamaremos a nuestra página web vulnerable, pasándole como parámetro la shell básica que acabamos de implementar:

    Cómo veis, nos ha ejecutado el comando "ipconfig" y nos ha presentado el resultado en la página, así que ya tenemos cierto control sobre la máquina. Ahora podríamos subir una consola completa PHP para automatizar el lanzamiento de muchas instrucciones, aunque no todas, dependerá de si el usuario que ejecuta el aplicativo en el servidor tiene más o menos permisos, si es root (algo improbable), de si se trata de un hosting compartido (lo que nos ayudaría a comprometer otras páginas, aunque sería un grave error), etc.

    Nuestro entorno comienza a crecer con cuatro páginas web vulnerables a XSS, SQL Injection, Xpath Injection y Remote File Inclusion de nivel 1. En el próximo post seguiremos ampliando nuestra máquina.

    Saludos!

    24 abr 2014

    Publicados los horarios para los Talleres de X1RedMasSegura 2014

    Buenas a todos. Ya se encuentran disponibles los horarios definitivos para cada uno de los Talleres que tendrán lugar durante los dos semanas de las Jornadas X1RedMasSegura 2014. 

    A continuación os listamos los horarios definitivos de cada uno de los talleres, así como su lugar de realización:

    Talleres en IPA Madrid
    • Día 8 de Mayo: Taller para Ciberabuelos (20 plazas). De 17:00h a 20:30h
    • Día 9 de Mayo. Taller para Padres y Taller paralelo para Niños mayores de 10 años (20 plazas cada taller). De 18:00h a 21:00h
    • Día 12 de Mayo: Taller para Internautas Base (20 plazas). De 17:00h a 20:30h

    Talleres en la Plaza de Toros de Alcalá de Henares
    • Día 10 de Mayo: Taller para DisCAPACITADOS. De 18:00h a 19:00h

    Talleres en UDIMA
    • Día 13 de Mayo: Taller para Educadores (100 plazas). De 18:00h a 21:00h

    Talleres en el Vivero de empresas de Móstoles
    • Día 14 de Mayo: Taller para Empresarios (45 plazas)

    Desde la página UBICACIÓN del sitio web oficial del evento, disponéis de mapas para llegar a cada uno de los talleres:


    Saludos!

    23 abr 2014

    ¡Arrancan las Jornadas X1RedMasSegura 2014!


    Las Jornadas X1REDMASSEGURA nacieron en 2013 con el propósito de promover a través de un foro el uso de Internet de una manera confiable y segura. Su objetivo es hacer llegar a todos los públicos, independientemente de sus conocimientos técnicos en informática, el uso adecuado y responsable de los recursos disponibles en la red con el fin de evitar ser víctimas de abusos fraudulentos, estafas, acoso, grooming, y tantos otros problemas que cualquier navegante puede sufrir en Internet si no cuenta con unos conocimientos adecuados.

    Esta segunda edición del evento también se encuentra coordinada por el colectivo X1RedMasSegura, que desde su nacimiento en 2013 ha ofrecido sus ganas y todo su apoyo por hacer de estas jornadas algo grande, sin ningún ánimo de lucro. 

    Las Jornadas durarán dos semanas, del 8 al 17 de Mayo. Comenzarán por una serie de talleres GRATUITOS que se celebrarán del 8 al 14 de Mayo en las sedes de IPA Madrid, del Vivero de Empresas de Móstoles y de la UDIMA, para Padres, Niños, Ciberabuelos, Empresarios, Profesores e Internautas Base, en los que se enseñarán como protegerse de la red de redes sin necesidad de ser experto ni en Informática, ni en Seguridad de la Información. Entre los temas que se tratarán se encuentran porqué es necesario utilizar HTTPS, cómo crear una contraseña segura, seguridad en redes sociales, etc. Los talleres tienen un máximo de 20 plazas cada uno (a excepción de los talleres de Seguridad para Empresas que tendrá 40 plazas y del taller para Profesores, que tendrá 100 plazas), y podréis apuntaros GRATUITAMENTE desde el siguiente formulario de inscripción:


    Además, el día 10 de mayo tendrá lugar un taller dirigido a personas con discapacidad, gracias al Programa de Atención Integral a la Discapacidad del Ayuntamiento de Alcalá de Henares, que tendrá lugar en el Espacio Joven, situado en los bajos de la plaza de toros de Alcalá de Henares a las 18h

    Los días 16 y 17 de Mayo se celebrará el evento principal en el auditorio de la Escuela Técnica Superior de Ingenieros de Telecomunicación (ETSIT) de la Universidad Politécnica de Madrid, localizada en la "Ciudad Universitaria". Las jornadas comenzarán el viernes 16 a las 16:00 horas y finalizarán el sábado a las 14:30 horas. Al igual que los talleres, las jornadas van dirigidas a público no técnico y en ellas se tratarán problemas actuales como las estafas cibernéticas, malware (virus), nuestros derechos en la red, la nube, etc., explicado para ser entendido por todos los niveles.

    A continuación os dejamos la dirección para llegar tanto a los talleres como al lugar donde se celebrarán las jornadas:


    Esperamos que las jornadas sean un éxito, las disfrutéis y sobretodo que sirvan para lo que queremos, conseguir entre todos 1Red MasSegura.

    Aprovechamos para recordaros que sigue abierto el concurso "Infografías Jóvenes x1RedMasSegura '14" hasta el próximo 4 de Mayo, con el objetivo de concienciar y educar a los más jóvenes en el uso seguro y responsable de Internet.

    En los próximos días se publicarán en el blog oficial de X1RedMasSegura las agendas definitivas de todos los talleres y de las jornadas, junto con los nombres de todos los ponentes.

    Artículo cortesía del colectivo #X1RedMasSegura

    22 abr 2014

    Creando un entorno vulnerable. Parte 3

    Buenas a todos, continuando con la cadena de artículos sobre la creación de un entorno vulnerable, hoy vamos a construir una página web sencilla vulnerable a XPath Injections.

    En primer lugar vamos a crearnos un archivo PHP en la raíz de nuestro servidor WAMP, y de igual manera que en las anteriores ocasiones, llamaremos a nuestro archivo "xpath1.php", matizando con el nº 1 el nivel técnico requerido para bypasear la vulnerabilidad.

    Dentro del archivo introduciremos el siguiente código PHP, en el que incluiremos una variable con un XML, que a modo de BBDD guardará un usuario y una contraseña, y al que intentaremos acceder más adelante mediante Xpath:
    <?php
    $user = $_GET["user"];
    $pass = $_GET["pass"];
    $string = <<<XML
    <users>
        <user>
            <username>admin</username>
            <password>fluprojectmola</password>
        </user>
    </users>
    XML;
    $xml = new SimpleXMLElement($string);
    $resultado = $xml->xpath("//users/user[username/text()='" . $user . "' and password/text()='" . $pass . "']");
    if($resultado)
        echo 'Correcto';
    else
        echo 'Incorrecto';
    ?>

    Si intentamos acceder a la URL sin indicar ningún parámetro deberíamos ver un error como el siguiente:

    Ya sabemos que la aplicación espera dos parámetros, "user" y "pass".

    Si introducimos los parámetros correctamente, veremos por pantalla el mensaje "correcto":

    Y de la misma manera, si los introducimos mal, nos saldrá el mensaje "incorrecto":

    Si intentamos hacer una inyección sencilla, aunque no consigamos robar el usuario y contraseña, nos cantará la función utilizada para acceder a la BBDD XML:

    Con estas pistas ya lo tenemos un poco más facil para acertar con una inyección válida:

    Como veis en este caso ni es necesario introducir valor alguno en la variable "pass", y simplemente con una inyección de tipo "or 1=1" , y añadiendo otra expresión después para cerrar la comilla abierta, es más que suficiente para bypasear esta sencilla autenticación.

    Bien, ya tenemos en nuestro entorno vulnerable tres páginas web, con fallos de seguridad de tipo XSS, SQL Injection y Xpath Injection de nivel 1. En el próximo post seguiremos ampliando nuestra máquina.

    Saludos!

    21 abr 2014

    Abre tu garaje desde Android o iPhone con Raspberry Pi (Parte II)

    Siento la tardanza del post, han pasado meses desde que se publicó el último, espero que disfrutéis con los que nos quedan! La siguiente parte del proyecto, obviamente consiste en el montaje electrónico de los relés, para actuar sobre cualquier tipo de dispositivo. 

    En este caso, yo lo he utilizado para la puerta del garaje, pero es perfectamente funcional para cualquier otra situación eléctrica controlada por un relé. Lo primero que debemos de saber, es como funcionan los “pines” de la RPi. En la mayoría de los casos, las RPi que compramos son Revisión 2.0 así que voy a adjuntar el esquema.


    En el primer post podemos ver que el servidor está configurado para los GPIO7 y GPIO 8. En realidad solo es necesario uno, pero yo añadí otra salida para otro relé que enciende la luz del garaje. A partir de aquí hay 2 opciones. Montar el circuito electrónico manualmente, o por el contrario, comprar un módulo de relés con etapa, que te evita la polarización de los transistores y demás. Para este artículo vamos a utilizar el módulo, ya que facilita sensiblemente el voltaje, y no merece la pena comprar los componentes por separado.

    Podéis comprar algo como esto, que no llega a 4€. http://www.dx.com/es/p/el817-2-channel-5v-10a-relay-module-deep-blue-297553#.U0-32JGFRFQ


    Una vez tengamos el módulo de relé, simplemente tenemos que conectar los pinas correspondientes a la RPi, y obviamente, conectar el dispositivo o circuito a controlar a través de las entradas (verdes) del relé.


    RELÉ RPi
    VCC —> Pin 2
    GND —> Pin 6
    IN1 —> GPIO7
    IN2 —> GPIO8

    Una vez hecho esto, el sistema debería estar funcionando perfectamente utilizando el servidor y el cliente del primer post. En el siguiente post, ya que hay más densidad de usuarios, seguiremos con el desarrollo de la aplicación de Android.


    Artículo cortesía de: Nico Moral

    20 abr 2014

    Informe Flu - 172

    Hoy, como cada domingo, nos juntamos para recopilar lo que ha ocurrido en Flu Project. Nos acercamos al maravilloso número 200, y es que la cifra de 4 años que se ve a lo lejos nos sigue motivando para seguir día a día con vosotros. 

    Lunes 14 de Abril
    Martes 15 de Abril
    Miércoles 16 de Abril
    Jueves 17 de Abril
    Viernes 18 de Abril
    Sábado 19 de Abril
    Nos vemos en 7 días por aquí, un saludo!

    19 abr 2014

    Resumen por vacaciones

    Aunque algunos se han ido de vacaciones (puedo mirar hacia Juanan), otros seguimos aquí al pie del cañón. Hoy hemos decidido daros un resumen de Flu Project y artículos interesantes de los últimos meses, o que al menos a nosotros y a vosotros (por cantidad de visitas os han parecido interesantes). Comenzamos con el resumen.

    Por otro lado os queríamos dejar con un resumen de algunos posts que nos han llamado la atención de otros blogs, aunque en algunos de ellos hemos participado, no nos lo tengáis en cuenta.

    Y recordar que desde Flu Project comenzamos con la idea de promociona tu blog, donde seguimos esperando que nos enviéis vuestros blogs para poder publicitarlos. Gracias. 

    18 abr 2014

    Seguridad en AJAX (Parte II)

    En el artículo de ayer hablamos de la seguridad en AJAX y se dieron algunas pautas y peligros, hablando principalmente de componentes que forman AJAX. Hoy toca avanza en la línea de mostrar más peligros y mitigación. 

    En la siguiente imagen se puede visualizar un esquema de cómo funciona un XSS con DOM, denominados DOM-Based XSS.


    Un grave problema utilizando AJAX entre nombres de dominios es lo que se conoce como Same Origin Policy. Con este problema de seguridad un script obtenido en un origen puede cargar o modificar propiedades del documento desde otro origen no igual al primero. 


    El envenenamiento XML es otro de los problemas de seguridad a los que nos podemos enfrentar. El servidor debe validar todos los datos que recibe, ya que un posible XML malformado puede causar un crash en el servidor provocando una denegación de servicio. 

    La ejecución de código malicioso también se encuentra en este ámbito, y es importante tenerlo en cuenta. Las llamadas que se realizan con AJAX ejecutan en background sin ninguna interacción del usuario, por lo que el usuario no es consciente de lo que se está realizando en un sitio concreto, por lo que la web puede aprovechar este hecho para realizar un robo de cookies. Es un problema de seguridad que se debe tener muy en cuenta, ya que se puede llevar a cabo de manera silenciosa y poco sospechosa. 

    En la siguiente entrega hablaremos de los últimos peligros y posibles soluciones que ayuden a evitar estas amenazas en AJAX, la tecnología silenciosa...

    17 abr 2014

    Seguridad en AJAX (Parte I)

    En este artículo vamos a comenzar a recopilar los problemas de seguridad que presenta la tecnología AJAX. Esta tecnología cada vez más distribuida por la web 2.0. Primero hablaremos lo que es AJAX y después vamos a hablar de los problemas de seguridad que se tiene y posibles soluciones o formas de mitigación. 

    AJAX, Asynchronous Javascript and XML, es una técnica que permite presentar la información con CSS y DOM. Esta técnica permite crear aplicaciones interactivas ricas, las cuales se ejecutan en el lado del cliente, client-side, en el navegador. El funcionamiento de AJAX es sencillo, mientras la aplicación se ejecuta en el navegador del cliente, la comunicación se lleva a cabo de manera asíncrona en segundo plano con el servidor. Esto permite crear el efecto de que el sitio web va cambiando en función de las necesidades, por la actualización de la información en el servidor, el cual podría ser debido a otras acciones del cliente.


    Ahora vamos a hablar de problemas de seguridad que se tienen que tener en cuenta, para ello hablaremos de lo que está compuesto ya que su seguridad dependerá de la seguridad que tienen los componentes que lo forman.

    Hay que tener en cuenta el aumento de la superficie de ataque, es decir, la parte que se ejecuta o desarrolla en la parte del cliente, y esto hace que la exposición o superficie de ataque sea mayor. La revelación de la lógica de la aplicación hace que los posibles atacantes conozcan parte del código, ya que éste reside en la parte del cliente. Esto hace que el usuario o atacante pueda estudiar e inferir cierta parte de la lógica, y utilizarlo para llevar a cabo acciones maliciosas sobre la lógica de la aplicación. 

    La dificultad de la auditoría de las aplicaciones hace que exista un problema de seguridad, ya que por un lado se debe revisar un mayor número de líneas de código y hace que haya más puntos a revisar. La parte de auditoría hay que llevarla tanto de la parte del cliente como del servidor. 

    Vulnerabilidades clásicas como SQLi o XSS, y nuevas posibilidades para el XSS. SQLi es una de las vulnerabilidades top de OWASP, y sigue siendo una de las principales amenazas en las nuevas tecnologías, hoy en día también con las bases de datos no relaciones, como por ejemplo Mongo Injection. Las nuevas posibilidades para los XSS surgen del almacenamiento de más datos en la parte del cliente y se pueden obtener cookies, credenciales y realizar un robo de información en profundidad. Mediante el DOM y un XSS se puede alterar el contenido de un sitio, modifica la dirección de dónde los datos o formularios de usuarios son enviados, robo de cookies y credenciales, tal y como se mencionó anteriormente. 

    En el siguiente artículo iremos más allá sobre los problemas de seguridad y se centrará el foco en algunas soluciones o mitigaciones para evitar que esto nos pueda proporcionar algún susto.

    16 abr 2014

    Creando un entorno vulnerable. Parte 2

    Buenas a todos, continuando con la cadena de artículos sobre la creación de un entorno vulnerable, hoy vamos a construir una página web sencilla vulnerable a SQL Injections.

    En primer lugar crearemos una BBDD en Mysql, a la que llamaré "cursoseguridad". Dentro de ella crearé una serie de tablas típicas que tendría el sitio web de una organización, como por ejemplo, una tabla con los empleados que trabajan en la misma.



    En segundo lugar vamos a programar una sencilla aplicación en PHP que devuelva por pantalla el nombre y apellidos de todos los empleados que tengan como nombre el texto pasado en el parémetro "nombre" por GET.
    <?php
        $dbhost="localhost";
        $dbusuario="root";
        $dbpassword="";
        $db="cursoseguridad";
        $conexion = mysql_connect($dbhost, $dbusuario, $dbpassword);
        mysql_select_db($db, $conexion);
    ?>
    <html>
        <head>
        </head>
        <body>
            <?php
                $query="SELECT * FROM empleados WHERE nombre='".$_GET["nombre"]."'";
                $resultado = mysql_query($query);
                if($fila = mysql_fetch_array($resultado))
                {
                    do{
                        echo $fila[0].' - '.$fila[1].'<br/>';
                    }while($fila = mysql_fetch_array($resultado));
                }
            ?>
        </body>
    </html>


    Si ponemos por ejemplo el texto Laura, nos pintará el nombre y apellidos de la única Laura que por el momento existe en BBDD:

    Y si intentamos realizar una inyección sencilla del tipo "http://localhost/sqlinjection1.php?nombre=Laura%27%20or%20%271%27=%271", veremos como nos devuelve todos los campos de la tabla "empleados":


    Eso es todo por hoy, nos vemos en el próximo post de la cadena.
    Saludos!

    15 abr 2014

    Creando un entorno vulnerable. Parte 1

    Buenas a todos, ahora que estamos de vacaciones y tenemos algo más de tiempo, queremos dar comienzo a una cadena de posts en la que construiremos nuestra propia máquina virtual vulnerable, para ayudar a toda la gente que esté aprendiendo seguridad de la información y que tenga un sistema al que poder atacar "sin meterse en lios" :)

    Para comenzar he decidido montar una máquina virtual con Windows 7, por ser el sistema operativo más extendido. A lo largo de la cadena iremos configurando la máquina para que tenga el mayor número posible de fallos de configuración/seguridad.

    En este primer post voy a instalar un servidor WAMP, con Apache y Mysql, para crear también un sitio web vulnerable (al estilo de badstore). Omitiré el paso de la instalación, ya que no supondrá ningún reto para vosotros, e iré directamente a la creación de un primer sitio web vulnerable.

    Por cada tipo de vulnerabilidad web existente, iré generando una página que lleve como nombre la vulnerabilidad que expondrá, y continuando con un número de 1 a 5, indicando el nivel de la vulnerabilidad. Estas páginas las dejaremos en la carpeta "www" del wamp, donde hoy crearemos el fichero "xss1.php" (nivel 1-básico):


    Esta aplicación PHP es uno de los ejemplos más sencillos que encontrarés de XSS:
    <?php
        echo $_GET["id"];
    ?>
    Consiste simplemente en mostrar por pantalla mediante la instrucción "echo", cualquier cosa que el usuario escriba en el parámetro "id":

    Si el usuario no introduce ningún parámetro, el servidor devolverá un error, exponiendo la existencia del parámetro "id", y del cual está esperando que le indiquemos un valor para mostrar:

    Y si inyectamos por ejemplo un script sencillo veremos como el sistema se lo come con patatas:


    En la misma línea, también podríamos inyectar código HTML:

    http://localhost/xss.php?id=%3Chtml%3E%3Chead%3E%3C/head%3E%3Cbody%3E%3Cimg%20src=%22https://pbs.twimg.com/profile_images/435322489552789504/pkPwgvTF.jpeg%22/%3E%3C/body%3E%3C/html%3E


    Eso es todo por hoy, en el próximo post seguiremos con nuestro entorno vulnerable.

    Saludos!

    14 abr 2014

    Instalación y configuración del FW Cisco PIX con GNS3. Parte 3



    Buenas a todos, en el post de hoy vamos a continuar la cadena sobre los Firewall PIX y GNS3, con el objetivo de aprender a bloquear servicios hacia y desde máquinas virtualizadas en Virtualbox.

    Continuaremos donde lo dejamos en el post anterior, y vamos a configurar una lista de acceso para denegar el acceso al puerto 80:

    access-list ACLIN deny tcp any any eq 80


    Ahora lo aplicaremos a la interface de salida:

    access-group ACLIN out interface outside


    Y comprobaremos como el firewall nos bloqueará el acceso:


    Si queremos ver el listado de reglas aplicadas en nuestra ACL utilizaremos la instrucción “show access-list ACL”:


    Si queremos eliminar la regla, y volver a tener acceso al servidor WAMP, simplemente repetiremos la instrucción colocando delante el comando “no”:


    Y ahora volveremos a tener acceso al servidor:


    Eso es todo por hoy, nos vemos en el próximo post,

    Saludos!

    13 abr 2014

    Informe Flu - 171


    Buenas a todos, como cada domingo, os dejamos con nuestros “Enlaces de la semana”: 

    Lunes 31 de Marzo
    Martes 1 de Abril
    Miércoles 2 de Abril
    Jueves 3 de Abril
    Sábado 5 de Abril
    • Ayer os hablamos del inicio del Call for papers de la CON Navaja Negra, ¡no te la pierdas!
    Saludos!