26 may. 2016

Curso en línea de Desarrollo Seguro en Node.Js orientado a prevenir OWASP Top 10

Junto al MUG (Microsoft User Group) tendremos el placer de realizar un nuevo curso teórico práctico orientado a conocer las vulnerabilidades consideradas críticas por OWASP y sobre el lengujae de programación Node.js
En el curso se analizará como explotar y solucionar las vulnerabilidades del OWASP Top 10 desde el inicio del proyecto hasta la implementación de las aplicaciones. Todas las prácticas se realizarán en Node.js de forma tal de conocer cómo se explotan estas vulnerabilidades y cómo se solucionan.
  • Instructores: Cristian Borghello y Diego Chavez
  • Modalidad: se dicta en cinco sesiones a distancia.
  • Fechas de las 5 clases: comienza el día martes 14 de junio de 2016, continúa jueves 16, martes 21, jueves 23 y finaliza el martes 28.
  • Horario: de 19:00 a 21:00 hs. (Zona horaria UTC -3:00, Buenos Aires)
  • Lugar: en línea
  • Público Objetivo: el curso está orientado a desarrolladores y personas con conocimientos de desarrollo web y Javascript, líderes de proyecto, analistas de sistemas y personas vinculadas al análisis, diseño, arquitectura y desarrollo de aplicaciones, así como a los responsables de seguridad de la información de la organización.
  • Precio: consultar en MUG
OWASP Top 10 es una lista de las 10 vulnerabilidades más comunes encontradas en aplicaciones web y los errores de programación que generan dichas vulnerabilidades elaborada por la organización Open Web Application Security Project.
Node.js es un entorno multiplataforma basado en el motor V8 de Google y que permite ejecutar programas altamente escalables en JavaScript y en el backend. Actualmente es un lenguaje ampliamente utilizado en ambientes Linux y Windows.
Luego de finalizado el curso será capaz de:
  • Conocer y entender las vulnerabilidades consideradas críticas por OWASP
  • Entender las amenazas y vulnerabilidades a las que está expuesta cualquier aplicación
  • Reconocer y detectar de manera proactiva las falencias del desarrollo de las aplicaciones
  • Aumentar la seguridad de las aplicaciones Node.js con ejemplos prácticos
Las reservas no abonadas caducan el lunes 6 de junio de 2016. Las vacantes se confirman definitivamente abonando el arancel. Vacantes limitadas. Residentes en otros países, consultar aranceles y formas de pago.

Cristian de la Redacción de Segu-Info

Microsoft bloqueará las contraseñas fáciles o que se hayan filtrado en Internet

Normalmente, cuando se hace un ataque de fuerza bruta para averiguar contraseñas, se prueba con las contraseñas más sencillas y comunes, tales como 123456, qwerty y password. Ahora, Microsoft quiere evitar que hagas esto y te obligará a que elijas una contraseña segura para utilizar sus servicios, tales como Windows, Azure, Outlook, Skype, Xbox LIVE, etc.
Microsoft aconseja elijamos una contraseña única, compleja y muy difícil de adivinar. Cuantos más elementos complejos la compongan, más difícil será de adivinar por un posible hacker. A partir de ahora, para ayudarnos en esta tarea, Microsoft ha establecido un sistema que nos impedirá elegir este tipo de contraseñas a la hora de registrarnos en sus servicios.

Para mejorar su sistema, Microsoft añade a su base de datos contraseñas que hayan sido filtradas al público de manera constante. De esta manera, mediante un sistema de bloqueo dinámico, evita que se establezcan contraseñas inseguras.

Además de las filtradas al público, Microsoft también monitoriza los ataques de fuerza bruta que recibe en sus servicios. Sus infraestructuras reciben la impresionante cifra de 10 millones de ataques por día. En estos ataques se prueban contraseñas comunes como las que tenemos en la lista más arriba, y Microsoft recoge y añade a sus bases de datos las contraseñas que se prueban en estos ataques. Además, Microsoft publica una completa guía para la contraseñas [PDF].

Como vemos, muchos usuarios no se toman en serio su propia seguridad, por lo que la medida que ha tomado Microsoft es bienvenida para evitar problemas en el futuro y mejorar la solidez de los servicios online que utilizamos. Además, Microsoft no es la única compañía preocupada por mejorar la seguridad de sus servicios, como vimos con Google y la nueva implementación que quieren realizar de contraseñas biométricas.

 Fuente: ADSLZone

Google quiere eliminar las contraseñas para Android en 2017

Google estaría probando una función en GMail que permitía acceder a la cuenta sin contraseña, simplemente usando nuestro móvil. Gracias a esta función, y a la nueva Trust API que Google quiere implementar, podemos imaginar un futuro en el que no tengamos que volver a recordar contraseñas, sino que será nuestro teléfono el que tenga que acordarse de nosotros.

Para el año que viene, Google quiere eliminar la necesidad de tener que introducir la contraseña cada vez que accedamos a una nueva aplicación. Actualmente, es algo engorroso que cada aplicación necesite de su login individual, cuando ya tenemos nuestra cuenta de Gmail asociada al teléfono y totalmente sincronizada.

Google quiere ir un paso más allá, y ha desarrollado una API llamada "Trust API". Esta API se encargará de recoger información de la mayoría de sensores que integran nuestro teléfono para poder hacer una identificación precisa del usuario que está utilizando el teléfono. El teléfono evaluará ciertos parámetros del usuario, como: velocidad de escritura, patrones en la voz, reconocimiento facial, localización, dispositivos bluetooth cercanos, y redes Wi-Fi que se encuentren alrededor del usuario.

En función de la necesidad de seguridad de la aplicación, las aplicaciones necesitarán una puntuación de confianza más alta o más baja. Para juegos y algunas apps básicas, no será necesario una puntuación muy alta. Pero, para aplicaciones de banca, se necesitará la puntuación más elevada.
Este sistema puede presentar ciertos problemas de seguridad, tales como una posible suplantación de identidad mediante videos. En Google deben trabajar en implementar correctamente este sistema. Ellos esgrimen que las contraseñas pueden ser hackeadas, y que cualquiera con una llave puede abrir una puerta, ya que la puerta no distingue quien la abre; sólo entiende que la llave que la está abriendo es la correcta. Si consiguen implementar correctamente este sistema, en Google afirman que la seguridad será mayor.
Entre humanos, distinguimos muchos factores que nos permiten diferenciar a las personas entre sí. Un ejemplo de esto se da cuando una persona de 40 años va a comprar alcohol a un supermercado. La cajera no le va a pedir el DNI, ya que signos clave que indican que esa persona tiene 40 años. Es bajo esta idea sobre la que se basa este nuevo sistema de seguridad. El teléfono nos distinguirá como si él mismo fuera un humano.

Fuente: ADSLZone | Android Authority

Píldora formativa Thoth 36 ¿Qué es el código Base64?


Los códigos en informática y en seguridad son muy importantes. El código más conocido y usado actualmente es el denominado ASCII extendido de 256 caracteres, con el que codificamos un conjunto de letras, números y símbolos mediante cadenas de 8 bits. No obstante, en realidad el código ASCII original tenía sólo 7 bits y el octavo bit se usaba como paridad para el control de errores. Contienen elementos imprimibles y otros no imprimibles, lo que provocaba problemas de compatibilidad entre equipos. Algo que se soluciona con un código intermedio de 6 bits con todos sus elementos imprimibles, el código Base64. ¿Sabías que en este formato recibimos los archivos adjuntos de un correo electrónico?

Enlace en YouTube a la píldora 36 ¿Qué es el código Base64?
https://www.youtube.com/watch?v=TvlHDA0J7QM

Todos los vídeos del proyecto Thoth cuentan con un archivo SRT original de subtítulos incluido en YouTube, importante para personas con limitaciones auditivas, así como un archivo Podcast MP3 que puede descargarse desde el sitio web, válido en este caso tanto para personas con limitaciones visuales como para quienes deseen realizar solamente la audición de estas lecciones.

Dr. Jorge Ramió, Dr. Alfonso Muñoz
Directores del proyecto Thoth

Fuente: http://www.criptored.upm.es/thoth/index.php

25 may. 2016

FBI advierte sobre cargadores USB con keyloggers

El FBI emitió una alerta para la industria privada en relación a un keyloggers que se esconden en cargadores USB de pared, y tienen como blanco a teclados inalámbricos. Las características son idénticas a las de KeySweeper, hasta ahora el único caso conocido de un cargador que registre las pulsaciones; sin embargo, es curioso que este aviso haya salido el 29 de abril pasado, cuando la aparición de KeySweeper fue en enero de 2015. Si se coloca estratégicamente en una oficina, un atacante podría recolectar información personal

KeySweeper ha sido creado por el investigador Samy Kamkar que logró construir con apenas 10 dólares de presupuesto un completo keylogger camuflado en un cargador USB que registra las pulsaciones de teclados inalámbricos Microsoft.

Samy ha puesto a disposición de quien quiera construirse su propio dispositivo keylogger todas las instrucciones necesarias en su cuenta de Github, aunque ya avisa de que nadie con la suficiente experiencia a la hora de manejar dispositivos electrónicos debería intentarlo siquiera, por el riesgo evidente de electrocución.
Vale la pena prestar atención a la advertencia de la fuerza de seguridad. Después de todo, la posibilidad de que algo que supuestamente está cargando tu teléfono registre tus contraseñas y todo lo que escribes para reportarlo a un atacante podría ser alarmante.

De todas formas, no debes entrar en pánico: el peligro existe solo cuando tu dispositivo móvil está enchufado a este cargador USB de pared alterado, que posee en su interior elementos como un minicontrolador Arduino y un chip de radiofrecuencia.

Además, lo que espía es la comunicación de ciertos teclados inalámbricos de Microsoft fabricados antes de 2011 con el equipo, por lo que deberían darse todas estas condiciones para que el ataque, que hasta el momento es una prueba de concepto mostrada por Samy Kamkar en un video, sea exitoso.

El FBI señala:
Si se coloca estratégicamente en una oficina u otra locación donde individuos podrían usar dispositivos inalámbricos, un atacante podría potencialmente recolectar información de identificación personal (PII), propiedad intelectual, secretos comerciales, contraseñas u otra información sensible.

Dado que los datos son interceptados antes de llegar al CPU, los jefes de seguridad podrían no tener conocimiento de cómo la información sensible está siendo robada.
Al mismo tiempo, el FBI asegura que una herramienta como KeySweeper podría ser usada para espiar los registros de otros dispositivos inalámbricos, además de teclados.

"Dado que los dispositivos Arduino son modulares y programables, un actor podría recolectar datos capturando y descifrando protocolos de comunicación de varios otros dispositivos inalámbricos, dependiendo de la debilidad o facilidad de explotación del cifrado de ese protocolo", dice el comunicado.

Conociendo los rangos de radiofrecuencia en los que operen, "un dispositivo como KeySweeper podría ser usado para recolectar datos de otros dispositivos inalámbricos además de teclados, para potencialmente incluir datos desde Bluetooth, Wi-Fi o tráfico SMS". Sin embargo, cabe destacar que la posibilidad de recolectar la información no implica que se pueda acceder a ella; eso depende de si se puede romper el cifrado del protocolo que se utiliza.

Al pie de página, el FBI aclara que estos hallazgos surgen de una investigación propia, lo cual podría explicar la "demora" en el lanzamiento de la advertencia. Sin embargo, como señala Ars Technica, el comunicado no hace ninguna referencia a atacantes interceptando tráfico de dispositivos inalámbricos In-the-Wild. El medio le preguntó a Samy Kamkar si sabía de algún ataque real que usara dispositivos similares a KeySweeper y tampoco él está al tanto de ninguno.

Aún así, nunca está de más escuchar una advertencia, sobre todo en el cambiante ámbito de la seguridad informática: el vector de ataque que hoy no existe podría ser hallado mañana.

Por eso, en el ámbito corporativo, mejor seguir los consejos del FBI:
  • Limitar la cantidad de enchufes disponibles para cargar dispositivos
  • Saber qué cargadores están siendo utilizados
  • Sacar de las instalaciones cualquier cargador desconocido
En cuanto al hogar, como mencionamos arriba, hay ciertas condiciones específicas que deberían cumplirse para que un keylogger pueda espiar los registros de un teclado inalámbrico. De igual forma, es preferible evitar su uso y elegir teclados con cable mientras sea posible.

Fuente: We Live Security

Webcast gratuitos sobre seguridad [ElevenPaths]

El mundo de la seguridad de la información es a la vez, tan largo y tan dinámico, que a veces cuando alguien quiere comenzar con un tema que no domina, no sabe por dónde empezar; y normalmente, quienes trabajamos en los diferentes ámbitos dentro de una empresa, no tenemos el tiempo suficiente para poder publicar o escribir periódicamente sobre lo que nos gusta.
Por este motivo, es bueno ver que existen iniciativas no comerciales que intentan difundir conocimiento de nuestro mundillo más allá de objetivos de negocio, y que para eso, las empresas donen tiempo de sus empleados con el objeto de compartir.

La empresa ElevenPaths tiene una serie de "evangelizadores" y, junto a todo el equipo de CSAs han diseñado y preparado una propuesta relacionada con las transmisiones en vivo por internet de videos que duran entre 30 y 60 minutos todos los días jueves a la misma hora (15:30 hs CET, o sea las 10:30 hs Argentina). Dichos videos quedan luego disponibles en nuestro canal de Youtube y los temas elegidos han sido bien variados. Al día de hoy llevamos realizados 10 transmisiones
Se encuentran publicadas 5 más a las cuales podrán inscribirse aquí o bien mirar luego las grabaciones en nuestro canal de youtube

En breve publicaremos los títulos de la siguiente tanda de charlas, sin embargo, si quieren que se hable sobre algún tema en particular, no duden en escribirnos por Twitter para indicarnos sus ideas.

Claudio Caracciolo
Chief Security Ambassador at Eleven Paths
ElevenPaths

24 may. 2016

Cuentas de Instagram vulnerables a ataques (cambia tu contraseña!)

Recientemente, Facebook ha solucionado una serie de fallos de seguridad en el sistema de autenticación de Instagram que estaban siendo utilizados para robar contraseñas de Instagram mediante ataques de fuerza bruta. Cuando un usuario tiene una cuenta inactiva, esta se "congela" como medida de seguridad para evitar que un tercero puedan tomar su control y, cuando el dueño intenta iniciar sesión con el usuario y la contraseña originales, se le pide cambiar la clave para descongelarla y recuperar el control sobre ella.
Uno de los fallos de seguridad se encontraba en el proceso de restablecimiento de contraseña, el cual se asociaba a cada usuario mediante un identificador único que, si se modificaba por otro aleatorio, podía permitir a un atacante restablecer la contraseña de otro usuario al azar evitando incluso el proceso de autenticación con el servidor.

Otro fallo de seguridad en el sistema de autenticación se encuentra en la posibilidad de cambiar la dirección de correo y el número de teléfono asociado a una cuenta de manera mediante un proceso similar de manera que un atacante pueda pedir restablecer la contraseña vía SMS para tomar el control sobre el perfil de Instagram.

Entre ambos bugs, se podría haber vulnerado las cuentas de al menos 20 millones de usuarios de Instagram.

La solución era simple, pero la compañía no era consciente de la vulnerabilidad. Ahora, las páginas de actualización y cambio de perfil obligan a cumplir con la autenticación, por lo que, aunque intentemos acceder a una página de un usuario al azar para cambiar sus datos, no podremos hacerlo salvo que tengamos la correspondiente contraseña.

Estos fallos de seguridad en los diferentes procesos de autenticación han sido descubiertos por un investigador llamado Arne Swinnen y Facebook, como parte de su programa de recompensas, le ha pagado por él 5000 dólares. Además, el investigador de seguridad recomienda a los usuarios utilizar contraseñas largas y seguras (Instagram permite configurar contraseñas de hasta 40 caracteres) de manera que, aunque muchas vulnerabilidades no dependen de nosotros, al menos no podamos ser víctimas de ataques informáticos basados en fuerza bruta.

Fuente: Redes Zone

El negocio de la denegación de servicio distribuida

En el ecosistema del cibercrimen actual, las denegaciones de servicio distribuidas se han convertido en un negocio más del amplio mundo del fraude.Los ataques de denegación de servicio -Denial of Service (DoS)- son ataques cuyo objetivo es evitar el funcionamiento normal de una red o servicio. Este ataque se puede llevar a cabo de diversas maneras, aunque las más comunes suelen ser la saturación del ancho de banda y el agotamiento de recursos que utiliza.Inicialmente, los ataques DoS se realizaban desde un único origen, generando un flujo de datos que saturaba los recursos del host o red. De este modo se evitaba que éste pudiera responder de manera eficiente a usuarios legítimos del sistema.

Con el fin de aumentar los daños, se modificó la arquitectura inicial, pasando a una arquitectura distribuida con múltiples orígenes. Con este cambio de arquitectura los ataques pasaron a denominarse Distributed Denial of Service (DDoS). Normalmente los orígenes de un ataque DDoS se encuentran en las llamadas botnets o redes zombie. Estas redes están formadas por miles de ordenadores controlados remotamente mediante un panel de control, lo que facilita la capacidad de generar el ataque a una sola persona.Lógicamente el uso de miles de ordenadores amplifica el ataque de manera exponencial frente al ataque DoS. A cada equipo infectado que pertenece a una botnet se le puede denominar drone, zombie o bot, mientras que al malware que lo infecta también se le puede llamar bot.

Oferta y demanda

La oferta y la demanda marcan cada día el coste de contratar este tipo de servicios. El coste de ofrecer el servicio para el dueño de una botnet es nulo ya que tanto los ordenadores usados como la cuota de Internet van a cargo de la persona infectada. Para los dueños de las botnets, además del robo directo de información bancaria, este tipo de servicio es simplemente otra forma de explotar su botnet para obtener un mayor beneficio sin que les suponga una carga extra.

Precios y condiciones

Un precio orientativo para el alquiler de una botnet es de unos 200 dólares por el alquiler de 10.000 bots durante 24 horas. Aunque en este mercado se da mayor valor a bots alojados en países con mejor ancho de banda, lo que podría traducirse, a modo de ejemplo, en que el precio de 5.000 bots en Inglaterra pueda ser el mismo que el alquiler 10.000 bots en Rumania.

Una botnet del tamaño anterior podría llegar a generar un tráfico de 100Gbps, lo que es más que suficiente para anular el acceso a prácticamente cualquier página en Internet durante las 24 horas por las que se ha contratado el servicio.Y como es normal en los mercados, existen descuentos para contrataciones por periodos de tiempo muy elevado.

También es muy común que se permita realizar una prueba para poder verificar la fiabilidad de la botnet que se desea contratar, y estas pruebas permite atacar al sitio web indicado durante dos o tres minutos permitiendo observar la potencia de la botnet.

Evolución

Se trata de un mercado altamente competitivo y en continuo movimiento que busca innovar para superar al competidor. Como evolución natural de esta innovación han entrado en juego los smartphones. Si tenemos en cuenta que en una botnet de unos 10.000 bots distribuidos por países, la posibilidad de que todos ellos estén conectados a la vez es muy remota, la captura de dispositivos smartphone se ha convertido en el foco principal para este negocio.

Estos dispositivos, al tener una conexión directa y continua con Internet, ofrecen las mismas cualidades que los ordenadores actuales y siempre están disponibles para ser usados para la realización de un ataque, que puede mantenerse sin que el usuario sea consciente de dicha actividad en su dispositivo.

Cómo acceder a estos servicios

Para un usuario obtener acceso a esta información es complicado, ya que se mueven en foros protegidos y muy privados, donde sólo se puede entrar mediante la invitación de uno de sus miembros. Con esta exclusividad consiguen ponerse a salvo de investigaciones policiales, ya que en estos foros no sólo se mueven mercados de botnets, sino que es un mercado negro de todo tipo de temas ilegales que pueden ir desde la venta de drogas al alquiler de botnets, pasando por venta de tarjetas de crédito, órganos…

Si bien es cierto que hay otras botnets que ofrecen servicios de DDoS por cinco dólares a la hora, no estamos hablando del mismo tipo de servicio. Como en todos los mercados hay diferentes clases de productos, y el acceso a los mismos no es igual para todas las personas. El acceso a botnets con un coste de cinco dólares puede ser encontrado de forma sencilla en canales de IRC (Internet Relay Chat), o foros de hacking, y estas ofrecen ataques que podrían llegar a saturar una web normal. Mientras que en los servicios ofrecidos en foros privados, se garantiza que el servicio funcionará durante el tiempo contratado.

Cómo operar una 'botnet' para DDoS

La persona que alquila el servicio tiene acceso a un panel de control desde donde puede gestionar los bots que ha contratado. Suelen tener una interfaz muy sencilla y de fácil manejo. Mediante estos paneles es posible realizar ataques de diferente tipo y verificar que lo contratado se corresponde con lo ofertado.

Mitigación

Mitigar o contrarrestar un ataque DoS no siempre es garantía de éxito, especialmente en el caso de que el ataque esté orientado al consumo del ancho de banda, aunque no por ello hay que desistir de utilizar contra-medidas. Actualmente hay una serie de premisas que deberían prevalecer:
  • Tener actualizado todo el software utilizado en el servicio, desde el sistema operativo de cualquier dispositivo hasta cualquier aplicación o librería empleada.
  • Emplear una política robusta de contraseñas.
  • Aplicar todos los filtros necesarios en las fronteras del ISP.
  • Redundancia del servicio.
  • Usar servicios en hosting dedicado y/o clouding.
Se pueden establecer además una serie de medidas para minimizar el impacto del ataque, reducir el tráfico no legítimo, etc. Estas medidas pasan por identificar el tráfico ilegítimo o anómalo.Las anomalías dentro de los servicios disponibles permitirán ejecutar acciones y/o generar alertas. A continuación se muestran, a modo de resumen, una serie de detecciones de anomalías del tráfico generado para un servicio.

Análisis estadístico

En este grupo se pueden englobar los ataques de SYN flooding orientados a saturar el número máximo de sesiones concurrentes en un servicio HTTP. Actualmente, y dado el tipo de ataques que se observan -mayoritariamente de aplicación http-, es importante establecer un análisis estadístico del tráfico HTTP de los servidores. Por ejemplo, 100 peticiones por segundo desde la misma IP a la misma URL podría considerarse una anomalía.

Descripción de camino hasta el objetoSi se sabe el camino que realiza una petición hasta llegar a un objeto dentro de los servicios que ofrece, se podría modelar una anomalía, haciendo que el camino a seguir por dicha petición sea distinto al esperado.Siguiendo con HTTP/HTTPS, si para llegar a la URL http://www.test.com/web/from1.jsp hay que hacerlo desde la URL http://www.test.com/web/main.jsp, cualquier otro camino sería considerado una anomalía.

Tiempo mínimoEl tiempo que transcurre entre peticiones ha de ser mayor cuando estas son realizadas por una persona y no por un programa, por lo que esta medida de tiempo también permite establecer un patrón de comportamiento anómalo.

Datos sospechosos

El análisis de tráfico de aplicación puede ofrecer muchas ayudas para detectar tráfico anómalo. Por ejemplo, comprobando la existencia de User-Agent o si este es utilizado frecuentemente para realizar la petición.Gran parte de las anomalías podrán ser detectadas y eliminadas desde el mismo dispositivo frontera que se esté utilizando -cortafuegos o router-. Otras requerirán una monitorización de los logs del servidor -proxy, web- para efectuar las acciones que se consideren oportunas, como bloquear directamente en los servidores o generar alertas.Para intentar minimizar el impacto que tendrá sobre la infraestructura un ataque de denegación de servicio, las recomendaciones generales son las siguientes:
  • Configurar los dispositivos de red, routers y firewalls para detener direcciones IP no válidas y protocolos que no sean necesarios.
  • Activar las protecciones de inundación TCP/UDP. Dichas protecciones deberán de tener presentes medidas como la cantidad de peticiones realizadas por una misma dirección IP, conexiones concurrentes, ancho de banda utilizado por cada dirección de origen, etc. Es importante evaluar el impacto que tienen dichas protecciones sobre el rendimiento y la disponibilidad, para evitar que se produzca el efecto contrario y los firewalls terminen convirtiéndose en cuellos de botella.
  • Activar los mecanismos de registro de actividad, teniendo presente la carga que pueden suponer para el rendimiento de la plataforma. De esta manera se podrá analizar a posteriori la información registrada si fuera necesario.
  • Los elementos de detección IDS/IPS podrán mitigar el impacto de los ataques con los sistemas de análisis de protocolos y vectores de ataque.
  • Los proveedores de servicio o ISP pueden ayudar también a minimizar el impacto activando el filtrado de tráfico antes de que este alcance la infraestructura.
  • Para los ataques a las aplicaciones se pueden establecer configuraciones de protección o tecnologías anti-DDoS.
  • Los planes de contingencia serán de gran ayuda, ya que el personal implicado conocerá con detalle cuál es su función en cada momento y qué acciones tendrán que realizar.
  • La comunicación con los usuarios legítimos o clientes de la organización también ayudará a que el impacto económico sea menor. 
Por Juan de la Fuente, S21sec eCrime Analyst y Juan Carlos Montes, S21sec eCrime Analyst

Fuente: Red Seguridad

100 cómplices, 1.400 locales, 3 horas y un robo de U$S12 millones

Un centenar de personas robaron en menos de tres horas 1.400 millones de yenes (alrededor de US$12.7 millones) en un ataque coordinado a cajeros automáticos de Japón en el que utilizaron tarjetas de crédito falsificadas, informaron hoy medios nipones. El robo se realizó en tiendas "24 Horas" de las ciudades .
La policía japonesa detalló que el robo tuvo lugar de manera simultánea en 1.400 tiendas muy populares, y que cuentan con cajeros automáticos, de todo el país el pasado 15 de mayo.

Las tarjetas de crédito falsificadas y utilizadas para cometer el robo contenían datos de 1.600 cuentas de un banco sudafricano, según la investigación de la policía nipona, que colaborará con la Interpol y con las autoridades de Sudáfrica para esclarecer la estafa cometida en Tokio y otras 16 regiones del país.

Los ladrones llevaron a cabo alrededor de 14.000 transacciones en las que retiraron la máxima cantidad de dinero permitida -100.000 yenes, unos U$S900, en cada operación.

La policía japonesa analiza ahora las imágenes de las cámaras de seguridad de los establecimientos para identificar a los autores del hurto, que según apunta la investigación pertenecen a una organización de delincuencia organizada de Malasia.

Fuente: Clarín

23 may. 2016

Caso práctico de Phishing orientado con Frenzy

En ocasiones durante una auditoría nos podemos encontrar con la necesidad de lanzar una campaña de phishing, para ganar acceso, por estar realizando un APT o simplemente dentro de un programa para concienciar a los trabajadores.

En la entrada de hoy vamos a ver Phishing Frenzy un framework escrito en Ruby para realizar campañas de phishing que nos permite llevar a cabo todas las fases del proceso.

Para la prueba de concepto vamos a utilizar Docker por su sencillez y comodidad. El siguiente comando descarga la imagen de Docker Hub y crea un contenedor.
docker run -d -p 80:80 b00stfr3ak/ubuntu-phishingfrenzy
Comprobamos que el contenedor esta corriendo. La imagen de docker que estamos ejecutando esta configurada con el Virtual Host phishingfrenezy.local. Para ajustarlo a nuestras necesidades podemos incluir dicho registro en nuestro archivo hosts local o bien modificar la configuración del contenedor, nosotros vamos a optar por la segunda.

La imagen de docker que estamos ejecutando esta configurada con el Virtual Host phishingfrenezy.local. Para ajustarlo a nuestras necesidades podemos incluir dicho registro en nuestro archivo hosts local o bien modificar la configuración del contenedor, nosotros vamos a optar por la segunda.

Para ello, iniciamos una Shell interactiva en nuestro contenedor y modificamos los siguientes archivos;
/etc/apache2/pf.conf linea ServerName
/var/www/Phishing-Frenzy/config/application.rb linea SITE_URL
Reiniciamos Apache, service apache2 reload y accedemos con el navegador a la interfaz web de Phishing Frenzy y las credenciales por defecto admin:Funt1me!
Como defensa es importante realizar campañas contra nuestros propios usuarios con el objetivo de concienciar al personal frente a futuros ataques.

Contenido completo en fuente original Follow the White Rabbit