Siempre se han escuchado rumores y comentarios de la gente sobre si el gobierno nos espía, si saben todo lo que hacemos, etc. pero, ¿hasta que punto esto es cierto? ¿Es posible que alguien pueda escanear todo lo que hacemos a través de nuestro PC o nuestro teléfono? La respuesta es sí.

Como sabemos no todas las comunicaciones se transmiten de la misma manera ni por el mismo medio, y por este motivo no las podemos tratar a todas de la misma forma. Así que haremos una pequeña clasificación según el medio por el que sean transmitidas estas comunicaciones y veremos como pueden ser interceptadas.

Para hoy miércoles tenemos una entrada de Sergio Galán, alias @NaxoneZ, que ya ha colaborado con Security Art Work en el pasado.

Pueden encontrarle en su blog naxonez.wordpress.com o seguirle en Twitter.

phpLdapAdmin es un front PHP que nos sirve para gestionar nuestro LDAP de una manera más cómoda y fácil. Realmente es una aplicación que nos puede facilitar mucho la vida, pero que como todos software, es vulnerable a diferentes fallos que un usuario remoto puede utilizar para hacerse con nuestro sistema. En concreto, el fallo que vamos a ver en esta entrada es del tipo denominado como “PHP Code Injection Vulnerabilities”; para más información sobre este tipo de ataques, pueden visitar la página correspondiente de OWASP.

Después de darle un pequeño repaso a VRRP, partimos del siguiente escenario. Nos encontramos en una LAN con un grupo VRRP formado por dos routers (A y B) con IP virtual 192.168.1.100. Como vemos en la salida el router A (configurado como Master) tiene una prioridad de 150 y una IP local de 192.168.1.5. En caso de caída, el router B tras un tiempo Master_Down_Timer, asumirá el rol de Maestro (Preemption enabled).

RouterA#show  vrrp
FastEthernet0 - Group 1
  State is Master
  Virtual IP address is 192.168.1.100
  Virtual MAC address is 0000.5e00.0101
  Advertisement interval is 1.000 sec
  Preemption enabled
  Priority is 150
  Master Router is 192.168.1.5 (local), priority is 150
  Master Advertisement interval is 1.000 sec
  Master Down interval is 3.414 sec      

RouterB#show  vrrp
FastEthernet0 - Group 1
  State is Backup
  Virtual IP address is 192.168.1.100
  Virtual MAC address is 0000.5e00.0101
  Advertisement interval is 1.000 sec
  Preemption enabled
  Priority is 100
  Master Router is 192.168.1.5, priority is 150
  Master Advertisement interval is 1.000 sec
  Master Down interval is 3.609 sec (expires in 3.533 sec)

A día de hoy sería extraño no encontrarse con configuraciones HSRP (Hot Standby Router Protocol), GLBP (Gateway Load Balancing Protocol) o VRRP (Virtual Router Redundancy Protocol) en organizaciones de pequeño/gran tamaño y más aún en entornos críticos donde prima la disponibilidad. El motivo es evidente: la mayor parte de los equipos son configurados con un Gateway estático generalmente obtenido por medio de DHCP. En caso de que dicho Gateway deje de funcionar implicaría la pérdida de paquetes hasta que el mismo se restableciera o bien hasta que otro Gateway fuera configurado en cada uno de los equipos. Aunque existen métodos para permitir una configuración dinámica del Gateway (proxy Arp, protocolos de routing RIP/OSPF, “ICMP router discovery protocol”, etc.) estos implican una configuración más “compleja” además de producir cierto overhead en la red. Por este motivo es por el que surgieron protocolos como HSRP, GLBP o VRRP, siendo este último la versión no propietaria de los protocolos desarrollados por Cisco.

Para hoy martes traemos una nueva entrada de Cristina Martínez Garay, de la firma Rocabert & Grau Abogados, bufete que colabora con Security Art Work, en este caso al respecto de la implantación (o mejor, “no-implantación”) de la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos.

Esperamos que les resulte interesante.

Han transcurrido más de cuatro años desde la promulgación de la Ley 11/2007, de 22 de junio, de acceso electrónico de los ciudadanos a los Servicios Públicos y dos desde la publicación de su Reglamento de desarrollo y apenas observamos algun cambio en las Administraciones ni tampoco la intención de acometerlo pese que, la Disposición Final 3ª concedió un aplazamiento para la adaptación a la citada Ley (hasta 31/12/09 y para las Comunidades Autónomas y Entidades Locales supeditado a sus disponibilidades presupuestarias). No obstante, habida cuenta que la implantación de la Administración Electrónica es un proyecto complejo y costoso, es por lo que nuevamente el legislador otorgó una tregua a las Comunidades Autónomas y Entidades Locales para aprobar y hacer público los programas y calendarios de trabajo con mención particularizada de las fases en las que los diversos derechos serán exigibles por los ciudadanos.

Para acabar la semana, tenemos una entrada de Sergio Galán, alias @NaxoneZ, que ya ha colaborado con Security Art Work en el pasado.

Pueden encontrarle en su blog naxonez.wordpress.com o seguirle en Twitter.

Últimamente se ha hablado mucho del robo de certificados. Como sabréis el uso de https y de su seguridad, en gran medida depende de que el certificado usado en la web haya sido generado por una entidad confiable y de que el acceso al mismo sea limitado, ya que si disponemos del certificado podremos hacer un phishing de la página web como si fuera real y el usuario ni lo notaría debido a que el certificado lo considera auténtico.

Un ejemplo de la obtención de un certificado de manera fraudulenta sería utilizando un fallo LFI de la página en cuestión. Veamos por ejemplo una página conh el siguiente código vulnerable a ataques LFIs:

<?php
require($_GET[file]);
?>

Para finalizar la semana traemos la segunda entrada de Cristina Martínez Garay, de la firma Rocabert & Grau Abogados, bufete que colabora con Security Art Work, y en este caso al respecto de la Ley 18/2011, de 5 de julio, reguladora del Uso de las Tecnologías de la Información y de la Comunicación en la Administración de Justicia.

Esperamos que les resulte interesante.

Hace apenas unos días, en la era de las Tecnologías de la Información y Comunicación, otra norma más se ha promulgado promoviendo el uso de las TIC´S, y esta vez le ha tocado a la Administración de Justicia, así como a todos los profesionales que trabajamos, ejercemos y lidiamos en la misma.

Siendo la Administración de Justicia independiente al poder Ejecutivo no estaba sujeta a la famosa, en la teoría, Ley 11/2007, de 22 de junio, de Acceso Electrónico de los Ciudadanos a los Servicios Públicos, en adelante LAESCP, por lo que era inevitable que se promulgara tarde o temprano una Ley especifica como ha sido la Ley 18/2011, de 5 de julio, reguladora del Uso de las Tecnologías de la Información y de la Comunicación en la Administración de Justicia.

Para hoy martes, tenemos una entrada de Sergio Galán, alias @NaxoneZ, que inicia su andadura como colaborador de este blog.

Pueden encontrarle en su blog naxonez.wordpress.com o seguirle en Twitter.

Cuando hablamos de monitorización el primer software que nos suele venir a la cabeza es Nagios. Según la Wikipedia y para quien no lo sepa, “Nagios es un sistema de monitorización de redes de código abierto ampliamente utilizado, que vigila los equipos (hardware) y servicios (software) que se especifiquen, alertando cuando el comportamiento de los mismos no es el deseado. Entre sus características principales figuran la monitorización de servicios de red (SMTP, POP3, HTTP, SNMP…), de los recursos de sistemas hardware (carga del procesador, uso de los discos, memoria, estado de los puertos…), independencia de sistemas operativos, posibilidad de monitorización remota mediante túneles SSL cifrados o SSH, y la posibilidad de programar pluggins específicos para nuevos sistemas.”

Como en todo software opensource, existe la versión enterprise, que en el caso de Nagios se denomina Nagios XI. En este post vamos a ver algunos fallos de seguridad que ya han sido notificados al equipo de desarrollo de esta herramienta y en la nueva release dejaran de estar, afortunadamente. Vamos a comenzar a buscar posibles puntos de fallo, para lo que usaremos la demo que podemos visitar en su sitio web: http://nagiosxi.demos.nagios.com/.

A diferencia de la versión Pro de Metasploit, una de las limitaciones a la hora de “pivotear” conexiones desde Meterpreter por medio de route es el tipo de herramientas que podemos usar a través del pívot. Esto es debido a que cualquier herramienta que use raw sockets no funcionará a través del túnel, estando limitados a conexiones TCP y UDP que realicen una “conexión completa” (connected sockets). En el caso de Nmap, por ejemplo, implica que únicamente podemos realizar escaneos de tipo TCP connect (-sT) por medio de socks4 y proxychains, pero será inútil utilizar switches como -sS (syn scan), -O (OS detection) o similares. Aunque otra opción es utilizar portforwarding (portfwd) mediante el cual mapear puertos locales con los de la víctima, estamos limitados a conexiones TCP, por lo que esto también reduce opciones a la hora de elegir herramientas que empleen UDP. En nuestro caso lo que haremos será preparar un entorno que nos ayude a “forwardear” peticiones DNS desde herramientas que hagan uso de UDP (nmap, dnsenum, etc) a través de Meterpreter.

Para ello configuraremos un Proxy DNS que intercepte peticiones DNS UDP y las redirija, en su “versión TCP”, al puerto configurado con portfwd. Ya que la mayoría de servidores DNS soportan TCP, no solamente para realizar transferencias de zona, sino para aceptar también queries en el puerto 53 (así lo especifica el protocolo DNS), podremos realizar consultas DNS con prácticamente cualquier herramienta. Lógicamente clientes DNS que empleen o soporten TCP (ej: dig +tcp) no requerirán de dicho Proxy y podrán lanzarse directamente a través de Meterpreter Lo mismo ocurre con clientes DNS que usen UDP y que utilizen la API adecuada, en cuyo caso podrá redirigir paquetes a través de Meterpreter utilizando route.

El pasado jueves 31 de Marzo, el Framework de ingeniería Social SET (Social Engineer Toolkit) lanzó su versión 1.3 “Artillery Edition” proporcionando características de gran interés. Entre las más destacables se encuentra el vector de ataque Wireless Attack Vector que hace uso de airbase-ng para crear un Fake AP y redirigir tráfico, o el payload RATTE (Remote Administration Tool Tommy Edition) desarrollado por Thomas Werth y que permite tunelizar instrucciones mediante HTTP aprovechándose de las configuraciones locales del navegador y saltándose de esta forma Firewalls y Proxys.

Además, una de las funcionalidades más interesantes ha sido la incorporación de una nueva shell interactiva (Custom Written Interactive Shell) desarrollada en python por David Kennedy (ReL1K) y que trabaja como una reverse shell usando AES 256. El payload ha sido añadido a SET e incorpora numerosas características como: command shell, uploading/downloading files, listing/killing processes, ssh tunneling, etc.

En este post hablaremos de esta última característica, Reverse Port SSH Tunneling, mediante un ejemplo práctico que refleja un escenario típico en el que necesitamos escalar privilegios y para ello necesitamos explotar un servicio al cual no tenemos acceso directo desde el exterior.