El HTC U11 Life ya está disponible desde el viernes 3 de noviembre en los Estados Unidos por $ 349, este modelo estará disponible de forma exclusiva para el carrier T-Mobile, aunque es posible comprar un modelo desbloqueado directamente desde HTC y usarlo con la red de AT&T.
HTC también ofrece una versión de Android One del teléfono con un software Android bastante próximo a un Android puro, pero esa versión solo está disponible en Alemania por el momento. Google dice que se introducirá dicha versión a más países europeos y la región de Asia Pacífico en los próximos meses.
El U11 Life ofrece una pantalla LCD FHD (1080×1920) de 5,2 pulgadas, procesador Snapdragon 630, almacenamiento interno de 32GB (con una ranura SD), la RAM es de 3GB, cámara trasera es de 16MP, la cámara frontal también es de 16MP, la batería es al parecer un poco limitada 2600mAh. Ofrece también un sensor de huellas dactilares en la parte frontal y la clasificación de resistencia al agua es IP67. La versión de Android que trae es la 7.1 (Nougat).
Aquí les dejo las especificaciones conpleta del smartphone:
HTC U11 Life
OS
Android 7.1 Nougat
HTC Sense
Display
5.2″ Super LCD Full HD (1080 x 1920)
Corning Gorilla Glass
El día de hoy en el blog 9to5Mac, se daba a conocer que el iPhone 8 es el peor en ventas de los últimos años para la empresa de la manzana, esto es lo que se puede leer en dicho blog:
Los datos de compra provistos por el Consumer Intelligence Research Partners (CIRP) sugieren que el iPhone 8 se está vendiendo en menor cantidad que un modelo ‘S’.
La compañía dice que el iPhone 8 / Plus representó solo el 16% de todas las ventas de iPhone en el último trimestre, frente al 24% del iPhone 6S / Plus …
Dijo que los modelos “tic” del iPhone solían representar más del 40% de las ventas, incluso el iPhone 7, que representaba una iteración de diseño relativamente pequeña en su predecesor.
Parte de la razón de esto es que los fans de Apple están esperando el iPhone X y otros sugieren la poca diferenciación del iPhone 8 con respecto al iPhone 7.
Para hacer fácil la comparación estamos pegando el gráfico de CIRP que muestra la distribución de las ventas de iPhone por año desde el 2015:
Un grupo de investigadores han revelardo los detalles de una nueva clase de vulnerabilidad de canal lateral de ejecución especulativa en los procesadores Intel que afecta a todos los chips modernos, incluidos los chips utilizados en los dispositivos Apple.
Después del descubrimiento de las vulnerabilidades Spectre y Meltdown, que afectan a los procesadores Intel a principios del año pasado que pusieron en riesgo prácticamente a todas las computadoras del mundo, surgieron una y otra vez diferentes variaciones de dichas vulnerabilidades.
Ahora, un equipo de investigadores de seguridad de varias universidades y empresas de seguridad han descubierto vulnerabilidades de canal lateral de ejecución especulativa diferentes pero más peligrosas en las CPU de Intel.
Un grupo de investigadores han revelardo los detalles de una nueva clase de vulnerabilidad de canal lateral de ejecución especulativa en los procesadores Intel que afecta a todos los chips modernos, incluidos los chips utilizados en los dispositivos Apple.
Después del descubrimiento de las vulnerabilidades Spectre y Meltdown, que afectan a los procesadores Intel a principios del año pasado que pusieron en riesgo prácticamente a todas las computadoras del mundo, surgieron una y otra vez diferentes variaciones de dichas vulnerabilidades.
Ahora, un equipo de investigadores de seguridad de varias universidades y empresas de seguridad han descubierto vulnerabilidades de canal lateral de ejecución especulativa diferentes pero más peligrosas en las CPU de Intel.
Hay un viejo dicho español: “Nadie sabe para quien tabaja“, que refleja la incertidumbre de que ninguno de nosotros podemos estar seguros de quien se beneficiará por nuestro esfuerzo. Con clásicos ejemplos como el responsable y sacrificado padre que vive frugalmente para dejar un gran patrimonio a sus hijos, quienes al recibirlo lo despilfarran e incluso los bienes con tanto esfuero acumulados terminan en manos de los enemigos de quién se los ganó con empeño y sacrificio.
Pues, bien ese refrán lo podemos aplicar a lo sucedido con Coinhive, un proyecto de criptominería en el navegador que pretendía ofrecer una alternativa a la odiosa publicidad que vemos en infinitas páginas web. La idea propuesta por Coinhive es simple, intalar un script de Javascript en una página web y remover la publicidad de la misma, de esa forma en lugar de obtener financiamiento por poner anuncios en el contenido producido, se obteniene el pago a través de la capacidad de cómputo de la computadora del visitante.
La idea es atractiva y algunos generadores de contenido estaban comenzado a probarla de forma experimental para evaluar su viabilidad, pero el lunes pasado, la empresa oficialmente reconoció que había sido hackeada y que a través de los DNS de la misma, hackers habrían robado el producto de lo minado.
La historia es como sigue de acuerdo a ZDNet:
El proveedor de software de minería de criptomonedas dijo esta semana que aproximadamente a las 10 pm GMT del lunes, la firma recibió una nota de su proveedor de DNS, Cloudflare, que advirtió a Coinhive que un agente desconocido había accedido a su cuenta.
Los registros DNS de coinhive.com se han manipulado para redirigir las solicitudes de coinhive.min.js a un servidor de terceros, que contiene una versión modificada del archivo JavaScript con una clave de sitio codificada.
El código Javascript de Coinhive que es incrustado por los usuarios en sus sitios web como una forma de extraer la criptomoneda Monero, pero los atacantes pudieron secuestrar esta secuencia de comandos para garantizar que los fondos extraídos ingresaran en una billetera que controlaran ellos en lugar de billeteras de los usuarios.
“Esto esencialmente permite que el atacante” robe “hashes de nuestros usuarios”, dice Coinhive.
La secuencia de comandos utilizada para implementar la minería de criptomonedas en los dominios de sitios web es una idea nueva, aunque controvertida.
La minería para moneda virtual se está examinando como una alternativa a los anuncios de terceros como una forma de generar ingresos, y fue la prueba piloto de Pirate Bay la que propulsó la idea al centro de atención.
Debido a un error de codificación, los usuarios detectaron el minado del sitio web, ya que extraía enormes cantidades de energía de la CPU de los sistemas visitantes, en lugar de 20 a 30 por ciento como se pretendía originalmente.
Tras la reacción de los visitantes, The Pirate Bay admitió haber probado el script de minado como una “forma de deshacerse de todos los anuncios”.
Lo peor de todo es que la forma cómo este hacker tomo control de la cuenta de Cloudflare de Coinhive es de un robo de información ocurrido en el 2014, lo cual indica que por aproximandamente 3 años la empresa estuvo usando las mismas credenciales a pesar de saber que estas habían sido comprometidas:
Parece que las credenciales de la cuenta Cloudflare pueden haberse filtrado en la violación de datos de Kickstarter.
En 2014, los hackers pudieron acceder a algunas cuentas y robar nombres de usuarios de clientes, direcciones de correo electrónico, direcciones de correo, números de teléfono y contraseñas encriptadas.
Dado que las contraseñas tomadas fueron encriptadas, es posible que la contraseña de Cloudflare de Coinhive fuera particularmente débil y susceptible a un ataque de fuerza bruta.
La compañía, sin embargo, ha sido honesta en reconocer dónde radica la verdadera culpa.
“Hemos aprendido lecciones duras sobre seguridad y usamos 2FA y contraseñas únicas con todos los servicios desde entonces, pero olvidamos actualizar nuestra cuenta Cloudflare de años atrás”, dice Coinhive. “Sentimos mucho este severo descuido”.
Lamentable revés para una compañía que ofrecía una alternativa real a la monetización a través de la odiosa publicidad. Aunque este hacking no ha sido debido a la calidad de su código o una falla de la implementación o la idea, sino por el contrario a la laxa política de seguridad en el manejo de contraseñas de la empresa, esperemos que luego de este grave problema la empresa pueda sobrevivir y continuar con el desarrollo de su idea.
Una de las razones por las que los proveedores de servicios de Internet (ISP) o hackers pueden espiar tus comunicaciones si usas el protocol HTTPS, es por dos factores claves. El primero es la encriptación que oculta de forma irreversible el intercambio de información con el servidor web, y la segunda, es la autenticación del servidor web en sí mismo.
Pero, ¿acaso sabías? que los ISP pueden ver todas sus solicitudes a servidores DNS, lo que les permite saber qué sitios web visitas y además los hackers pueden implementar ataques de Man in the Middle a servidores DNS y dirigirte a sitios web fraudulentos.
Google está trabajando en una nueva característica de seguridad para su sistema operativo Android que podría evitar que el tráfico de Internet de los usuarios de su sistema operativo sea objeto de ataques de suplantación, redirección de tráfico o que simplemente sean espiados.
Casi todas las actividades de Internet comienzan con una consulta a un servidor DNS, lo que convierte a este protocolo en un componente fundamental de Internet. El DNS funciona como una guía telefónica de Internet, su misión es convertir las direcciones web legibles por el ser humano, como el nombre de dominio www.consejerodigital.com, en una dirección IP que es comprensible por la computadora.
Las consultas y respuestas a los servidores DNS se envían en texto plano (usando ya sea el protocolo UDP o TCP), lo que lo hace vulnerable a las escuchas ilegales y compromete la privacidad de los usuarios.
Los ISP resuelven por defecto las consultas DNS desde sus servidores. Entonces, cuando ingresas el nombre de un sitio web en tu navegador, la consulta va primero a sus servidores DNS para encontrar la dirección IP del sitio web, que finalmente expone esta información (metadatos) a tus ISP.
Aunque ya existen extensiones de seguridad para DNS, conocidas como DNSSEC, solo ofrecen integridad de datos, no privacidad.
Para tratar de resolver este problema, el Grupo de Trabajo de Ingeniería de Internet (IETF, por sus siglas en inglés) propuso el año pasado una característica experimental llamada DNS sobre TLS (RFC 7858), que funciona aproximadamente de la misma manera en que lo hace el protocolo HTTPS.
Al igual que el protocolo de encriptación Transport Layer Security (TLS) protege las conexiones HTTPS criptográficamente, DNS-over-TLS mejora dramáticamente la privacidad y la seguridad con búsquedas de DNS autenticadas de extremo a extremo.
Se ha informado en un post del blog XDAdevelopers, que Google agregará soporte “DNS over TLS” al Proyecto de Código Abierto de Android (AOSP), actualmente en una etapa experimental, para permitir a los usuarios de smartphones activar o desactivar la función “DNS over TLS” en la Configuración de Opciones de Desarrollador.
Es importante resaltar lo que agraga ese post al final como adendum referente a que no existe una formula mágica para proteger el tráfico del usuario:
Tenga en cuenta que TLS over DNS no dará lugar a la privacidad total con solo presionar un botón. Si un proveedor de servicios de DNS diferente al que decide conectarse opta por habilitar DNS over TLS, obtendrán su tráfico de DNS en lugar de su ISP. Las solicitudes de DNS se cifrarán, pero el servidor DNS sobre el protocolo TLS aún puede ver su tráfico de DNS, aunque eso solo podría ser un paso más arriba al usar los servidores de su ISP sin TLS over DNS. Al menos de esta manera, su ISP no podrá adjuntar sus consultas a la IP que le han asignado, y por lo tanto su nombre.
El handshake entre los servidores a través de la Indicación del nombre del servidor (SNI) que permite que se establezca una conexión aún puede ser visto por su ISP (y pueden registrarlo a su nombre). Para esconderte completamente, necesitarás una VPN para enrutar las consultas DNS, que de lo contrario tu ISP puede ver, a un servidor DNS over TLS. Mientras confíe en su proveedor de VPN, ahora debería estar más oculto que nunca en Android. Por lo tanto, aunque esta característica no le permite ser completamente anónimo en virtud de tener un DNS over TLS, sí le permite ocultar las solicitudes DNS de los ISP, y ocultar las solicitudes y el tráfico si está dispuesto a agregar algo extra de trabajo.
Aún no sabemos la fecha exacta de cuándo esta características estará disponible, pero es muy probable en que una próxima version Android 8.x la tengamos presente.
En el portal de noticias tecnológicas ArsTechnica, da cuenta de que la base de datos del Sistema de Tracking de Propiedades y Evidencias no tiene copias respaldo (back-up) y que si ocurre un ataque informático, los datos se corrompen o por alguna razón las computadoras que lo contienen queda fuera de servicio la información se perdería.
Así nos presenta la noticia ArsTechnica:
Como parte de una batalla legal en curso para lograr que el Departamento de Policía de la Ciudad de Nueva York rastreara el dinero que la policía ha tomado en efectivo, un fiscal de la ciudad le dijo a un juez de Manhattan el 17 de octubre que parte de la razón por la que el NYPD no puede cumplir con tales solicitudes es que la base de datos de evidencias del departamento no tiene copia de seguridad. Si los servidores de dicha bases de datos que potencian el Sistema de Seguimiento de la Propiedad y Evidencias [PETS, por sus siglas en inglés] del NYPD, diseñados e instalados por Capgemini en virtud de un contrato de U.S.$ 25,5 millones entre el 2009 y 2012, fallarían, todos los datos sobre la evidencia almacenada, simplemente dejarían de existir.
Esto que parece digno de un país en vías de desarrollo está pasando actualmente con uno de los departamentos de policía con más presupuesto en el mundo, en una de las ciudades que ha abrazado con más entusiasmo la automatización de procesos y la modernización de toda la infraestructura pública.
Entonces, si la implementación del sistema costó $25,5 millones, por qué no hay un sistema de back-up, o uno que permita analizar o auditar los datos. Pues al parecer porque la consultora que lo creo, Capgemini, olvidó ese pequeño detalle según las autoridades:
Cuando se activó en 2012, Capgemini hizo alarde de PETS [Property and Evidence Tracking System], que se construyó utilizando la plataforma de software de planificación de recursos empresariales (ERP) de SAP, así como las bases de datos IBM DB2, como un proyecto del sector público emblemático. La compañía fue tan lejos que llegó a presentar PETS como un proyecto nominado para los premios Computerworld Honors 2012. Pero aparentemente el sistema fue diseñado sin ningún esquema para hacer una copia de seguridad de la base de datos o cualquier tipo de almacén de datos para realizar análisis de los mismos.
Fue esto hecho a propósito, pues al parecer si. Ya que el fiscal actualmente cuestiona el paradero de más de U.S. $68 millones confiscados por el Departamento de Policía de la Ciudad de Nueva York:
El reclamo fue clave para la negativa del departamento de policía a proporcionar la contabilidad de datos por aproximadamente U.S.$ 6 millones incautados en efectivo y propiedad cada año. Desde el año 2013, de acuerdo con el grupo sin fines de lucro Bronx Defenders, el NYPD tenía un balance de más de $ 68 millones en efectivo incautado.
Lo que me parece increíble siendo un residente de la Ciudad de New York, es que esto no haya trascendido a los medios de comunicación (televisión y periódicos) de la ciudad y sea por los medios especializados en tecnología que nos enteremos de esta grave negligencia que puede afectar negativamente las posibilidades de reelección del actual alcalde de la ciudad Bill De Blasio. Aunque técnicamente el sistema entró en funcionamiento en la gestión anterior, es increíble como se haya permitido que la situación continúe hasta el día de hoy.
Como diría el refrán “en todas partes se cuecen habas”.
En un reciente artículo publicado por ArsTechnica, se informa que el nuevo smartphones de Google, el Pixel 2, incluye dentro del SoC una Unidead de Procesamiento de Imágenes, que debería ser activada cuándo el Android 8.1 sea liberado.
ArsTechnica dice lo siguiente:
El smartphone más nuevo de Google, el Pixel 2, está a punto de agotarse. La compañía ha estado hablando del gran juego que puede ofrecer la cámara de los Pixel 2 y llamándolo, de forma enfática, “la mejor cámara para smartphones”. Pero Google ha mantenido en secreto lo que oculata el Pixel 2 tiene un SoC (System On a Chip) personalizado diseñado por Google y dedicado exclusivamente al procesamiento de imágenes de la cámara. El SoC todavía no está activo, pero Google afirma que hará que las fotos que procese el Pixel 2 sean más rápidas y más eficientes que nunca.
Además del habitual Qualcomm Snapdragon 835 SoC, el Pixel 2 está equipado con el “Pixel Visual Core“, un segundo SoC extra que ha sido diseñado por Google con el procesamiento de imágenes acelerado por hardware en mente. En el corazón del chip hay una Unidad de procesamiento de imágenes (IPU Image Processesing Unit) de ocho núcleos capaz de más de tres billones de operaciones por segundo. Usando estos núcleos de IPU, Google dice que el procesamiento de imágenes HDR+ de la compañía puede ejecutarse “5 veces más rápido y a con menos de 1/10 de consumo de batería” que lo que actualmente hace la CPU principal.
Lo que sorprende a todos es que Google no haya mencionado el asunto para nada hasta ahora. Incluso cuándo tuvo la oportunidad durante la presentación de los Pixel el pasado 4 de octubre, no dijo ni una palabra sobre el tema. Sólo queda esperar a los reviews del portal web iFixIt, que abre todos los dispositivos y será alli dónde podremos confirmar si es que hay algo oculto en el nuevo Pixel 2.
¿Crees que tu red inalámbrica es segura porque estás usando la última tecnología de cifrado WPA2?
Si es así, tenemos muy malas noticias para tí.
Los investigadores de seguridad han descubierto varias vulnerabilidades en la administración de claves en el núcleo del protocolo WPA2 (Wi-Fi Protected Access II) que podría permitir a un atacante piratear tu red Wi-Fi y escuchar todas las comunicaciones por Internet. En total son 10 la vulnerabilidades hechas públicas el día de hoy:
CVE-2017-13077, Reinstalación de la clave de encriptación pairwise (PTK-TK) en el handshake de cuatro vias.
CVE-2017-13078, Reinstalación de la llave de grupo (GTK) en el handshake de cuatro vias.
CVE-2017-13079, Reinstalación de la clave del grupo de integridad (IGTK) en el handshake de cuatro vias
CVE-2017-13080, Reinstalación de la clave de grupo (GTK) en el handshake de la clave del grupo
CVE-2017-13081, Reinstalación de la clave del grupo de integridad (IGTK) en el handshake de la clave del grupo
CVE-2017-13082, Aceptación de una solicitud de reasociación rápida de transición BSS (FT) retransmitida y reinstalación de la clave de cifrado por parejas (PTK-TK) mientras la procesa.
CVE-2017-13084, Reinstalación de la clave STK en el handshake PeerKey
CVE-2017-13086, Reinstalación de la clave de configuración de enlace directo Tunneled (TDLS) PeerKey (TPK) en el handshake TDLS
CVE-2017-13087, Reinstalación de la clave de grupo (GTK) mientras se procesa un marco de respuesta de modo de suspensión de gestión de red inalámbrica (WNM).
CVE-2017-13088, Reinstalación de la clave de grupo de integridad (IGTK) al procesar un marco de respuesta de modo de suspensión de gestión de red inalámbrica (WNM).
WPA2 es un esquema de autenticación WiFi que ya tiene 13 años y es ampliamente utilizado para garantizar conexiones Wi-Fi seguras, pero el estándar se ha visto comprometido, afectando a casi todos los dispositivos Wi-Fi, incluso en nuestros hogares y negocios, junto con las compañías de redes que los construyen.
Apodado KRACK (Key Reinstallation Attack), el ataque de prueba de concepto demostrado por un equipo de investigadores funciona en contra de todas las redes Wi-Fi modernas protegidas por WPA2 y puede ser abusado para robar información confidencial como números de tarjetas de crédito, contraseñas, mensajes de chat, correos electrónicos y fotos
Dado que las debilidades residen en el estándar Wi-Fi en sí, y no en las implementaciones o cualquier producto individual, es probable que se vea afectada cualquier implementación correcta de WPA2.
Según los investigadores, el ataque recién descubierto funciona en contra de:
Los protocolos WPA1 y WPA2,
Las redes personales y empresariales,
Encriptación WPA-TKIP, AES-CCMP y GCMP
En resumen, si su dispositivo admite Wi-Fi, lo más probable es que se vea afectado. Durante su investigación inicial, los investigadores descubrieron que Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys y otros, se ven afectados por los ataques KRACK.
Cabe señalar que el ataque KRACK no ayuda a los atacantes a obtener la contraseña de su red Wi-Fi; en su lugar, les permite desencriptar los datos de los usuarios WiFi sin desencriptar o conocer la contraseña real. Por lo tanto, simplemente cambiar la contraseña de su red Wi-Fi no impide (o atenúa) el ataque KRACK.
Aquí un video sobre cómo es que funciona el ataque:
Descubierto por la investigadora Mathy Vanhoef de la empresa belga de seguridad imec-DistriNet, KU Leuven, el ataque KRACK funciona explotando el handshake de 4 vías del protocolo WPA2 que se utiliza para establecer una clave para cifrar el tráfico entre el dispositivo y el access point.
Para un ataque KRACK exitoso, un atacante debe engañar a una víctima para que vuelva a instalar una clave ya en uso, lo que se logra manipulando y reproduciendo mensajes criptográficos de comunicación.
El documento que describe la vulnerabilidad, titulado Key Reinstallation Attacks: Forcing Nonce Reuse en WPA2, ha sido publicada por Mathy Vanhoef de KU Leuven y Frank Piessens de imec-DistriNet, Nitesh Saxena y Maliheh Shirvanian de la Universidad de Alabama en Birmingham, Yong Li de Huawei Technologies y Sven Schäge de Ruhr-Universität Bochum.
Los investigadores descubrieron las vulnerabilidades el año pasado, pero enviaron las notificaciones a varios vendedores el 14 de julio de este año, a la vez que notificaron al US-CERT (United States Computer Emergency Readiness Team), que envió una advertencia a cientos de proveedores el 28 de agosto.
Para solucionar estas vulnerabilidades, se debe esperar las actualizaciones de firmware de los fabricantes de routers y todo tipo de dispositivo que haga uso de WPA2.
Según los investigadores, la comunicación a través de HTTPS es segura, pero no al 100% y por lo tanto no podría descifrarse utilizando el ataque KRACK. Pero para estar más seguros, se recomienda utilizar un servicio VPN, que encripte todo el tráfico de Internet, ya sea este HTTPS o HTTP, esto obviamente reducirá su velocidad de conexión, pero le garantizará la privacidad mínima que se debe usar para operaciones comunes.
El equipo de investigadores prometió lanzar una herramienta mediante la cual puede verificar si su red WiFi es vulnerable al ataque KRACK o no.
Hasta el momento el único patch disponible es para el sistema operativo Linux en sus servicios hostapd (el daemon de punto de acceso del host) y WPA Supplicant.
Los investigadores de seguridad de la empresa ESET, fabricante de software de seguridad con sede en Eslovaquia, descubrieron un nuevo ransomware de Android que no solo encripta los datos de los usuarios, sino que también no permite el acceso de los usuarios a sus dispositivos porque cambia el PIN de bloque de la pantalla. Esta nueva amenaza se llama DoubleLocker.
Además de lo anterior, DoubleLocker es el primer ransomware que hace un mal uso de las características de accesibilidad de Android, una característica que ofrece a los usuarios formas alternativas de interactuar con sus dispositivos móviles y que los troyanos bancarios de Android abusan principalmente de robar credenciales.
Los investigadores creen que el ransomware de DoubleLocker podría actualizarse en el futuro para robar credenciales bancarias, además de simplemente extorsionar dinero como rescate de los datos del smartphone.
Aquí un video creado por ESET dónde explica cómo opera este nuevo ransomware:
Una vez ejecutado, DoubleLocker primero cambia el PIN del dispositivo a un valor aleatorio que ninguno de los atacantes conoce ni almacena en ninguna parte y, mientras tanto, el malware encripta todos los archivos usando el algoritmo de encriptación AES.
DoubleLocker ransomware exige 0.0130 BTC (aproximadamente USD 74.38 al momento de la redacción) y presiona a las víctimas para pagar el rescate dentro de las siguientes 24 horas.
Si se paga el rescate, el atacante proporciona la clave de descifrado para desbloquear los archivos y restablece de forma remota el PIN para desbloquear el dispositivo de la víctima.
¿Cómo podemos protegernos de el ransomware DoubleLocker?
Según los investigadores de ESET, hasta ahora no hay manera de desbloquear archivos cifrados por DoubleLocker, sin embargo, para los dispositivos no rooteados, los usuarios pueden restablecer de fábrica su teléfono para desbloquear el teléfono y eliminar el ransomware de DoubleLocker.
Sin embargo, para los dispositivos Android rooteados con el modo de depuración habilitado, los usuarios afectados por DoubleLocker pueden usar la herramienta de desarrollo ADB (Android Debug Bridge) para restablecer el PIN sin necesidad de formatear su smartphone.
Sin embargo, la mejor manera de protegerse de DoubleLocker y evitar caer víctimas de este tipo de ataques de ransomware es descargar siempre aplicaciones de fuentes confiables, como Google Play Store, Amazon Store, etc. y sólo instalar Apps de desarrolladores verificados.
Además, nunca haga click en los enlaces provistos en SMS o correos electrónicos. Incluso si el correo electrónico parece legítimo o ha sido enviado por un amigo. En lugar de hacer click en el enlace vaya directamente al sitio web de origen y verifique las posibles actualizaciones.
Lo más importante, mantenga una buena aplicación antivirus en su smartphone que pueda detectar y bloquear dichos ataques de malware antes de que pueda infectar su dispositivo. Siempre mantenga actualizado smartphone.
