Qué hacer si Android no reconoce tu clave de Google

 

En ocasiones podemos encontrarnos en la situación de que Android no reconoce tu clave de Google, con lo que quedan deshabilitados los servicios relacionados con la gran G y entonces empezamos a pensar que ¡tenemos un problema!
Sin embargo, puesto que se trata de un problema que bastantes usuario se han encontrado, aquí os incluimos un tutorial para solucionar este problema y volver a tener acceso a los servicios de Google desde nuestro Android.

Cuando Android no reconoce tu clave porque no es tu clave

Puede parecer absurdo, pero no sería la primera vez
que el motivo por el que un usuario no puede acceder a su cuenta de
Google es porque la clave no es la que pensaba. Esto puede ocurrir incluso porque nos han pirateado la cuenta y alguien ha cambiado la clave.
Si nos planteamos buscar ayuda en la documentación oficial de Android sobre ello, encontraremos lo siguiente en la página de ayuda de Android.
Esta página nos sugiere tanto restablecer el dispositivo de fábrica
(¡esperad a terminar el artículo antes de hacer ese paso!) como acceder a
la página de Ayuda de Google para resolver este tipo de conflictos con nuestra cuenta:
En ella, podremos especificar cuál puede ser el origen
de nuestro problema e intentar solucionarlo. Así que éste debe ser
nuestro primer intento.

Cuando Android no reconoce tu clave, pero sólo en determinadas apps

Superado el paso anterior, si el problema persiste, debemos plantearnos la siguiente pregunta:

¿Nos ocurre para cualquier tipo de servicio de Google? ¿O sólo con una app determinada, como Gmail?

Si la respuesta es que nos ocurre sólo en alguna app determinada como Gmail, pero la cuenta ya está añadida a nuestro dispositivo, deberíamos intentar descargar una app cualquiera desde Google Play, para forzar a dejar un registro sobre la cuenta que hemos utilizado.

Si tras este paso el problema persiste, deberíamos intentar borrar los registros de la cuenta con los siguientes pasos:
  1. Borrar todos los datos de la aplicación que falla
  2. Borrar todos los datos de la aplicación Google Play
A continuación, bastará con volver a intentar
descargar una app de Google Play y sincronizar después la aplicación (en
nuestro ejemplo, Gmail).

Cuando Android no reconoce tu clave por culpa de la verificación en dos pasos

Si el problema persiste aún, quizá sea debido a cómo tenemos configurada la cuenta de Google, en la cual seguramente tendremos activa la verificación en dos pasos, y es ésta la que nos impide llegar a acceder a nuestra cuenta desde el dispositivo.
Para ello bastaría con acceder a la siguiente web, la
cual os solicitará vuestra clave aunque ya estéis conectados (si lo
hacéis desde otro dispositivo en el que sí tenéis acceso):
Si al acceder a esta web obtenemos un error como el
que a continuación os mostramos, entonces el motivo es que no tenéis
activa la verificación en dos pasos, y estos pasos no funcionarán en tu
caso.
Si por el contrario, sí que la tienes activa, os mostrará una lista con las contraseñas de aplicación
o ninguna si aún no tenemos. En nuestro caso vamos a proceder a generar
una clave nueva, para lo que tendremos que irnos al botón desplegable Seleccionar aplicación y seleccionar la opción Otra (nombre personalizado), introduciendo un nombre libre (en mi caso, Nexus 5):
Al hacer click en Generar, nos saldrá un mensaje con la clave que deberemos utilizar en nuestro dispositivo móvil, pero teniendo en cuenta que es una clave de un solo uso y que los espacios no hay que introducirlos:
Utilizando esta clave en nuestro dispositivo ya no
deberíamos tener problemas. Además, en cualquier momento podemos revocar
la clave si así lo deseásemos:
A partir de ahí, si el problema persiste, entonces sí
que te sugerimos o que restaures el dispositivo de fábrica o que
intentes conectarlos a través de otro dispositivo diferente para ver si
el problema persiste.

via Blogger http://ift.tt/2jk4YdC

Cuando un virus informático puede matarte, literalmente

http://ift.tt/2jj4X9d 

 

Cada día hay más cacharros conectados a internet. Y ya no estamos hablando sólo cámaras y lavadoras, sino que numerosos dispositivos médicos también empiezan a estar conectados a la red como una forma de monitorizar y mejorar la atención sanitaria.

Pero un marcapasos o una bomba de insulina no es un electrodoméstico. Los problemas de seguridad informática que hace unos meses tumbaron internet,
en un caso de estos pueden tumbar una vida. O al menos, comprometerla
seriamente. ¿Qué pasa con la seguridad de los dispositivos médicos? ¿Estamos dejando olvidado un punto central de la medicina del futuro?

Un argumento a medio camino entre un thriller y una película de ciencia ficción

Dna 163466 1280
No es difícil imaginar argumentos de película: Cuando recibió aquel correo electrónico, Woodruff Walton
no se lo podía creer. “Hemos tomado el control de su bomba de insulina,
si no transfiere ahora mismo 20.000 euros a este número de cuenta, le
provocaremos un shock hipoglucémico y morirá. Lo estamos observando, no
intente nada raro”. No había mucha gente que supiera que Walton tenía
una bomba de insulina. Sus familiares cercanos, sus médicos y algunos
otros pacientes diabéticos de un grupo de ayuda. ¿Qué broma macabra era
esa? ¿Cómo alguien podía intentar algo así? ¿Cómo alguien puede, en remoto, decidir jugar con la vida de otra persona?

Y, no creáis, no es ciencia ficción del todo. En 2011, Jay Radcliffe, experto en seguridad informática y diabético, programó un sistema capaz de controlar una bomba de insulina ajena. Un par de años más tarde, Jack Barnaby lo hizo con un marcapasos. De hecho, no hace falta que sea una red de fraude y extorsión.

Un simple virus informático podría afectar seriamente
a algunos tipos de dispositivos. Cosas como crear arritmias, parar un
respirador en una unidad de cuidados intensivos o producir fallos
sistémicos cuando, por fin, tengamos órganos robóticos útiles y
conectados.

decía Suzanne Schwartz,
directora adjunta de la FDA: “veremos adelantos tecnológicos
significativos en este campo de la atención al paciente, pero, al mismo
tiempo, un aumento en el riesgo de violaciones de ciberseguridad que podrían afectar al rendimiento y la funcionalidad de un dispositivo”,
 

Hay que empezar a hablar de seguridad

Este es un tema crucial. Esta semana la misma FDA, la agencia estadounidense que supervisa estos dispositivos, ponía el foco en la seguridad informática de estos dispositivos y acaba de aprobar unas nuevas directrices sobre ciberseguridad médica.

Ya en 2014 prepararon unas directrices, pero, como se demostró en el caso del Centro Médico Presbiteriano de Hollywood a principios de año, entrar en la red de un hospital y secuestrarlo no es algo muy difícil. En los últimos años, unos 160 hospitales de Estados Unidos han sido víctimas de ciberataques de distinto tipo.

Como coinciden todos los expertos,
el futuro de la medicina pasa por la integración del conocimiento
científico-médico, la conectividad y la inteligencia artificial. Pero si
no ponemos en el centro a la ciberseguridad estaremos violando el primer gran mandamiento de la medicina: ‘primun non nocere‘, primero no hacer daño. Este debería ser uno de los grandes temas de 2017.

FUENTE: Xataka

via Blogger http://ift.tt/2ijEgx9

El fraude publicitario “más grande hasta la fecha”: páginas falsas y una botnet para robar 180 millones de dólares

http://ift.tt/2hF6ySi

Cada vez escuchamos más acerca de los problemas de seguridad relacionados con los datos digitales, el ejemplo más claro es del Yahoo y sus más de 1.500 millones de cuentas robadas. Otro ejemplo es aquel ataque DDoS
que tiró algunos servicios por varias horas, el cual estuvo relacionado
con la nula seguridad que existe en algunos dispositivos del Internet
de las Cosas.

Hoy White Ops, empresa de investigación en seguridad, está dando a conocer algunos detalles de la que es considerada “la operación de fraude publicitario digital más grande y rentable hasta la fecha”. Un fraude que se llevó a cabo gracias una sofisticada red de bots rusos que pasó desapercibida por más de dos meses, lo que significó pérdidas por más de 180 millones de dólares.

Pérdidas por más de 180 millones de dólares

Esta botnet fue desarrollada por el grupo de hackers rusos ‘Ad Fraud
Komanda’ o AFK13. Este avanzado sistema automatizado es conocido como Methbot,
y su tarea consistía en consumir anuncios, principalmente de vídeo, y
así hacer que los anunciantes tuvieran que pagar por publicidad digital
entre 3 y 5 millones de dólares diarios.

Para que esto diera resultado, los hackers crearon una firma de
publicidad ficticia donde ofrecían a grandes compañías hospedar sus
anuncios en sitios como ESPN, CBS Sports, Vogue, Fox News, entre otros.
Para lograr esto, montaron páginas web ficticias que al final nadie
visitaba, por lo que tuvieron usar entre 800 y 1.200 servidores dedicados ubicados en los Estados Unidos y Holanda.
Methbot
Una vez montado el numerito, era momento de activar a Methbot. El ejercito de bots se repartió en 571.904 direcciones IP
asignadas a proveedores como Verizon, Comcast y otros ISPs con sede en
Estados Unidos. Estos bots estaban programados para ver los anuncios
montados en las webs falsas, y así los hackers podían cobrar a los
anunciantes.

La verdadera magia de todo esto es que cada bot fue programado para
que los algoritmos detectores de fraudes no saltaran, es decir, cada bot
estaba activo sólo durante el día, simulaba estar usando Chrome en un
Mac, e incluso tenía perfil en Facebook. Con esto, nunca levantaron
sospechas y las estadísticas mostraban lo que parecía ser personas reales.
La clave estaba en que cada bot veía entre dos y tres vídeos diarios,
además de que también simulaban las acciones de un usuario, como
movimientos y clics del ratón, o inicios de sesión falsos en redes
sociales.
Bot
White Ops calcula que AFK13 acumulaba 300 millones de impresiones
diarios, obteniendo unas ganancias entre 3 y 5 millones de dólares. Una
operación que se mantuvo en secreto por más de dos meses, donde los
anunciantes estuvieron pagando por anuncios que nunca llegaron a un ojo humano.
Esta operación se coloca como el mayor esquema de fraude jamas
realizado, una operación que aún tiene incógnitas como el proceso que
llevaron a cabo para realizar los cobros, o cómo lograron contratar los
servidores para operar de forma ilícita, todo sin que nadie se diera
cuenta.
Más información | White Ops

via Blogger http://ift.tt/2hpe0F6

La gran inseguridad del Internet de las cosas, la culpable del ataque DDoS que noqueó la web

http://ift.tt/2dT8qHK
 
Si en estos días trataste de acceder a Twitter, Netflix o
Spotify, entre otros servicios, lo más probable es que hayas tenido
dificultades: desde páginas que cargan lento o sin imágenes hasta
servicios que directamente no funcionaban. No, no es un fallo de tu
operador, como explicábamos, sino que se trataba de un ataque DDoS masivo contra Dyn, un importante proveedor de DNS que daba servicio a clientes potentes como los que mencionábamos al principio.
Todavía no se tienen muchos detalles sobre este
ataque, que aún se está investigando (incluso por el FBI). Sin embargo,
la firma de seguridad Flashpoint asegura conocer qué dispositivos están
detrás del mismo: un “ejército” de cámaras IP y dispositivos grabadores
infectados con un malware que permite a los atacantes controlarlos
remotamente y dirigir tráfico sin parar hacia un objetivo (en este caso,
Dyn). Sí, los dispositivos IoT se están convirtiendo en el arma preferida de los que organizan DDoS a nivel global.
http://ift.tt/2dT8Z4g
Ejemplos de componentes que vende Xiongmai Technology
 
En concreto, Flashpoint apunta
al fabricante chino XiongMai Technology, que hace componentes que luego
vende a otros fabricantes. Entre los productos afectados se encuentran,
principalmente y según dichos investigadores, cámaras IP y dispositivos de grabación de vídeo (DVRs). Si bien no se refieren a ningún fabricante concreto, Dyn también ha confirmado que “una gran parte” del tráfico del ataque procede de dispositivos IoT, algo que también asegura Level3.
También se usaron cámaras IP y
dispositivos grabadores en DDoS contra KrebsOnSecurity.com y contra OVH
en septiembre, generando tráfico récord para este tipo de ataques




No se puede decir que esto sea una novedad: también dispositivos similares fueron utilizados en uno de los ataque DDoS más importantes que se recuerda:
620 Gbps de tráfico contra el sitio web de un popular investigador de
seguridad informática en septiembre de este año. OVH sufrió un ataque
DDoS similar el mes pasado, que alcanzó 1Tbps según la compañía francesa
y que por ahora parece tener el dudoso honor de ser el mayor DDoS
registrado de la historia. Adivinad quién estaba detrás: más de 145.000 cámaras IP y dispositivos grabadores.

Un “ejército” de dispositivos IoT

¿Por qué usar dispositivos IoT en los ataques? La
respuesta es sencilla: los hay de muchos tipos, son más fáciles de
infectar que otros dispositivos más avanzados, funcionan durante todo el
día (a fin de cuentas, nadie apaga sus cámaras de seguridad, ¿no?) y, a
día de hoy, los fabricantes suelen descuidar bastante su seguridad.


Existe una herramienta, de nombre Mirai, que permite
escanear Internet en busca de dispositivos desprotegidos o que utilizan
las claves que el fabricante impone por defecto en sus productos, los infecta y permite controlarlos a distancia para coordinar ataques. El código fuente de esta herramienta se hizo público a comienzos de este mes. Si queréis leer más sobre ella, os recomiendo este análisis de Level3.
http://ift.tt/2eNRLTp
Estructura de una botnet “Mirai” Foto por: Foto. Level3
Una de estas “Mirai botnet”, como se les conoce en la industria, participó en el ataque de 620Gbps que os comentábamos antes y también, según Level3, se utilizó en el ataque a Dyn. No es el único software con fines similares: el propio Brian Krebs hablaba de Bashlight, que opera de forma similar y se filtró el año pasado.

¿Quién está detrás de estos ataques? Ésa es la parte
más difícil de responder, ya que desconocemos si se trata de un mismo
grupo o persona o, al ser estas herramientas públicas,
puede tratarse de grupos distintos que aprovechan que cualquiera puede
conseguir el software para realizar sus propios DDoS a la carta.

Fuente: Xataka

via Blogger http://ift.tt/2eNQtbg

Google lleva 4 años protegiéndote del fallo que afecta a 900 millones de Android

Seguramente has oído en los últimos días algo relacionado con QuadRooter. Dicho nombre hace referencia a una nueva vulnerabilidad en Android que afecta, ni más ni menos, que al 90% de los terminales con el sistema operativo de Google. QuadRooter se refiere a cuatro fallos que se encuentran en los smartphones con procesadores Qualcomm que permiten conseguir acceso root de forma remota
y hacerle cualquier barbaridad a nuestros dispositivos, pero
tranquilos, que Google nos vigila las espaldas con la función “Verificar
aplicaciones”.


A diferencia de Stagefright, QuadRooter se tiene que camuflar en una aplicación.
Es decir, debemos habilitar los “Orígenes desconocidos” e instalar una
aplicación manualmente para que esta vulnerabilidad pueda hacernos algún
daño. Sin embargo, la función “Verificar aplicaciones” que se incluye
en los Servicios de Google Play –y que está habilitada por defecto en
todos los terminales con Android 4.2 Jelly Bean o superior– nos protege contra esto.
De acuerdo a unas declaraciones por parte de un vocal de Google a Android Central, la función “Verificar aplicaciones” es capaz de detectar y bloquear las aplicaciones infectadas:


Apreciamos la investigación de Check Point, ya que nos ayuda a mejorar la seguridad de nuestro ecosistema móvil. Los dispositivos Android que tienen nuestro parche de seguridad más reciente ya están protegidos contra tres de las cuatro vulnerabilidades. La cuarta, CVE-2016-5340, será añadida en el próximo boletín de seguridad Android, de tal forma que los colaboradores de Android puedan emprender acciones usando el parche público que Qualcomm ha publicado. La explotación de este problema depende de los usuarios que descarguen e instalen aplicaciones maliciosas. “Verificar aplicaciones” y SafetyNet ayudan a identificar, bloquear y eliminar las aplicaciones que explotan estas vulnerabilidades – Vocal de Google a Android Central.


Mientras que algunos dispositivos aun son técnicamente vulnerables, incluso con “Verificar aplicaciones”, los usuarios tendrán que desactivar manualmente otra medida de seguridad más para ser afectados.
Las aplicaciones que usan QuadRooter no podrán instalarse, puesto que
nos saldría un aviso de “La instalación ha sido bloqueada”, y este mensaje no tiene opción para ignorar, lo que significa que es “casi imposible” instalar dicha app.
Si tieness un teléfono de antes de 2010 con Android Gingerbread –si es que eso sigue existiendo–, debes de tener dos cosas para estar protegidos:
1) tener los Servicios de Google Play actualizados a la última versión y
2) activar manualmente la función “Verificar aplicaciones” en la
aplicación Ajustes de Google. QuadRooter era exactamente el tipo de amenaza que Google vio venir cuando implementó “Verificar aplicaciones” y lo activó por defecto en 2012.

Como vemos, estamos “completamente” a salvo. Ya sabes que no hace faltan ningún antivirus en Android, puesto que la mejor defensa es el sentido común.
No instales nada de cuyos orígenes no sean seguros, puesto que es ahí
cuando la seguridad de tu dispositivo se verá realmente comprometida. Estamos
protegidos por defecto, pero si buscamos la forma de instalar algo que
no debemos instalar, seguramente la encontremos, y ahí Google no tiene
nada que hacer.
FUENTE: andro4all

via Blogger http://ift.tt/2bjFZQr

Quadrooter, la vulnerabilidad grave que afecta a millones de móviles Qualcomm

 

Con la de millones de dispositivos que se venden cada
año con Android, y la cantidad de personas que utilizan este sistema a
diario, la seguridad siempre debe considerarse. Sin llegar a los
extremos de la paranoia, pero sí tomando conciencia de qué hacemos con el móvil y cómo lo hacemos. ¿Eres
de los que instala apps fuera de la Google Play Store pero vigila en
todo momento los permisos? Tampoco estás libre de riesgos.
Quadrooter es una vulnerabilidad seria que afecta a dispositivos con chips de Qualcomm.
Permite a un atacante tomar el control total del sistema sin que el
usuario deba otorgarle permisos, algo que convierte a Quadrooter en un
problema grave para los más de 900 millones de dispositivos que se
estima son vulnerables. Si tienes un Qualcomm, seguramente estés en la
lista.

El código de Qualcomm posee vulnerabilidades en el escalado de privilegios

Por más que Google vigile el código de Android para
lanzar las puntuales actualizaciones de seguridad, esto no significa que
los dispositivos actualizados sean 100 % seguros. El fabricante del procesador central también aporta su propio código a los dispositivos que equipan sus chips. Éste es el caso de Qualcomm, que acumula diversas vulnerabilidades en el escalado de privilegios.

Los procesadores de Qualcomm poseen cuatro vulnerabilidades en el escalado de privilegios

Según se encargó de demostrar Adam Donenfeld en la conferencia Def Con celebrada el pasado domingo,
resulta posible ejecutar código de kernel y ganar privilegios ROOT
en dispositivos equipados con multi procesadores de Qualcomm. El
principal problema es que estas vulnerabilidades no requieren de permisos especiales, por lo que una simple app instalada por el usuario bastaría para obtener control absoluto de su dispositivo.

Siempre hacemos especial hincapié en vigilar los
permisos de aquellas aplicaciones que instalamos, pero esto dejaría de
tener sentido si la app en cuestión está capacitada para aprovechar las
vulnerabilidades Quadrooter. Aunque eso sí: minimizaríamos el riesgo instalando desde desarrolladores fiables y desde la Google Play Store.

Quadrooter ha sido corregido por Qualcomm, pero la corrección no ha llegado a todos los dispositivos

Qualcomm asegura que corrigió las vulnerabilidades
distribuyendo el nuevo código a usuarios y fabricantes entre abril y
julio del 2016. Google ya lanzó tres de las correcciones en sus actualizaciones de seguridad;
pero quedaría por corregir la cuarta al no llegar a tiempo el parche
para agosto (la actualización de septiembre corregiría la situación por
completo, al menos en Nexus).


Qualcomm ya corrigió las vulnerabilidades; pero las correcciones no llegaron a los dispositivos


Historia aparte merece el resto de fabricantes, ya
sabemos cómo aplican las distintas actualizaciones de seguridad. Samsung
es de los que más empeño ponen en el asunto, así como BlackBerry, por
ejemplo. Aun así, sus dispositivos Qualcomm siguen siendo vulnerables; al menos en parte.

¿Quieres comprobar si tu móvil es propenso a
Quadrooter? A día de hoy, y siempre que tu móvil sea Qualcomm, la
respuesta es un “sí”. Pero como hay aplicación para todo, Check Point
Software tiene a punto la suya para comprobarlo en un momento y con
total seguridad.

Más información ZDNet

via Blogger http://ift.tt/2aToUOQ

Google libera el parche de seguridad de julio, que resuelve más de 100 errores

http://ift.tt/2a9qmdy

 

Google ha liberado ya, para sus dispositivos Nexus, el parche de seguridad de julio, el cual resuelve la friolera de más de 100 errores,
varios de los cuales tenían que ver con los componentes del propio
sistema operativo y controladores de algunos fabricantes de
procesadores, aunque su objetivo principal es la parte del sistema que
maneja el flujo del sonido y el vídeo.

En cuanto a esta parte, el parche soluciona 16 vulnerabilidades, de las que al menos 7 son críticas,
que podrían usarse para obtener privilegios avanzados. Otra
vulnerabilidad tratada es la que tiene que ver con las bibliotecas
OpenSSL y BoringSSL. Google ha tenido que dividir en dos partes esta
actualización debido a la enorme cantidad de errores abordados.

Una de las partes está dedicada a la que afecta a todos los dispositivos Android,
mientras que la otra se centraría en dispositivos con unos chips en
concreto. La primera parte tiene resuelve un total de 32
vulnerabilidades, de las que 8 serían críticas. Esta actualización tiene
como fecha el 1 de julio.

La otra parte, con fecha del 5 de julio, resuelve 75 vulnerabilidades de terminales con chips de Qualcomm, MediaTek y Nvidia.
Google ya notificó hace un mes a los fabricantes que podían preparar su
propio parche para liberarlo a sus respectios terminales, mientras la
gran G lo liberó para sus dispositivos.


Vía | Talk Android

Más información | Android


En Xataka Android | Desde ahora, LG también publica sus boletines de seguridad, al igual que Google y Samsung

via Blogger http://ift.tt/2a9qeuP