El panorama actual de la seguridad informática es bastante interesante puesto que cada vez vemos más información sobre este tema. Ataques, robos de credenciales, amenazas, suplantación de identidad… es evidente que en el “Internet de las cosas” toda protección es poca.
Muchos gremios profesionales se interesan, poco a poco eso sí, por formarse o al menos asistir a charlas y/o eventos de carácter no excesivamente técnico (como Hack&Beers) para iniciarse o aprender ciertas pautas a tomar para su empresa.
Antivirus o con suerte Firewalls, es lo que más podemos encontrar en todas las empresas. Otra cosa es encontrarse antivirus actualizados. Esta protección no está de más, como ya comentamos. Si todo está al día, y configurado correctamente, esta solución nos “protege” del exterior, bloquea malware, avisa de phishing, etcétera… Aunque a los más “arcaicos” les puede resultar una auténtica molestia el recibir bloqueos y/o avisos, esto puede salvarnos de una catástrofe de dimensiones casi mundiales en nuestro negocio.
¿Y qué pasa con la fuga de información?
Este aspecto (actualmente ignorado por la inmensa mayoría aunque si bien es cierto que determinados gremios están concienciándose bastante rápido) es muy interesante.
Existe el robo de información desde sedes físicas. Un individuo “A” llega a una empresa X, enchufa un USB Rubber Ducky, el famoso Pato, y “aspira” todo tipo de información y credenciales.
Otra forma, es que un empleado, o nuevo empleado o servicios externos en nuestra empresa de cualquier tipo (limpieza, servicio técnico, etcétera…) puede acceder a nuestras oficinas por confianza y pinchar un USB y extraer información confidencial.
Siendo más paranoicos, y no estoy exagerando, puesto que nos hemos encontrado ya varios casos de este tipo, un empleado utiliza un equipo de la empresa el cual no necesita introducir ni extraer información para compartir con compañeros ya que su trabajo no contempla esto, puesto que todo se hace mediante la intranet. ¿Por qué están activos los USB o grabadores DVD?
A continuación vamos a desgranar en este artículo primero y en otra segunda parte de “Controlando Dispositivos Externos“, soluciones válidas para contrarrestar fuga de datos.
En esta primera parte, trataremos con una reputadísima empresa de soluciones de Seguridad. Sophos.
Los EndPoints. Una medida más para evitar fuga de información.
Queramos o no, la inseguridad está en todos lados. Por ello vamos a exponer en este artículo, brevemente, el uso de el EndPoint SOPHOS como medida preventiva para evitar que fuga de información. Recordad, la información es negocio.
Nos vamos a centrar únicamente en su función de Control de Dispositivos.
Lo primero es irnos a su Web. Veremos algo similar a la siguiente captura.
Obviamente necesitaremos evaluar la versión para poder probarla durante 30 días. Suficiente para ver su efectividad.
Elegimos la instalación “en la nube”. ¿Por qué? Vamos a ver como gestionar varios equipos desde la nube, habilitando políticas, reglas, etcétera desde su sitio Web. Algo muy cómodo si se tienen muchos equipos.
Rellenamos los datos correspondientes, email real para activar el producto y pasamos a la siguiente fase. Debemos entrar en la URL de la captura para loguearnos con nuestro mail y password. Este es el panel de administración.
Es muy importante fijarse en todas las opciones que tiene puesto que son muy interesantes.
Este es el panel de administración. Nos ha gustado mucho que es muy “limpio” en su diseño, ofrece detalles estadísticos que pueden servirnos en el futuro para ver el uso del EndPoint, equipos no protegidos, etcétera…
Nos fijaremos en la sección de descargas puesto que tendremos los instalables para Windows, Linux, MAC…personalizados. Estos serán los que usaremos para “propagar” (instalar) en nuestros equipos y poder gestionar así, desde el cloud, todos.
En la anterior captura vemos el menú correspondiente a la sección descargas.
Cuando instalemos en algún equipo nuestro ejecutable descargado desde el mencionado menú de Descargas, y cuando el equipo esté conectado a Internet, detectará la conexión y aparecerá en nuestro panel de administración.
En el menú “Usuarios y Dispositivos” aparece el apartado “Políticas” (Policies) en el cual tenemos entre otras opciones “Defina cómo se debe tratar los medios extraíbles y otros periféricos”. En ella vamos a denegar el almacenamiento extraíble para evitar que nos instalen un USB Rubber Ducky o que algún empleado malhumorado trafique con información confidencial.
Igualmente podemos bloquear todo tipo de conexiones. Lo vemos en la siguiente captura.
Al final de la página, guardamos. Automáticamente tras pocos segundos se actualiza en el equipo cliente, esta política bloqueando cualquier tipo de medio extraíble.
En el equipo cliente, SOPHOS ENDPOINT, nos aparecerá como un software antivirus pero con muchísimos más complementos. Igualmente podemos gestionar algunas actividades.
Un opción muy interesante, es un módulo “anti desinstalaciones” llamado Protección contra manipulaciones que nos sirve para que el usuario no desinstale el software sino conoce la password de desinstalación, reflejada en el DashBoard en el que gestionamos, como hemos dicho, nuestro endpoint.
Con ello, sumamos un punto más de control y seguridad a nuestros equipos. No por ataques, que también incorpora antivirus (como hemos hablado) sino que evita extracción de información. Si un usuario quisiera en un momento determinado introducir algún documento via pendrive, o extraer lo tendría que solicitar y quedaría registrado en nuestro Sophos Cliente y en el panel de administración.
Espero que os sirva de referencia para adoptar medidas. Invertir en seguridad no es derrochar el dinero, es ahorrar en incidencias.
Algunos activistas están motivados por la política o la religión, mientras que otros pueden querer denunciar los abusos, o la venganza, o simplemente acosar a su objetivo para su propio entretenimiento.
Vistas de página en total
Mostrando entradas con la etiqueta Software. Mostrar todas las entradas
Mostrando entradas con la etiqueta Software. Mostrar todas las entradas
miércoles, 17 de febrero de 2016
Honeypot. Un tarro de miel para los atacantes.
En el artículo de hoy trataremos el tema de los Honeypots. Este tema es bastante desconocido para mucha gente, ya que es un concepto bastante contradictorio.
Honeypot significa en inglés, “tarro de miel”. Es una herramienta que se usa casi exclusivamente en el campo de la seguridad informática. Su función se basa en atraer y analizar ataques realizados por bots o hackers. Y podremos decir: ¿Atraer? ¿Pero el quid de la cuestión no es repeler?. Pues bien, su objetivo es atraer atacantes para ver sus pautas de ataque, generar diccionarios para recopilar que palabras usan en ataques (para no usarlas en tu sistema), conocer al enemigo y su perfil.
Bueno, ¿y cómo es un honeypot?. Un honeypot puede ser tan sumamente sencillo como un equipo informático cualesquiera que analice el tráfico entrante y saliente hacia Internet. Pero es importante “habilitar” o no sanear alguna vulnerabilidad del S.O, en algún protocolo, programa o cualquier otro elemento para así atraer más fácilmente a un atacante o atacantes.
Pero por otra parte, un honeypot puede ser bastante complejo. Puede funcionar como una red de ordenadores, funcionando con diversos sistemas, y con infinidad de servicios. Con esto, cuando uno de los equipos es atacado inmediatamente es informado el administrador de sistemas.
Una de las opciones más utilizadas es usar un honeypot en forma de programa. Hay honeypots que simulan ser una red local de múltiples equipos, ips falsas, directorios inventados, equipos no presentes, etc… para crear gran confusión al atacante y/o para detectar nuevos métodos de ataque y poder aplicar defensas a nuestra red real.
También pueden guardar usuario y contraseña que el atacante introduce, bien manualmente, o por medio de diccionarios para así poder excluir todos esos caracteres alfanuméricos o no de contraseñas en nuestra red real.
A continuación os mostramos un esquema de un honeypot en una red local:
Podemos decir, que un honeypot es un gran aliado para defender tu red, aunque el concepto sea atraer ataques, la mejor táctica para defenderse es saber como actúa el enemigo y que mejor que ponerle un cebo el cual no supondrá un riesgo para nuestra red, y nos ayudará a saber como incide el ataque y de que manera.
Los honeypots más conocidos son: honeyd, kippo(ssh), Valhalla, Specter, honeynet…
Unos son mas fáciles de usar, otros más complejos, pero altamente configurables, aunque la forma más fácil de saber cuál va a cubrir nuestras necesidades será probándolos.
Honeypot significa en inglés, “tarro de miel”. Es una herramienta que se usa casi exclusivamente en el campo de la seguridad informática. Su función se basa en atraer y analizar ataques realizados por bots o hackers. Y podremos decir: ¿Atraer? ¿Pero el quid de la cuestión no es repeler?. Pues bien, su objetivo es atraer atacantes para ver sus pautas de ataque, generar diccionarios para recopilar que palabras usan en ataques (para no usarlas en tu sistema), conocer al enemigo y su perfil.
Bueno, ¿y cómo es un honeypot?. Un honeypot puede ser tan sumamente sencillo como un equipo informático cualesquiera que analice el tráfico entrante y saliente hacia Internet. Pero es importante “habilitar” o no sanear alguna vulnerabilidad del S.O, en algún protocolo, programa o cualquier otro elemento para así atraer más fácilmente a un atacante o atacantes.
Pero por otra parte, un honeypot puede ser bastante complejo. Puede funcionar como una red de ordenadores, funcionando con diversos sistemas, y con infinidad de servicios. Con esto, cuando uno de los equipos es atacado inmediatamente es informado el administrador de sistemas.
Una de las opciones más utilizadas es usar un honeypot en forma de programa. Hay honeypots que simulan ser una red local de múltiples equipos, ips falsas, directorios inventados, equipos no presentes, etc… para crear gran confusión al atacante y/o para detectar nuevos métodos de ataque y poder aplicar defensas a nuestra red real.
También pueden guardar usuario y contraseña que el atacante introduce, bien manualmente, o por medio de diccionarios para así poder excluir todos esos caracteres alfanuméricos o no de contraseñas en nuestra red real.
A continuación os mostramos un esquema de un honeypot en una red local:
Podemos decir, que un honeypot es un gran aliado para defender tu red, aunque el concepto sea atraer ataques, la mejor táctica para defenderse es saber como actúa el enemigo y que mejor que ponerle un cebo el cual no supondrá un riesgo para nuestra red, y nos ayudará a saber como incide el ataque y de que manera.
Los honeypots más conocidos son: honeyd, kippo(ssh), Valhalla, Specter, honeynet…
Unos son mas fáciles de usar, otros más complejos, pero altamente configurables, aunque la forma más fácil de saber cuál va a cubrir nuestras necesidades será probándolos.
Etiquetas:
ataques,
escenarios,
General,
hackers trampa,
honeypot,
Pentesting,
Phishing,
Privacidad,
Redes,
seguridad informatica,
Software,
tarrodemiel,
trampas
Protege el acceso a tu servidor con TCP Wrapper
TCP Wrapper es un sistema que nos permite permitir, denegar o filtrar el acceso a los servicios de un servidor con sistema operativo UNIX (como por ejemplo Linux o BSD).
Con este artículo aprenderás cómo funciona y aprenderás a configurar los TCP Wrappers en tu servidor.
Los ficheros principales implicados en TCP Wrappers son “/etc/host.allow” y “/etc/host.deny”. En el fichero /etc/host.allow se indican las políticas permisivas y en el fichero /etc/host.deny las políticas restrictivas.
Las políticas o reglas para filtrar el acceso al servidor desde la red se definen de la siguiente forma:
Demonios o lista de demonios del sistema : Lista de equipos : Acción a realizar
A continuación detallamos cada campo:
– Demonios: Son servicios que existen en sistemas operativos Unix como por ejemplo sshd (servicio SSH), slapd (servicio LDAP) o proftpd (servicio FTP). Para crear una regla común para varios demonios debemos indicar su nombre separados por comas. Existe también el comodín “ALL” que hace que dicha política afecte a todos los demonios del sistema.
– Lista de equipos: En este campo indicamos a que equipos aplicamos esta política. Podemos indicar una dirección IP, un rango de direcciones IP, o un nombre de dominio. También podremos usar el comodín “ALL” para que esta política afecte a todos los equipos que intenten acceder. También existe el operador “EXCEPT” que nos permite eliminar de la regla uno o varios equipos.
– Acción a realizar: Aquí debemos indicar si la política permite el acceso o deniega el acceso a los demonios indicados anteriormente. Las palabras que se usa denegar el acceso es “deny”. En caso de dejar este campo vacío, significa que permitimos el acceso a los demonios y equipos indicados. Opcionalmente, podemos enviar comandos con la directiva “spawn”. Esta directiva suele ser utilizada para la creación de registros de conexión al propio equipo. Existe también la directiva “twist” que sustituye el servicio o demonio solicitado por el comando que le hemos especificado. Esto significa que por defecto se deniega el acceso. Esto es muy útil para la creación de honeypots.
Ejemplo de uso de TCP Wrapper
Ahora pondremos en práctica todo lo que hemos explicado anteriormente.
Como primer ejemplo vamos a denegar el acceso a un servidor SSH instalado en el equipo solo a una determinada IP. Al ser una política permisiva (permite el acceso a todos los equipos excepto a la IP que se le indica) la vamos a definir utilizando el fichero /etc/host.allow .
Escribiremos lo siguiente para aplicar esta política:
sshd —> Deminio del servicio SSH
192.168.5.135—> Ip a la que vamos a aplicar la política
deny —> Denegamos el acceso
Comprobamos que desde el equipo con la IP 192.168.5.135 no se puede acceder al servicio SSH:
A continuación vamos a denegar el acceso al servicio SSH a todos los equipos. Además, gracias a la directiva “spawn” vamos a guardar un registro del intento de conexión a nuestro servidor. Con %d imprimimos el demonio que denegamos y %h el equipo que se intenta conectar.
Una vez que un equipo se intenta conectar a la máquina en la que tenemos la política anterior configurada, se crea una linea en el fichero que hemos indicado con el demonio al que hemos denegado el acceso y la IP desde donde se intentaba conectar.
Con este artículo aprenderás cómo funciona y aprenderás a configurar los TCP Wrappers en tu servidor.
Los ficheros principales implicados en TCP Wrappers son “/etc/host.allow” y “/etc/host.deny”. En el fichero /etc/host.allow se indican las políticas permisivas y en el fichero /etc/host.deny las políticas restrictivas.
Las políticas o reglas para filtrar el acceso al servidor desde la red se definen de la siguiente forma:
Demonios o lista de demonios del sistema : Lista de equipos : Acción a realizar
A continuación detallamos cada campo:
– Demonios: Son servicios que existen en sistemas operativos Unix como por ejemplo sshd (servicio SSH), slapd (servicio LDAP) o proftpd (servicio FTP). Para crear una regla común para varios demonios debemos indicar su nombre separados por comas. Existe también el comodín “ALL” que hace que dicha política afecte a todos los demonios del sistema.
– Lista de equipos: En este campo indicamos a que equipos aplicamos esta política. Podemos indicar una dirección IP, un rango de direcciones IP, o un nombre de dominio. También podremos usar el comodín “ALL” para que esta política afecte a todos los equipos que intenten acceder. También existe el operador “EXCEPT” que nos permite eliminar de la regla uno o varios equipos.
– Acción a realizar: Aquí debemos indicar si la política permite el acceso o deniega el acceso a los demonios indicados anteriormente. Las palabras que se usa denegar el acceso es “deny”. En caso de dejar este campo vacío, significa que permitimos el acceso a los demonios y equipos indicados. Opcionalmente, podemos enviar comandos con la directiva “spawn”. Esta directiva suele ser utilizada para la creación de registros de conexión al propio equipo. Existe también la directiva “twist” que sustituye el servicio o demonio solicitado por el comando que le hemos especificado. Esto significa que por defecto se deniega el acceso. Esto es muy útil para la creación de honeypots.
Ejemplo de uso de TCP Wrapper
Ahora pondremos en práctica todo lo que hemos explicado anteriormente.
Como primer ejemplo vamos a denegar el acceso a un servidor SSH instalado en el equipo solo a una determinada IP. Al ser una política permisiva (permite el acceso a todos los equipos excepto a la IP que se le indica) la vamos a definir utilizando el fichero /etc/host.allow .
Escribiremos lo siguiente para aplicar esta política:
sshd —> Deminio del servicio SSH
192.168.5.135—> Ip a la que vamos a aplicar la política
deny —> Denegamos el acceso
Comprobamos que desde el equipo con la IP 192.168.5.135 no se puede acceder al servicio SSH:
A continuación vamos a denegar el acceso al servicio SSH a todos los equipos. Además, gracias a la directiva “spawn” vamos a guardar un registro del intento de conexión a nuestro servidor. Con %d imprimimos el demonio que denegamos y %h el equipo que se intenta conectar.
Una vez que un equipo se intenta conectar a la máquina en la que tenemos la política anterior configurada, se crea una linea en el fichero que hemos indicado con el demonio al que hemos denegado el acceso y la IP desde donde se intentaba conectar.
Creando un túnel SSH con Nessus
Muchas veces a la hora de hacer una auditoría externa y tener algún sistema de protección exterior (Firewall, IDS…), se nos habilitan diferentes mecanismos para poder acceder dentro de la red que queremos auditar sin que su seguridad exterior se vea comprometida. Es muy común habilitar un túnel SSH para acceder al interior de la red local.
Hoy vamos a ver cómo aprovechar ese túnel para correr Nessus como si estuviéramos ubicados dentro de la red. Como sabéis, la versión gratuita de Nessus tan sólo nos permite escaneos a direcciones IP locales, sin embargo mediante el túnel vamos a conseguir utilizar esta herramienta frente a una IP pública, como si estuviéramos dentro de la red a auditar aún estando fuera de la misma.
Vamos a utilizar para ello un túnel SSH y la herramienta Proxychains de la cual tenéis un artículo en el blog sobre cómo trabajar con ella y Tor.
En el siguiente diagrama vemos el entorno en el cual vamos a trabajar:
La idea es crear un túnel SSH y haciendo uso de Proxychains reenviaremos todas las peticiones de nuestro PC (Nodo A) a través del túnel, de tal forma que Nessus va a pensar que está corriendo el scanner en la máquina intermedia (Nodo B) que sí está en la misma red del servidor a auditar (Nodo C). Los pasos a seguir son los siguientes:
Creación del túnel SSH con el nodo B.
Para crear el túnel previamente tenemos que tener habilitado en el nodo B el servicio SSH con nuestro usuario correspondiente y una regla en el Firewall que permita las peticiones desde exterior hacia la máquina B (natearemos el puerto 22 mediante Port Fowarding a la máquina B).
Con todo preparado pondremos a la escucha un puerto en la máquina local A, de tal forma que todo lo que se envíe a ese puerto se reenviará a través del túnel que crearemos contra la máquina B. Usaremos el siguiente comando:
sudo ssh –p 22 –N –D 8081 user@direccionIP_B
Tras introducir las credenciales oportunas podemos ver desde otra terminal como ya tenemos el puerto 8081 a la escucha en la máquina local A:
Instalación y configuración de Proxychains.
Para la instalacción de Proxychains simplemente ponemos:
sudo apt-get install proxychains
y nos vamos a editar su fichero de configuración /etc/proxychains.conf. Pondremos que todas las peticiones de los programas/servicios abiertos con Proxychains vayan al puerto 8081 de autobucle (127.0.0.1) donde está el túnel.
Comprobación del funcionamiento del túnel.
Pasamos ahora a comprobar si funciona nuestro túnel, para ello vamos a solicitar desde nuestra máquina local A la IP pública que tenemos. Vemos como aparece nuestra IP 95.x.x.x.
Sin embargo cuando pasamos la petición a través del túnel mediante proxychains vemos que nos da la IP del nodo B, por tanto nuestro túnel funciona correctamente.
Hoy vamos a ver cómo aprovechar ese túnel para correr Nessus como si estuviéramos ubicados dentro de la red. Como sabéis, la versión gratuita de Nessus tan sólo nos permite escaneos a direcciones IP locales, sin embargo mediante el túnel vamos a conseguir utilizar esta herramienta frente a una IP pública, como si estuviéramos dentro de la red a auditar aún estando fuera de la misma.
Vamos a utilizar para ello un túnel SSH y la herramienta Proxychains de la cual tenéis un artículo en el blog sobre cómo trabajar con ella y Tor.
En el siguiente diagrama vemos el entorno en el cual vamos a trabajar:
La idea es crear un túnel SSH y haciendo uso de Proxychains reenviaremos todas las peticiones de nuestro PC (Nodo A) a través del túnel, de tal forma que Nessus va a pensar que está corriendo el scanner en la máquina intermedia (Nodo B) que sí está en la misma red del servidor a auditar (Nodo C). Los pasos a seguir son los siguientes:
Creación del túnel SSH con el nodo B.
Para crear el túnel previamente tenemos que tener habilitado en el nodo B el servicio SSH con nuestro usuario correspondiente y una regla en el Firewall que permita las peticiones desde exterior hacia la máquina B (natearemos el puerto 22 mediante Port Fowarding a la máquina B).
Con todo preparado pondremos a la escucha un puerto en la máquina local A, de tal forma que todo lo que se envíe a ese puerto se reenviará a través del túnel que crearemos contra la máquina B. Usaremos el siguiente comando:
sudo ssh –p 22 –N –D 8081 user@direccionIP_B
Tras introducir las credenciales oportunas podemos ver desde otra terminal como ya tenemos el puerto 8081 a la escucha en la máquina local A:
Instalación y configuración de Proxychains.
Para la instalacción de Proxychains simplemente ponemos:
sudo apt-get install proxychains
y nos vamos a editar su fichero de configuración /etc/proxychains.conf. Pondremos que todas las peticiones de los programas/servicios abiertos con Proxychains vayan al puerto 8081 de autobucle (127.0.0.1) donde está el túnel.
Comprobación del funcionamiento del túnel.
Pasamos ahora a comprobar si funciona nuestro túnel, para ello vamos a solicitar desde nuestra máquina local A la IP pública que tenemos. Vemos como aparece nuestra IP 95.x.x.x.
Sin embargo cuando pasamos la petición a través del túnel mediante proxychains vemos que nos da la IP del nodo B, por tanto nuestro túnel funciona correctamente.
Iniciando Nessus a través del túnel.
Una vez que tenemos todo funcionando vamos a lanzar Nessus de nuevo pero esta vez a través del túnel. Primero paramos el servicio de Nessus:
/etc/init.d/nessus stop
y lo iniciamos a través de proxychains para que las peticiones vayan a través del túnel.
Una vez que tenemos todo funcionando vamos a lanzar Nessus de nuevo pero esta vez a través del túnel. Primero paramos el servicio de Nessus:
/etc/init.d/nessus stop
y lo iniciamos a través de proxychains para que las peticiones vayan a través del túnel.
Una vez que tenemos todo funcionando ya podemos arrancar Nessus y llevar a cabo el escaneo de la máquina C en cuestión, sin necesidad de desplazarnos a la ubicación del nodo
Dejar claro que todas las pruebas se han llevado a cabo sobre dos redes propietarias y que como comentábamos en la nota legal, se hace con fines educativos.
Iniciando Nessus a través del túnel.
Una vez que tenemos todo funcionando
vamos a lanzar Nessus de nuevo pero esta vez a través del túnel. Primero
paramos el servicio de Nessus:
/etc/init.d/nessus stop
y lo iniciamos a través de proxychains para que las peticiones vayan a través del túnel.
- See more at: http://hacking-etico.com/2015/06/12/creando-un-tunel-ssh-con-nessus/#more-4509
Etiquetas:
firewall,
firewalls,
ids,
nessus,
openssh,
Pentesting,
proxychains,
Redes,
Sin categoría,
Software,
ssh,
túnel,
Tutorial,
Vulnerabilidades
martes, 16 de febrero de 2016
Cuando el pato teclea Cuack Cuack – Parte 2
Seguimos con la trilogía de pato. Ya vimos en la parte 1 qué era el pato (USB Rubber Ducky) y cómo protegernos, en este caso vamos a ver algunos ejemplos del pato en diferentes sistemas operativos, por lo que va a comenzar a hacer Cuack
Lo primero que necesitamos para poderlo usar es aprender su lenguaje de programación el cual veréis que es muy sencillo. Aquí realizaremos el Hola Mundo en Windows, Mac, Linux y Android. Lo que vamos a hacer es abrir un editor de texto y escribir la conocida frase con la que empezamos a programar todo el mundo. Primero veremos el código y cómo afecta, luego veremos las herramientas para compilarlo.
Comenzamos con nuestro amigo Windows de Bill Puertas.
?
1
2
3
4
5
6
7
8
DELAY 3000
GUI r
DELAY 200
STRING notepad
ENTER
DELAY 200
STRING Hola mundo!!!
ENTER
Comenzamos introduciendo el comando DELAY -dicho comando mide el tiempo en milisegundos- que nos hará esperar 3 segundos para que le dé tiempo a Windows a reconocer el “teclado”. A continuación, con GUI r lanzamos el ejecutar, GUI emula la tecla de Windows, Super-Key o Command según el sistema operativo, al combinarlo con la tecla r y se nos abrirá la ventana de ejecutar de Windows.
Volvemos a esperar 200 milisegundos para dar tiempo a Windows a abrirnos la pantalla y tecleamos, con el comandos STRING, notepad. Después presionamos ENTER.
n
Lo primero que necesitamos para poderlo usar es aprender su lenguaje de programación el cual veréis que es muy sencillo. Aquí realizaremos el Hola Mundo en Windows, Mac, Linux y Android. Lo que vamos a hacer es abrir un editor de texto y escribir la conocida frase con la que empezamos a programar todo el mundo. Primero veremos el código y cómo afecta, luego veremos las herramientas para compilarlo.
Comenzamos con nuestro amigo Windows de Bill Puertas.
?
1
2
3
4
5
6
7
8
DELAY 3000
GUI r
DELAY 200
STRING notepad
ENTER
DELAY 200
STRING Hola mundo!!!
ENTER
Comenzamos introduciendo el comando DELAY -dicho comando mide el tiempo en milisegundos- que nos hará esperar 3 segundos para que le dé tiempo a Windows a reconocer el “teclado”. A continuación, con GUI r lanzamos el ejecutar, GUI emula la tecla de Windows, Super-Key o Command según el sistema operativo, al combinarlo con la tecla r y se nos abrirá la ventana de ejecutar de Windows.
Volvemos a esperar 200 milisegundos para dar tiempo a Windows a abrirnos la pantalla y tecleamos, con el comandos STRING, notepad. Después presionamos ENTER.
n
Una vez dominado Windows seguimos con la versión para Mac OS X de Jobs que veréis que es muy similar.
DELAY 3000
GUI SPACE
STRING TextEdit
ENTER
DELAY 2000
GUI n
DELAY 750
STRING Hola Mundo!!
ENTER
Como observamos en el segundo caso, los comandos son similares a Windows la diferencia es que en lugar de usar GUI r usamos GUI SPACE que nos abre el lanzador de aplicaciones.
DELAY 3000
GUI SPACE
STRING TextEdit
ENTER
DELAY 2000
GUI n
DELAY 750
STRING Hola Mundo!!
ENTER
Como observamos en el segundo caso, los comandos son similares a Windows la diferencia es que en lugar de usar GUI r usamos GUI SPACE que nos abre el lanzador de aplicaciones.
Abrimos el TextEdit, en el caso de MAC, tenemos que decirle que queremos uno nuevo fichero de texto antes de ponernos a escribir en él, por lo que ejecutamos GUI n.
Ahora ya solo nos queda escribir el hola mundo con STRING Hola Mundo!!
como
ya hicimos en Windows. - See more at:
http://hacking-etico.com/2015/05/16/cuando-el-pato-teclea-cuack-cuack-parte-2/#sthash.ho96N1g1.dpuf
como
ya hicimos en Windows. - See more at:
http://hacking-etico.com/2015/05/16/cuando-el-pato-teclea-cuack-cuack-parte-2/#sthash.ho96N1g1.dpuf
Ahora ya solo nos queda escribir el hola mundo con STRING Hola Mundo!! 😀 como ya hicimos en Windows.
Seguimos con el tercer caso. En este momento vamos con GNU/Linux del tito Richard y Linus en su versión Ubuntu + Gnome3.
DELAY 3000
ALT F2
DELAY 500
STRING gedit
DELAY 500
ENTER
DELAY 750
STRING Hola Mundo!!
Como podéis ver, aquí difiere un poco el código, ya que no usamos GUI sino ALT F2 porque es como se abre el lanzador de aplicaciones en Gnome3, pero el resto es igual que en los anteriores sistemas.
DELAY 3000
ALT F2
DELAY 500
STRING gedit
DELAY 500
ENTER
DELAY 750
STRING Hola Mundo!!
Como podéis ver, aquí difiere un poco el código, ya que no usamos GUI sino ALT F2 porque es como se abre el lanzador de aplicaciones en Gnome3, pero el resto es igual que en los anteriores sistemas.
Ahora introducimos una vez más el editor de texto con el comando STRING gedit y lo ejecutamos.
Ya tenemos listo nuestro gedit para escribir nuestra famosa frase Hola Mundo.
Vamos con nuestro cuarto y ultimo caso ¿Sueñan los androides con ovejas eléctricas?
Pues si no lo hacen nosotros vamos a hacer que lo hagan 😉
Vamos a usar inkpad en Android, dado que lo tenia instalado en mi móvil de pruebas y así no busco otro editor de texto simple.
DELAY 3100
ESCAPE
ESCAPE
ESCAPE
ESCAPE
ESCAPE
ESCAPE
CTRL z
DELAY 1200
STRING inkpad
DELAY 1000
DOWN
DOWN
DOWN
DOWN
ENTER
DELAY 2000
ENTER
DELAY 200
STRING Hola mundo!
Pues si no lo hacen nosotros vamos a hacer que lo hagan 😉
Vamos a usar inkpad en Android, dado que lo tenia instalado en mi móvil de pruebas y así no busco otro editor de texto simple.
DELAY 3100
ESCAPE
ESCAPE
ESCAPE
ESCAPE
ESCAPE
ESCAPE
CTRL z
DELAY 1200
STRING inkpad
DELAY 1000
DOWN
DOWN
DOWN
DOWN
ENTER
DELAY 2000
ENTER
DELAY 200
STRING Hola mundo!
Como observamos en este último caso usamos algunos comandos más. El primero es ESCAPE que nos sirve para volver hacia detrás y salir si tenemos alguna aplicación ejecutándose en ese momento.
Una vez en el escritorio usamos CTRL z que nos permitirá usar el buscador de Android donde tecleamos el nombre del programa inkpad, le damos un segundo para que busque y bajamos cuatro posiciones con DOWN hasta la aplicación y presionamos ENTER.
Una vez en el escritorio usamos CTRL z que nos permitirá usar el buscador de Android donde tecleamos el nombre del programa inkpad, le damos un segundo para que busque y bajamos cuatro posiciones con DOWN hasta la aplicación y presionamos ENTER.
Esperamos 2 segundos para que se abra la aplicación y pulsamos ENTER de nuevo y ya escribimos nuestra frase Hola mundo!
FIN
Esperamos
2 segundos para que se abra la aplicación y pulsamos ENTER de nuevo y
ya escribimos nuestra frase Hola mundo! - See more at:
http://hacking-etico.com/2015/05/16/cuando-el-pato-teclea-cuack-cuack-parte-2/#sthash.ho96N1g1.dpuf
Esperamos
200 milisegundos y tecleamos Hola Mundo!! que aparecerá escrito gracias
al comando STRING - See more at:
http://hacking-etico.com/2015/05/16/cuando-el-pato-teclea-cuack-cuack-parte-2/#sthash.ho96N1g1.dpuf
Cuando el pato teclea Cuack Cuack – Parte 1
el USB Rubber Ducky, vamos a ver una pequeña introducción y quien sabe que más
Para él que no sepa que es nuestro patito de goma, es un USB que utiliza el estándar HID (Human Interface Device) por lo que Windows, OS X, Linux y Android lo detectarán como un teclado, por lo que hacemos al final con este USB es teclear comandos como si lo estuviera realizando un usuario y hace que los antivirus no lo detecten.
Tiene un lenguaje de programación muy sencillo que nos permite automatizar nuestros propios payloads pudiendo realizar diferentes tareas como:
Recoger información del sistema operativo
Sustraer información importante de los navegadores
Robar cookies de sesiones abiertas
Obligar a la víctima a conectarse a una WiFi que queramos y ya tenemos un MITM.
Mandar la información por correo electrónico
Esto es solo una pequeña muestra de lo que podéis hacer, ahora, el resto depende de vuestra imaginación.
Ahora viene la siguiente pregunta.
¿Nos podemos proteger?
La gente piensa que desactivando el autoplay de los USB se soluciona el problema, pero no es así dado que este USB trabaja como HID, por lo que no le afecta, dado que el autoplay solo es para los USB de almacenamiento.
Tenemos varias opciones para evitar este tipo de ataques, la primera y más radical es apagar los USBs desde la BIOS, de esta manera no funcionará ninguno y no hay posibilidades de ataque.
También podemos usar la aplicación USBDeview, que nos muestra a tiempo real toda la información de los dispositivos USB que se conectan, detectando de esta manera la conexión del “pato”.
Recordar bloquear la sesión cuando nos levantemos del ordenador para evitar que el pato pueda tener éxito, debido que lo que se suele hacer es usar los terminales de los sistemas para realizar las acciones.
Si somos de los que nos olvidamos de bloquear el ordenador al levantarnos de él, también tenemos shielducky de Alex Torrescrack que con presionar un botón ya quedaríamos protegidos y dejaremos de hacer Cuack.
sí que ya sabéis, también hay que tener cuidado con la seguridad física y nuestros puertos USB no sea que nos pinchen un pato de goma y nos roben la cartera.
Como me gusta esto de ir haciendo las cosas por fascículos para que no se hagan muy largos los post y así dejar las cosas en el aire y la intriga… en el siguiente montaremos nuestro primer programa.
Para él que no sepa que es nuestro patito de goma, es un USB que utiliza el estándar HID (Human Interface Device) por lo que Windows, OS X, Linux y Android lo detectarán como un teclado, por lo que hacemos al final con este USB es teclear comandos como si lo estuviera realizando un usuario y hace que los antivirus no lo detecten.
Tiene un lenguaje de programación muy sencillo que nos permite automatizar nuestros propios payloads pudiendo realizar diferentes tareas como:
Recoger información del sistema operativo
Sustraer información importante de los navegadores
Robar cookies de sesiones abiertas
Obligar a la víctima a conectarse a una WiFi que queramos y ya tenemos un MITM.
Mandar la información por correo electrónico
Esto es solo una pequeña muestra de lo que podéis hacer, ahora, el resto depende de vuestra imaginación.
Ahora viene la siguiente pregunta.
¿Nos podemos proteger?
La gente piensa que desactivando el autoplay de los USB se soluciona el problema, pero no es así dado que este USB trabaja como HID, por lo que no le afecta, dado que el autoplay solo es para los USB de almacenamiento.
Tenemos varias opciones para evitar este tipo de ataques, la primera y más radical es apagar los USBs desde la BIOS, de esta manera no funcionará ninguno y no hay posibilidades de ataque.
También podemos usar la aplicación USBDeview, que nos muestra a tiempo real toda la información de los dispositivos USB que se conectan, detectando de esta manera la conexión del “pato”.
Recordar bloquear la sesión cuando nos levantemos del ordenador para evitar que el pato pueda tener éxito, debido que lo que se suele hacer es usar los terminales de los sistemas para realizar las acciones.
Si somos de los que nos olvidamos de bloquear el ordenador al levantarnos de él, también tenemos shielducky de Alex Torrescrack que con presionar un botón ya quedaríamos protegidos y dejaremos de hacer Cuack.
sí que ya sabéis, también hay que tener cuidado con la seguridad física y nuestros puertos USB no sea que nos pinchen un pato de goma y nos roben la cartera.
Como me gusta esto de ir haciendo las cosas por fascículos para que no se hagan muy largos los post y así dejar las cosas en el aire y la intriga… en el siguiente montaremos nuestro primer programa.
Explotando vulnerabilidad en Java 7 – PoC
A estas alturas creo que todo el mundo está ya al tanto acerca de la vulnerabilidad en Java 7, y de la cual Oracle aún no ha publicado una actualización de seguridad. Ayer mismo anunciábamos en este blog la criticidad de esta vulnerabilidad y de la gravedad de la misma.
La gravedad se acentúa cuando ya se ha publicado un exploit capaz de aprovecharse de esta vulnerabilidad y explotándola, permitiendo al atacante ejecutar código remoto en la máquina vulnerada.
Explotando vulnerabilidad en Java 7 – PoC
odo esto, y gracias a que en Metasploit ya tenemos disponible el exploit, me he decidido a hacer una PoC (Proof of Concepto, prueba de concepto) para comprobar realmente la criticidad de facilidad de explotación de la nombrada vulnerabilidad.
Para empezar, decir que he actualizado Metasploit hoy mismo para tener todos los módulos actualizados. También he vuelto a instalar y habilitar Java 7 en un Internet Explorer para realizar las pruebas, ya que lo tenía deshabilitado desde que salió la noticia de la vulnerabilidad.
Una vez actualizado MSF buscamos el exploit, en este caso podemos observar que es bastante reciente, data de ayer y su ranking es excelente. Perfecto!
Vamos a usar este exploit, ejecutamos los comandos necesarios y observamos que por defecto no hay que modificar ninguna opción del exploit.
Para el payload vamos a usar uno del tipo meterpreter:
Como se observa en la imagen, sólo hay que especificar la opción LHOST que hace referencia a la IP de nuestro equipo, el equipo atacante. Sólo falta lanzar el exploit y esperar que la víctima se conecte:
Copiamos la URL y la vamos a escribir en el navegador de la máquina víctima, en este caso con un Internet Explorer:
En esta caso mi antivirus Avira ha detectado el exploit, bueno ya que Oracle no lo ha solucionado, parece que las firmas AV sí lo detectan. Una vez más, la importancia de mantener actualizado nuestro antivirus. ¿Y si deshabilito el antivirus?
Bingo! Ya tenemos sesión Meterpreter, ya podemos “trastear” en la máquina víctima. Poder ver información del sistema u obtener una shell para acceder a su línea de comandos.
La gravedad se acentúa cuando ya se ha publicado un exploit capaz de aprovecharse de esta vulnerabilidad y explotándola, permitiendo al atacante ejecutar código remoto en la máquina vulnerada.
Explotando vulnerabilidad en Java 7 – PoC
odo esto, y gracias a que en Metasploit ya tenemos disponible el exploit, me he decidido a hacer una PoC (Proof of Concepto, prueba de concepto) para comprobar realmente la criticidad de facilidad de explotación de la nombrada vulnerabilidad.
Para empezar, decir que he actualizado Metasploit hoy mismo para tener todos los módulos actualizados. También he vuelto a instalar y habilitar Java 7 en un Internet Explorer para realizar las pruebas, ya que lo tenía deshabilitado desde que salió la noticia de la vulnerabilidad.
Una vez actualizado MSF buscamos el exploit, en este caso podemos observar que es bastante reciente, data de ayer y su ranking es excelente. Perfecto!
Vamos a usar este exploit, ejecutamos los comandos necesarios y observamos que por defecto no hay que modificar ninguna opción del exploit.
Para el payload vamos a usar uno del tipo meterpreter:
Como se observa en la imagen, sólo hay que especificar la opción LHOST que hace referencia a la IP de nuestro equipo, el equipo atacante. Sólo falta lanzar el exploit y esperar que la víctima se conecte:
Copiamos la URL y la vamos a escribir en el navegador de la máquina víctima, en este caso con un Internet Explorer:
En esta caso mi antivirus Avira ha detectado el exploit, bueno ya que Oracle no lo ha solucionado, parece que las firmas AV sí lo detectan. Una vez más, la importancia de mantener actualizado nuestro antivirus. ¿Y si deshabilito el antivirus?
Bingo! Ya tenemos sesión Meterpreter, ya podemos “trastear” en la máquina víctima. Poder ver información del sistema u obtener una shell para acceder a su línea de comandos.
Resumiendo, en primer lugar se aconseja deshabilitar Java, también mantened actualizados vuestros antivirus y comprobar que funcionan correctamente, como habéis podido comprobar, mi última actualización de la base de firmas de Avira (hoy) me lo ha detectado.
Resumiendo,
en primer lugar se aconseja deshabilitar Java, también mantened
actualizados vuestros antivirus y comprobar que funcionan correctamente,
como habéis podido comprobar, mi última actualización de la base de
firmas de Avira (hoy) me lo ha detectado. - See more at:
http://hacking-etico.com/2013/01/12/explotando-vulnerabilidad-en-java-7-poc/#more-1393
Resumiendo,
en primer lugar se aconseja deshabilitar Java, también mantened
actualizados vuestros antivirus y comprobar que funcionan correctamente,
como habéis podido comprobar, mi última actualización de la base de
firmas de Avira (hoy) me lo ha detectado. - See more at:
http://hacking-etico.com/2013/01/12/explotando-vulnerabilidad-en-java-7-poc/#more-1393
Suscribirse a:
Entradas (Atom)
















,









.







,