Mostrando entradas con la etiqueta Phishing. Mostrar todas las entradas
Mostrando entradas con la etiqueta Phishing. Mostrar todas las entradas

miércoles, 4 de julio de 2018

Campaña de phishing contra Trezor utilizando DNS spoofing o secuestro BGP

La famosa compañía de billeteras hardware Trezor descubrió la campaña el pasado fin de semana.

Resultado de imagen de trezor wallet hacked

El equipo detras del servicio de monederos descubrió un ataque de phishing contra varios de sus usuarios durante el fin de semana.

La compañía apunta a que el ataque se trata de un envenenamiento DNS o un secuestro BGP, ya que los atacantes secuestraron el tráfico legítimo destinado al dominio oficial y redirigieron a estos usuarios a un servidor malicioso donde se alojaba la página fraudulenta.

Detección del fraude

El incidente fue detectado después de que los usuarios se quejaran de que encontraban un certificado HTTPS no válido en la web de la compañía.


Un aviso de certificado no válido generalmente significa que el dominio al que se se está accediendo no coincide con quien dice ser en el certificado. En ocasiones, como en esta, se puede tratar de una web que se hace pasar por otra, y este último no es verificado como sitio de confianza por el cliente (en este caso, el navegador).

Este error alertó a la comunidad de Trezor, cuyos miembros informaron rápidamente al equipo de soporte de la compañía, quien luego confirmó el intento de suplantación de identidad y advirtió a los usuarios sobre el fraude que se estaba realizando.

Diferencias entre el sitio web real y el falso

El equipo de Trezor determinó que se trataba de un ataque de phishing legítimo y no solo un error aleatorio del servidor SSL porque detectaron dos problemas con el sitio web.


El primero, era un mensaje de error que estaba redactado de manera diferente al sitio web original. En él se notificaba a los usuarios que la sincronización de los datos entre su cartera de Trezor y su cuenta web había fallado.

Sitio web de Fake Trezor

En segundo lugar, el sitio web falso pedía a los usuarios que ingresaran su semilla de recuperación, algo que el equipo de Trezor dijo que nunca haría.

La compañía explica claramente que los usuarios nunca deben ingresar la semilla de recuperación en ningún otro lugar que no sea su dispositivo Trezor. 

Es pronto para conocer el alcance que ha tenido esta campaña, pero esperemos que dentro de poco sepamos si finalmente las víctimas han perdido sus fondos.


Daniel Púa
@dpua_
dpua@hispasec.com

Más información:

Alerta en el blog de Trezor:






miércoles, 2 de mayo de 2018

FacexWorm: el malware que se extiende a través de Facebook

Descubierto por Trend Micro, este malware se camufla tras una extensión de Google Chrome para robar criptomonedas a las víctimas.
Esquema de funcionamiento de Facexworm. Obtenida de Hacker News.


La técnica de ataque utilizada por la extensión maliciosa surgió por primera vez en agosto del año pasado, pero los investigadores han descubierto que se añadieron nuevas capacidades a principios de este mes.

Estas novedades incluyen el robo de credenciales de sitios web, redirigir a las víctimas a estafas de criptomonedas y/o al enlace de referencia del atacante en programas relacionados con criptomonedas e inyectar mineros en las webs.

A finales del año pasado, se descubrió un bot de minería llamado Digmine el cual se propagaba a través de Facebook Messenger y tenía como objetivo a ordenadores Windows, así como a Google Chrome.



Instalación de la extensión fraudulenta. Obtenida de Hacker News.
Al igual que el malware que acabamos de mencionar, FacexWorm también se propaga mediante ingeniería social a través de Facebook Messenger para redirigir a las víctimas a versiones falsas de sitios webs populares tales como YouTube.

Cabe señalar que la extensión solo se diseñó para usuarios de Chrome. Si el malware detecta cualquier otro navegador web en el dispositivo de la víctima, redirige a un anuncio de aspecto inofensivo.

Cómo funciona

Si el enlace al vídeo malicioso se abre con Chrome, FacexWorm redirecciona a la víctima a una página falsa de YouTube, donde se aconseja al usuario a descargar una extensión maliciosa para el navegador como si de un códec para reproducir el vídeo se tratase.

Una vez instalada, la extensión descarga más módulos para realizar varias tareas maliciosas.
"FacexWorm es un clon de una extensión legítima de Chrome, pero se le inyectó un código que contiene su rutina principal. Descarga el código JavaScript adicional del servidor C&C cuando se abre el navegador", explican los investigadores.

Dado que la extensión toma todos los permisos extendidos en el momento de la instalación, el malware puede acceder o modificar datos para cualquier web que el usuario abra.

A día de hoy, las criptomonedas reconocidas a las que se dirige FacexWorm incluyen Bitcoin (BTC), Bitcoin Gold (BTG), Bitcoin Cash (BCH), Dash (DASH), Ethereum (ETH), Ethereum Classic (ETC), Ripple (XRP), Litecoin (LTC), Zcash (ZEC) y Monero (XMR).

Dado que las campañas de spam en Facebook son bastantes comunes, se aconseja a los usuarios estar atentos al hacer clic en enlaces y archivos proporcionados a través de la plataforma del sitio.

Daniel Púa
@dpua_
dpua@hispasec.com

Más información:


FacexWorm Targets Cryptocurrency Trading Platforms, Abuses Facebook Messenger for Propagation:
https://blog.trendmicro.com/trendlabs-security-intelligence/facexworm-targets-cryptocurrency-trading-platforms-abuses-facebook-messenger-for-propagation/



viernes, 11 de agosto de 2017

Comprometidas dos populares extensiones de Google Chrome

El equipo de seguridad de Google ha enviado advertencias a través de e-mail a los desarrolladores de extensiones de Chrome después de que muchos de estos fuesen objetivos de ataques de phishing. Algunos de estos ataques consiguieron su objetivo y permitieron el robo de algunas extensiones.

Estos ataques tuvieron lugar la semana pasada, cuando las cuentas de los desarrolladores de las extensiones CopyFish (80.000 usuarios) y Web Developer (100.000) se vieron comprometidas. Los atacantes aprovecharon para insertar código malicioso de adware en la extensión. De esta manera consiguieron ingresos a través de todos los usuarios que las tuvieran instaladas. 

Estos ataques llevan cerca de dos meses produciéndose sin que hasta la fecha nadie se haya percatado. El phishing en cuestión se hace pasar por una cuenta oficial de Google, informando a los desarrolladores de una supuesta violación de los terminos de servicio de Chrome Web Store. Es entonces cuando las víctimas accedian a un sitio falso que solicitaba el login a una cuenta de Google. 

Phishing email
Captura de los e-mails de phishing. Fuente: www.bleepingcomputer.com

Los avances en la investigación indican que los dominios utilizados para robar la información de estas dos extensiones son los mismos, y el e-mail prácticamente idéntico, lo que apunta a un actor común en ambos ataques. La misma estrategia fue probada de nuevo en agosto, pero esta vez Google Safe Browsing bloqueó estos enlaces fraudulentos. 

Tras el secuestro de las extensiones, Google envió un e-mail a todos los desarrolladores informando de la situación e indicando las instrucciones para reportar futuros casos similares. 

Google email warning
Captura del e-mail de alerta de Google. Fuente: bleepingcomputer.com


Fernando Díaz
fdiaz@hispasec.com

Más información: 

Chrome Extension Developers Under a Barrage of Phishing Attacks


jueves, 3 de agosto de 2017

Certificados de dominio gratuitos: tu conexión con el phishing es segura

En el último post de su blog, Zscaler, una empresa de servicios de seguridad en la nube, ofrece algunas estadísticas interesantes sobre el uso de conexiones cifradas en esquemas de fraude y malware. No profundizaremos mucho en los datos, que vienen a confirmar con cifras concretas una situación que aquellos que trabajamos con phishing y malware conocemos: el constante incremento de amenazas que hacen uso de conexiones cifradas.


Aunque el artículo se centra en el malware, hay un dato que a priori puede pasar desapercibido aun siendo bastante abultado: según sus mediciones, los ataques de phishing que hacen uso de SSL/TLS han aumentado desde el pasado año. En un 400%. 12.000 peticiones al día en su plataforma.




Y esto, ¿por qué?


Este aumento no es casual. Por definición, el phishing necesita simular el sitio que suplanta, y el uso de una conexión cifrada o segura era un fleco que quedaba para satisfacer esta necesidad, más aún con la popularización del SSL/TLS. De hecho, el famoso "candadito verde" ha sido señalado durante años como indicador para diferenciar sitios legítimos y fraudulentos. El problema es que su significado no es el que se le atribuye.


Hace 9 años ya hablábamos de esto en "Mitos y leyendas: Compruebe el candadito del navegador para estar seguro". Entonces ya comentamos que los certificados de validación de dominio, aparte de la función de cifrado, simplemente aseguran que el dominio pertenece a su propietario. Esta condición no es falsa para dominios fraudulentos; sigue siendo cierto que el phisher es el propietario, y hace factible el tener un sitio “seguro” aun siendo un phishing.

Por ello se introdujeron soluciones como los certificados EV (Extended Validation) que requieren no solo pruebas de propiedad del dominio, sino además de que el propietario es la entidad que dice ser. Son aquellos que aparecen con el nombre de la empresa en color verde en el navegador.

¿Cómo ha crecido tanto?

Varios factores han propiciado el aumento de conexiones cifradas en el phishing de un tiempo a esta parte. Por un lado, iniciativas como Let's Encrypt, que permiten la obtención de un certificado de validación de dominio de manera gratuita solo demostrando control sobre el dominio. Y esto ya le ha valido alguna que otra queja. Si hace 9 años había certificados similares por 20 euros, hoy no tienen coste y el proceso de instalación es totalmente automatizado.


La posición de Let's Encrypt al respecto es clara y no ha cambiado desde hace 2 años: Los emisores de certificados no son (y no pueden ser) vigilantes de contenido:
First, CAs are not well positioned to operate anti­-phishing and anti-malware operations – or to police content more generally. They simply do not have sufficient ongoing visibility into sites’ content. The best CAs can do is check with organizations that have much greater content awareness, such as Microsoft and Google. 
Josh Aas, Director de Let's Encrypt: https://letsencrypt.org/2015/10/29/phishing-and-malware.html



A este respecto, Let's Encrypt sí comprueba los dominios que piden certificados con Google Safe Browsing, de forma que el certificado se deniega si están marcados como malware o phishing. Sin embargo, la utilidad de esta medida no está del todo clara, ya que el certificado se pide poco después de pedir el dominio, en un momento en el que ni siquiera tiene contenido y, por tanto, no ha podido ser detectado. Como ellos mismos dicen, “el contenido cambia de manera más rápida que lo que una CA puede comprobar o certificar”.




Pero el problema puede agravarse. Plataformas de creación de sitios gratuitos, algunas auténticos nidos de fraude, ofrecen también desde hace tiempo añadir SSL de manera automática e incluso sin coste. Esta característica se ofrece a través tanto de Let's Encrypt como de la plataforma cPanel, que a finales de año comenzó a ofrecer este servicio junto a Comodo. En estos casos, el phisher no tiene más que marcar una casilla para obtener un certificado y "candadito" para su sitio fraudulento.


Y todo esto unido a los sitios comprometidos que ya cuentan con certificado y del que se aprovechan los atacantes. Aunque en este caso el phishing es más evidente al ser el dominio distinto.


Sea cual sea el caso, solo hay que darse una vuelta por Phishtank para encontrar algunos ejemplos.


¿Por qué ahora y no antes?

La popularización del cifrado en la web y el empuje de los navegadores han tenido mucho que ver. Toda web con un formulario y sin HTTPS es marcada con un rotundo “No es seguro” en algunos navegadores, lo que puede disparar las alarmas en el usuario. Lo que antes era un añadido que daba más veracidad al fraude es ahora una necesidad. Por otro lado, hasta la aparición de los certificados gratuitos no salía realmente a cuenta a los atacantes comprarlo y configurarlo, menos aún cuando los tiempos de vida de un phishing son cada vez más cortos.


¿Me fio del "candado" entonces?

Por supuesto, sin perder de vista lo que significa: que la conexión está cifrada y que el dominio pertenece al propietario, aunque este puede ser un phisher. Solo con el candado no podemos estar seguros de que el sitio web pertenece a la organización a la que realmente queremos acceder, pero sigue siendo una métrica más (junto con el nombre del dominio, el enlace que nos ha llevado allí, etc.) para discernir si el sitio es fraudulento o no.


Más información:

SSL/TLS-based malware attacks

World’s Largest CA Comodo and Web Hosting Platform Leader cPanel
Join Forces to Enable Automated SSL Encryption for the Web
https://www.comodo.com/news/press_releases/2016/12/worlds-largest-CA-comodo-and-web-hosting-platform-leader-cPanel.html

Mitos y leyendas: "Compruebe el candadito del navegador para estar seguro" I (Phishing)
http://unaaldia.hispasec.com/2008/06/mitos-y-leyendas-el-candadito-del_03.html



Francisco López

martes, 18 de abril de 2017

Phishing con caracteres Unicode

Se ha confirmado un problema en Chrome y Firefox que podría permitir la realización de ataques de phishing mediante el uso de caracteres Unicode. Conocidos como ataques homográficos, representan un problema que los navegadores intentan evitar, pero se ha descubierto una forma para evitar los controles actuales. Se puede visitar https://www.аррӏе.com/ para entender las implicaciones.

¿A qué cuela?
Con el uso de Punycode se pueden representar caracteres Unicode mediante el subconjunto de caracteres ASCII empleado para los nombres en Internet. De esta forma se pueden registrar dominios que hagan uso de caracteres no permitidos, por ejemplo podríamos registrar un dominio como España.com que quedaría como xn--espaa-rta.com. Evidentemente no es muy empleado porque para temas como el SEO, promoción y marca, no es muy eficiente. Queda raro que haya que escribir algo como xn--espaa-rta.com.

Ahora bien, las implicaciones en el mundo de la seguridad que pueden representar estos dominios son grandes, ya que muchos caracteres Unicode pueden ser difíciles de distinguir de los caracteres ASCII normales. De esta forma, es posible registrar dominios como "xn--pple-43d.com", equivalente a "аpple.com" por el uso de la a en cirílico "а" (U+0430) en vez de la "a" en ASCII (U+0041). Este tipo de ataques son conocidos como homográficos.
Los navegadores modernos tienen mecanismos para evitar o limitar este tipo de ataques. En Chrome y Firefox la forma Unicode se esconde si un dominio contiene caracteres de varios lenguajes diferentes. De esta forma, por ejemplo el dominio "xn--pple-43d.com" aparecerá como tal (en vez de "аpple.com") al contar con caracteres de dos lenguajes, de esta forma se evita la confusión con el dominio real.

Pero el sistema de protección ante ataques homográficos falla si todos los caracteres son sustituidos con un carácter similar del mismo lenguaje. El dominio "аррӏе.com" registrado como "xn--80ak6aa92e.com" evita el filtro al emplear únicamente caracteres cirílicos. Esta forma de evitar la protección afecta a Chrome y Firefox, mientras que Internet Explorer, Microsoft Edge y Safari se libran del problema.

El desarrollador Xudong Zheng (@Xudong_Zheng) reportó el fallo a Chrome y Firefox el 20 de enero de 2017 y confirma que ha quedado corregido en la rama de Chrome 59, aunque finalmente se incluirá en Chrome 58 que estará disponible en torno a la semana que viene. Por ahora sigue sin corregir en Firefox ya que no han decidido si está dentro de su alcance.

Como contramedida en Firefox se puede configurar desde about:config y asignar network.IDN_show_punycode a true. Esto fuerza a Firefox a mostrar siempre los dominios IDN en su forma Punycode, lo que permite identificar los dominios maliciosos.

Más información:

Phishing with Unicode Domains

Punycode

Registrar un dominio con ñ

Phishing with Unicode Domains (Reddit)



Antonio Ropero
Twitter: @aropero

lunes, 12 de diciembre de 2016

Phishing botnet: nueva campaña que afecta a diversas entidades bancarias europeas

Nuestro Laboratorio Antifraude ha detectado una nueva campaña de phishings que está afectando a diversas entidades europeas, entre ellas algunas españolas como Banco Santander y que como particularidad está utilizando una botnet de servidores JBoss comprometidos.

El término botnet casi siempre está unido a familias de malware como pudieran ser Zeus, Spyeye o la última detectada para Android, Gooligan. Sin embargo existen múltiples tipos de botnets para diferentes causas: SPAM, denegaciones de servicio (como Mirai), o despliegue de campañas phishings, como el que nos atañe.

Durante el proceso de detección y cierre que hemos llevado a cabo, hemos podido comprobar que las entidades afectadas eran Deutsche Bank (Alemania), BancaMarche y Posteitaliane (Italia) y al Banco Santander en España en otros.


La campaña de phishing detectada es bastante sencilla en su diseño: un html que carga un fondo previamente capturado del portal principal de la entidad y un formulario que captura los datos y los envía al atacante:


Pero donde gana en complejidad es en su despliegue, con el uso de diferentes tipos de redirección, mediante acortadores de URLs para la campaña de mail masivo y dominios de redirección y con el uso de sitios web comprometidos. Todo ello en búsqueda de frenar los cierres y dar tiempo a montar nuevos sitios comprometidos según van cayendo. También llegan a utilizar técnicas de GeoIP para impedir la visita a aquellos usuarios que no sean objetivo de la campaña, de esta forma sólo muestran el phishing adecuado a cada país.

Una vez comprobados todos estos filtros se expone al visitante el phishing final, que durante nuestros análisis hemos podido comprobar que se encuentran albergados en servidores JBoss vulnerables previamente comprometidos. Es aquí donde hemos podido detectar como novedad en este tipo de casos de phishing, de la presencia de una botnet mediante IRC que controlaba el despliegue de las campañas finales, según se realizaban los mailings masivos a los usuarios.

Ejemplo de la última campaña desactivada es la IP 34.192.25.188, de la que se pueden comprobar los dominios fraudulentos asociados que redireccionaban a la misma:
Por el momento la botnet se encuentra activa y está compuesta por más de 30 servidores comprometidos. Por lo que no dudamos, y según las fechas en las que nos encontramos, se activen nuevas campañas.

Hemos recogido en una entrada denuestro blog del Laboratorio todo el análisis técnico e investigación realizada para el que quiera profundizar en ello.

Por nuestra parte recomendamos como siempre no abrir correos de los que no sepamos su procedencia y aplicar todas las medidas oportunas y sentido común.

Más información:

una-al-dia (02/12/2016) Malware para Android compromete más de un millón de cuentas de Google

Blog Laboratorio Hispasec: Análisis de una Botnet usada para Phishing




José Mesa Orihuela

jueves, 7 de abril de 2016

Fundamentos de anatomía digital: "6 pasos esenciales antes de hacer click"

A lo largo de las escasas 24 horas que tiene un día tomamos cientos de decisiones. No es un número estable. Para algunos serán miles mientras que a otros les bastan unas pocas decenas. La mayoría de esas decisiones son triviales. ¿Papel higiénico acolchado, perfumado, con estampaciones de flores silvestres? Mientras que otras disyuntivas, sin percibir su justo peso, pueden condenar al decisor a una penitencia doble. Por un lado el pago que conlleva las consecuencias de una mala opción y por otro el amargo sabor a derrota que se siente cuando se rememora el momento en el que se tomó la vía equivocada. Somos esclavos de nuestro tiempo y el tiempo es alimento de la historia, lástima que ésta viaje en un solo sentido y nos impida rectificar la huella de nuestras imperfecciones.

Una decisión que ha traído a muchos de cabeza, es ese momento en el que otorgaron un inocente y bienintencionado 'click' a un enlace que les prometía una recompensa en maravedíes o por el contrario, les conminaba a hacerlo bajo la amenaza del cadalso digital. Naturalmente hablamos del phishing.

Aunque tradicionalmente lo asociamos al fraude bancario, ni de lejos es exclusivo su uso para tales menesteres. Es más (y ahora nos ponemos de pie, arrastramos la silla hacia atrás y nos llevamos la palma de la mano al pecho), incluso nosotros mismos lo usamos en nuestras tribulaciones, cuando nos encargan un test de penetración (si, suena gracioso cuando no estás habituado a escuchar el término) y nos permiten usar ingeniería social.

El antiguo arte de engañar
Porque realmente, el mecanismo de funcionamiento de un phishing se basa en la ingeniería social. En el engaño, estafa, argucia, ardid, fraude, artimaña, señuelo, falsedad, confusión, burla, embuste, etc. (Tampoco vamos a engañaros en este punto, es evidente que hemos usado un diccionario de sinónimos). El arte del engaño es tan antiguo como su padre, el arte de codiciar lo ajeno. Estos dos nacen como respuesta a una pregunta que nace a su vez de la necesidad congénita del ser humano de simplificar y optimizar los procesos vitales: "¿Por qué esforzarme lo mismo que el otro si puedo enajenar lo que él tiene con menos esfuerzo?". Bendita economía.

Bien, pues ya que hemos instalado la idea de una mala decisión y construido el canal por el que queremos plasmar la concreción en un ejemplo, pasemos a ver qué defensas podemos levantar contra la toma de una pésima alternativa o un decálogo de medidas a tomar antes de pulsar un maldito enlace que nos lleve a la perdición en forma de ransomware o un derrame pecuniario en nuestros haberes bancarios.

1) Si no eres capaz de demostrar que no es un phishing, entonces ES UN PHISHING.

En Barrio Sésamo todos eran buenos
Me encantaba "Barrio Sésamo". Era un lugar donde el mal no tenía cabida. Todo era felicidad y buen rollo encantador. De hecho no veréis en ningún episodio a un personaje echando la llave a una puerta (¿Julián el del kiosco quizás?). Nadie era malo allí. ¿Cómo pensar mal de un puercoespín rosa de dos metros con la capacidad humana del habla y la movilidad óptica de un cenicero de bronce?

Al menos en lo que respecta a tus correos entrantes no habituales, piensa mal por defecto. Si ves un correo de tu banco. Demuéstrate a ti mismo que realmente viene de tu banco. Quizás te llamen paranoico pero siempre puedes responderles que cuenten con los dedos de una mano a cuantos paranoicos conocen que hayan sido timados. En la mayoría de los casos les sobraran cinco dedos. Seis o más en caso de padecer polidactilia. No falla.

Recuerda, el principio de inocencia no se aplica a los activos digitales. Es culpable por defecto, demuestra su inocencia. Esa es la actitud.

2) Lee el correo. En serio, lee el correo.

Lee el correo con alguien como él
Da igual el idioma que hables. Un correo verdadero y corporativo debería llegar con una perfección ortográfica y gramatical que cuando termines de leerlo llores de emoción o tu corazón palpite entregado a los placeres de la prosa.

Un truco que utilizo es leerlo con un señor como nuestro académico Pérez Reverte pero imaginario. Coges el texto del correo e imagina que el señor Pérez Reverte está sentado junto a ti leyendo el mismo correo. Cuando termines de leerlo (o terminéis) fíjate en su rostro y estate atento. Si se levanta, te da una palmadita en el hombro y se va, entonces el correo podría ser bueno. Si te lo imaginas agitado y desenvainando un sable del siglo dieciocho mientras brama improperios coetáneos del mismo con una tempestad de fondo. No falla. El correo tiene la validez equivalente a una promesa electoral. ES PHISHING.

3) Copia el enlace y compruébalo en sitios de reputación online.

Ten mucho cuidado al copiarlo. En serio, activar un enlace puede suponer que tu navegador se abra y se dirija a una fiesta organizada por un exploit kit. Así que deposita el cursor sobre el enlace lentamente, botón derecho, copiar y sepárate muy muy despacio de él. Poco a poco.

Ahora, con el enlace en el portapapeles, puedes comprobarlo en sitios web que van a decirte si la dirección está en una lista negra. Pero recuerda, y esta idea es importante: Estos sitios sólo demuestran que el enlace está en una lista negra. Es decir, si no aparece en la lista negra no significa que sea bueno, significa que no está incluido.

Recuerda. Estos sitios confirman una sospecha, no confirman una coartada.

¿Sitios? Hay muchísimos, unos pocos ejemplos.

Ya sabes. ¿Dominio en lista negra? ES PHISHING. ¿No está en lista negra? Entonces no está en lista negra.

4) Comprueba el dominio.

Suponemos que llegados a este paso, que has visto el correo y tu sentido común no te ha puesto en alerta. Lo has leído con tu imaginario escritor favorito a tu lado y le ha dado el visto bueno. Por último, el enlace no aparece en una lista negra. Bien, porque nos acercamos a una fase crítica. De la URL céntrate, de momento, en el dominio.

Pega la URL en tu editor de texto favorito. Disecciónala y quédate con el dominio. Hay lectores que tienen un nivel básico, no hay problema, todos tuvimos un primer día, el resto puede saltarse el ejemplo. Pongamos la URL de una "Una Al Día" cualquiera:


Comprueba el dominio
¿Veis las barras inclinadas a la derecha? Las /

Separan componentes. Parte la url en piezas tomando como referencia esas /

http:


2016

03

petya-un-nuevo-ransomware-que-impide-el.html

Eso que está en negrita es el dominio. Eso se transformará en una dirección IP a la que se irá nuestro navegador de manera transparente para traerte una página web. El problema es que tu navegador web es incapaz de decidir si lo que vas a visitar es la banca online o un servidor controlado por un atacante y preparado para filibustearte los dineros.

¿Cuál es el dominio de tu banco? ¿Adónde te diriges cuando vas a visitar el sitio web de tu banco?

Coge la URL que usas habitualmente de tu banco y haz lo mismo. Compara los dominios. ¿Son idénticos? ¿No? ES PHISHING.

Es cierto que los subdominios pueden variar:

Pero cuídate mucho de que la parte final, ese hispasec.com antes del primer punto sean iguales en ambos dominios. ¿No es así? ES PHISHING.

5) Comprueba el certificado SSL

Hubo un tiempo que el sinónimo de seguridad en la red era la presencia de un candadito amarillo en el navegador cuando visitabas un sitio "seguro". Cuánto daño ha hecho esa frase en el subconsciente de los usuarios proporcionando una falsa sensación de seguridad.

Hubo incluso malware, que una vez instalado en el sistema, le endiñaba un candado amarillo por defecto al navegador, con el simple cometido de despreocupar al usuario de lo que iba a pasar a continuación. Bajar la guardia y ¡bum!

El dichoso candadito amarillo
Un candadito amarillo solo significaba que la conexión iba "cifrada" y que el sitio tenía un certificado SSL. Punto. Ahora pensad un momento. ¿Qué detiene a cualquiera de comprar un dominio, extender un certificado sobre ese dominio y poner a la escucha un servidor que ofrezca un canal cifrado?

Hoy día puedes montar una infraestructura con un dominio, su certificado digital y un servidor con HTTPS establecido, de manera anónima y en menos tiempo del que llevas leyendo este artículo. Todo eso puede hacerse en cuestión de minutos e incluso de manera anónima, sin dejar rastro.

Una conexión segura lo único que te asegura es que el canal con el que te comunicas está cifrado y el certificado te dice que el dominio es de quien dice ser. Y eso lo podemos jurar siempre y cuando no salga un ataque criptográfico de última generación o a la certificadora de turno no le hayan trabuqueado un certificado raíz.

Así que el sitio web de tu banco tiene que presentar su dominio habitual, su certificado seguro, correcto, al día y asociado al dominio y una conexión cifrada de manera robusta. Si no es así, no hay duda: ES PHISHING.

Si el dominio es correcto, pero la conexión no es cifrada o el certificado no es válido entonces amigo, te están haciendo un hombre en el medio. Sal de ahí. Ya.

6) ES PHISHING

¡Templanza!
Este nivel requiere de una templanza propia de esos maestros sabios que aparecen en las películas de kung-fu de los 70 u 80.

El principio es muy sencillo. Da igual que el correo sea de tu banco o no. ES PHISHING. No se pincha en el enlace. No se visita ninguna URL. No se manda por fax ni correo ninguna documentación. No se contesta a ese correo. Ni se le hace caso.

Ya sabemos que puede sonar radical. Pero es tremendamente efectivo. Además te pone en una ventaja táctica. Usa una suerte de patrón Hollywood. Si quieren algo de ti y es importante, llámales tú a ellos. Ponte en contacto con tu banco a través de las líneas que tienen disponibles y coméntales lo que has recibido. Si es cierto te lo confirmarán y ya puestos arregla el marrón con ellos. Si es un phishing lo más probable es que hablando con ellos termines ayudando a otras personas desmontando el fraude cuanto antes.

Vosotros, nuestros lectores, tenéis un nivel de concienciación y técnico considerable. No todo el público posee ese nivel capaz de distinguir una estafa de una comunicación legítima. Incluso confesemos, hasta un ojo avezado y curtido en las amenazas puede ser engañado. Somos imperfectos.

Sin embargo el día a día avanza, las comunicaciones se tornan digitales y para bien de los árboles, el papel va siendo sustituido por un puñado de bits. No dejes que esos bits te estropeen un día o un mes o los ahorros de una década.

Esperamos que de una forma entretenida, con gotas de humor y unas pequeñas reglas, ayudemos a crear conciencia en usuarios menos entrenados, más confiados y por lo tanto más vulnerables.

Más información:

una-al-dia (03/06/2008) Mitos y leyendas: "Compruebe el candadito del navegador para estar seguro" I (Phishing)

una-al-dia (17/06/2008) Mitos y leyendas: "Compruebe el candadito del navegador para estar seguro" II (Troyanos)

una-al-dia (20/12/2004) Nueva técnica de "phishing" afecta a Internet Explorer

una-al-dia (12/07/2006) Troyanos bancarios y evolución del phishing


David García
Twitter: @dgn1729


lunes, 23 de febrero de 2015

Google por una navegación más segura

Google está dispuesta a mejorar la seguridad de los usuarios mientras navegan, para ello está implementando importantes medidas en su navegador Chrome, en Google Search y en sus anuncios para evitar que los usuarios descarguen malware o accedan a páginas de fraude on-line.

Google ha confirmado que recientemente ha realizado esfuerzos para mejorar la seguridad de Chrome, de las búsquedas, y de los anuncios para conseguir que sean más seguros ante las descargas de software malicioso.

Como principal novedad en Chrome, además de mostrar una advertencia antes de descargar el software no deseado, Chrome mostrará una nueva advertencia antes de visitar un sitio en el que se detecte algún tipo de malware. Esto es, incluso antes de cargar la página el usuario visualizará un aviso similar.

Un aviso suficiente alarmante ("El siguiente sitio contiene programas dañinos").

En la búsqueda de Google se incorporan señales para identificar sitios peligrosos. Este cambio está destinado a reducir las posibilidades de visitar páginas web maliciosas. De forma similar, la compañía confirma que está desactivando aquellos anuncios de Google que puedan dirigir a sitios con software no deseado.

Todas estas medidas se engloban dentro de la campaña "NavegaciónSegura" (SafeBrowsing) destinada a identificar los sitios web que no sean seguros e informar de ello a los usuarios y webmasters de modo que puedan protegerse frente a posibles peligros.

Google cifra en aproximadamente mil millones de personas los usuarios de la Navegación segura de Google. Pero no solo se centra en Chrome, sino que los usuarios de Google Chrome, Mozilla Firefox y Apple Safari también se benefician cuando intentan navegar a sitios web que podrían robar su información personal o instalar software diseñado para tomar el control de sus ordenadores. La compañía afirma descubrir miles de sitios no seguros nuevos, muchos de ellos sitios legítimos que se han puesto en peligro y muestra advertencias en la búsqueda de Google.

Más información:

More Protection from Unwanted Software

Conseguir que la Web sea un lugar más seguro


Antonio Ropero
Twitter: @aropero


viernes, 13 de febrero de 2015

Informe de Kaspersky sobre ciberamenazas financieras

El Laboratorio Kaspersky ha publicado un informe centrado en las ciberamenazasfinancieras registradas por sus sistemas durante el pasado año 2014.

El informe se divide claramente en los dos tipos de ataques principales de la actualidad, phishing y malware. Como aclaración hay que señalar que como ataques financieros se refieren a todos aquellos que tienen como objetivo un beneficio económico, en lo que incluyen ataques contra bancos, sistemas de pago y tiendas on-line.

Sorprendentemente según el informe de la compañía rusa la cantidad de ataques y de usuarios atacados disminuyó considerablemente, al igual que la cantidad de phishing bancario.

En 2014, los ataques de phishing financiero representaron el 28,73% de todos los ataques registrados (lo que significa un descenso del 2,72%). Concretamente el phishing bancario representó el 16,27% de todos los ataques (un descenso del 5,93% frete al 2013). Sin embargo, la cantidad de phishing lanzado contra sistemas de pagó aumentó en un 2,4% (de un 2,74% en 2013 a un 5,14% en 2014).

Por otra parte, el lo que se refiere al malware financiero durante el pasado año el laboratorio Kaspersky detectó 22,9 millones de ataques con programas maliciosos contra 2,7 millones de usuarios. Esto representa una disminución del 19,23% en comparación al año anterior respecto a los ataques, y del 29,77% respecto a los usuarios. Por otra parte, la cantidad de malware bancario aumentó en un 8,89%, alcanzando el 75,63% de todos los ataques financieros en 2014. Sin embargo, el mayor cambio se nota en los ataques relacionados con malware de minería para Bitcoin, que se triplicó; pasando de 360.065 ataques en 2013, a 1.204.987 en 2014.

Los investigadores de la firma rusa apuntan a varias razones para estos cambios tan notables. En primer lugar, el arresto de algunas de las principales bandas de delincuentes dedicados al fraude financiero. Por otra parte, apuntan a un cambio de tendencia de los atacantes, que en vez de atacar a usuarios finales, están apuntando a organizaciones que trabajan con información financiera y herramientas de pago.

Y por último, los técnicos de Kaspersky afirman que los ciberdelincuentes han dejado de interesarse por los ataques maliciosos “masivos" contra los usuarios, y prefieren lanzar menos ataques, pero más "dirigidos”. Esto es, los delincuentes se centran en un grupo concreto de usuarios (por ejemplo, los usuarios de un determinado banco, o una tienda concreta) en lugar de propagar correos masivos con enlaces maliciosos.

Más información:

Ciberamenazas financieras en 2014: las cosas han cambiado

Kaspersky Lab Report
Financial cyberthreats in 2014




Antonio Ropero
Twitter: @aropero

lunes, 14 de abril de 2014

Vulnerabilidad en Android facilita la realización de ataques de phishing

Investigadores de FireEye han descubierto una nueva vulnerabilidad en Android que podría permitir a una aplicación maliciosa con permisos normales modificar los iconos de la pantalla principal de Android y modificarlos para que apunten a sitios web de phishing o a la propia aplicación maliciosa sin notificarlo al usuario. Google ha reconocido el problema y ha liberado un parche a sus socios OEM, aunque posiblemente tarde en llegar a los usuarios.

Android Open Source Project (AOSP) clasifica los permisos en Android en varios niveles: "normal", "dangerous", "system", "signature" y " development". Los permisos normales se conceden automáticamente en la instalación, sin pedir aprobación explícita del usuario (aunque el usuario siempre puede revisar los permisos antes de instalar).

En la última versión de Android 4.4.2 si una aplicación solicita tanto permisos peligrosos como permisos normales, el sistema solo muestra los permisos peligrosos. Si una aplicación solo solicita permisos normales, Android no los muestra al usuario. Sin embargo, FireEye ha descubierto que determinados permisos de la categoría "normal" pueden tener impactos peligrosos en la seguridad. Mediante el uso de estos permisos una aplicación maliciosa puede modificar los icosos de la página principal de forma que lanzen aplicaciones o sitios web de phishing.

La aplicación maliciosa abusa del conjunto de permisos:
"com.android.launcher.permission.READ_SETTINGS" y "com.android.launcher.permission.WRITE_SETTINGS".
Estos dos permisos permiten a una aplicación consultar, insertar, eliminar o modificar todos los ajustes de la configuración del "Launcher" (lanzador), incluyendo la modificación e inserción de iconos. Estos dos permisos están etiquetados como "normal" desde la primera versión de Android.

Como prueba de concepto desarrollaron una aplicación que hacía uso de estos dos permisos para modificar iconos legítimos de algunas aplicaciones sensibles para redirigirlas a otros sitios web. Con lo que confirmaron el problema en un Nexus 7 con Android 4.4.2. Google Play no evitó que la aplicación fuera publicada y no se mostró ningún aviso al usuario al descargarla e instalarla. Tras las pruebas, eliminaron tanto las webs empleadas como la aplicación de Google Play. Por lo que nadie ha podido verse afectado.

FireEye también confirma que la vulnerabilidad no está limitada a dispositivos Android que ejecuten AOSP. También se ven afectados otros dispositivos con Launchers no-AOSP incluyendo Nexus 7 con CyanogenMod 4.4.2, Samsung Galaxy S4 con Android 4.3 y HTC One con Android 4.4.2.

Google ha reconocido la vulnerabilidad y ha distribuido un parche a sus sociosOEM. Sin embargo, tal y como ya avisan en FireEye muchos fabricantes que hacen uso de Android son lentos a la hora de adaptar las actualizaciones de seguridad. Al igual que FireEye, nos unimos a la petición de que estos fabricantes solucionen las vulnerabilidades de forma más eficiente para proteger a los usuarios.

Más información:

Occupy Your Icons Silently on Android

App Manifest/<permission>


Antonio Ropero
Twitter: @aropero