Friday, 2 October 2015

Datos de 15 millones de clientes de T-Mobile robados por la brecha en Experian

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/hacking-incidentes/datos-de-15-millones-de-clientes-de-t-mobile-robados-por-la-brecha-en-experian/
TAGS: T-Mobile

Experian, compañía que analiza datos crediticios y provee servicios de información financiera, sufrió una intrusión a sus sistemas que, como efecto secundario, resultó en el robo de datos personales de 15 millones de clientes de T-Mobile. Los afectados fueron aquellos que solicitaron contratos de telefonía entre marzo de 2013 y la actualidad.


John Legere, CEO de T-Mobile, publicó una carta en la que se propuso ser “directo, transparente y honesto”, explicando:




[caption id="attachment_6612" align="alignnone" width="623"]Datos de 15 millones de clientes de T-Mobile robados por la brecha en Experian Datos de 15 millones de clientes de T-Mobile robados por la brecha en Experian[/caption]

Hemos sido notificados por Experian, un proveedor que procesa solicitudes de crédito, que ellos han experimentado una intrusión de datos. La investigación se está llevando a cabo aún, pero lo que sabemos hasta ahora es que el hacker adquirió aproximadamente 15 millones de archivos de personas que requerían una verificación de crédito cuando solicitaban un nuevo servicio o financiamiento de un equipo entre el 1 de septiembre de 2013 y el 16 de septiembre de 2015.


Los datos robados incluyen:



  • Nombre

  • Dirección

  • Fecha de nacimiento

  • Número de seguro social

  • Número de identificación/licencia de conducir/pasaporte

  • Información adicional usada en la evaluación de crédito de T-Mobile

Preocupado y “sumamente molesto” por el acontecimiento, Legere aseguró estar trabajando para asistir a los consumidores afectados, y remarcó: “Ni la red de T-Mobile ni nuestros sistemas fueron parte de esta intrusión, que no incluye números de tarjetas registradas para pagos o información de cuentas bancarias”.


Es alarmante que aunque los números de identificación y de seguro social estaban cifrados, los atacantes pudieron hacerse de ellos.


Como resarcimiento, las víctimas pueden aplicar a dos años de servicio de monitoreo de créditogratuito, y al servicio de restauración de identidad que ofrece Experian. Además, T-Mobile publicó un listado de preguntas frecuentes sobre este incidente, explicando por qué Experian tenía acceso a los datos de sus clientes, las medidas que se tomaron y van a tomar, y por qué no se puede solicitar la eliminación de los datos de la base de la empresa.


¿Y qué dijo Experian?


En su propio informe del hecho, Experian explicó que el 15 de septiembre advirtió un acceso no autorizado a información de clientes de T-Mobile alojada en uno de sus servidores. Rápidamente notificó a la compañía y a las autoridades, y emprendió los avisos a los individuos afectados.


Entre las medidas tomadas para remediar el incidente nombró:



  • Evaluación y remoción de cualquier presencia de malware o conectividad inadecuada

  • Evaluación de los procedimientos de aislamiento del servidor afectado y los sistemas asociados

  • Compromiso con EE.UU. y la policía internacional

  • Una mayor supervisión de los servidores afectados y sistemas asociados

De seguro, los clientes afectados que hayan solicitado un contrato de T-Mobile en el período especificado podrían aplicar estos consejos para evitar el robo de identidad.


Fuente:http://www.welivesecurity.com/


Noticias de seguridad informática

UN NUEVO STAGEFRIGHT 2.0 AMENAZA LA SEGURIDAD DE LOS USUARIOS DE ANDROID

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/seguridad-informatica/un-nuevo-stagefright-2-0-amenaza-la-seguridad-de-los-usuarios-de-android/
TAGS: Stagefright
Esta nueva vulnerabilidad permitiría a los atacantes ejecutar código malicioso en los dispositivos afectados, debido a la presencia de dos bugs que son desplegados cuando se procesan archivos MP3 y Mp4 especialmente diseñados para comenzar el ataque.

De acuerdo con el informe de Zimperium, “la vulnerabilidad recae en el procesamiento de los metadatos dentro de los archivos, así que incluso previsualizar la canción o el video (infectado) podría desencadenar el asunto. Debido a que la vía de ataque primario por MMS fue removida en las más recientes versiones de las aplicaciones de Google Hangouts y Google Messenger, la forma más probable de recibir el ataque podría ser el navegador web”



¿Cómo podrías ser víctima de un ataque que aproveche la vulnerabilidad StageFright 2.0?


[caption id="attachment_6600" align="alignnone" width="600"]Usuario precavido vale por dos. Usuario precavido vale por dos.[/caption]

La vulnerabilidad StageFright 2.0 reside en dos librerías llamadas ‘libutils’ y ‘libstagefright’, que tienen que ver con el procesamiento de archivos multimedia. La primera se encuentra presente en cualquier Android desde 1.0 en adelante, y lo preocupante es que incluso los equipos más nuevos podrían estar comprometidos, dependiendo de qué aplicaciones de terceros y la configuración de fábrica de cada dispositivo. De acuerdo con Zimperium, existen tres escenarios muy probables para ser víctima de un ataque:


1. El atacante trataría de convencerte de visitar una dirección web específica donde se aloja el archivo perjudicial.
2. Un atacante que se encuentre en la misma red tuya podría inyectar el ‘exploit’ por medio de técnicas comunes de interceptación de tráfico (ataques ‘man in the middle’) para el tráfico de red sin cifrar que llega al navegador.
3. Por medio de aplicaciones de terceros como reproductores multimedia o de mensajería instantánea que usen la librería vulnerable.


De acuerdo con la nota de Ars Technica, Google se pro


nunció frente al tema y afirma que esta nueva ola de bugs de Stagefright será arreglada con una actualización que será lanzada la próxima semana. Es decir, que una vez esta sea liberada, pasarán algunos días hasta que llegue a los equipos Nexus, que la próxima semana ya podrán actualizarse a Android 6.0 Marshmallow, y se demorará un poco más en llegar a los equipos de los demás fabricantes.


No sobra recordar que la primera puerta de entrada a los atacantes a nuestros equipos somos los usuarios, y por eso es importante tener medidas básicas de seguridad como no instalar aplicaciones de terceros si no confiamos en la fuente de donde provienen, así como ser precavidos a la hora de pulsar en enlaces o publicidad.



Fuente:enter.co


Noticias de seguridad informática

Thursday, 1 October 2015

Así es como una persona compró Google.com por sólo 12 dólares

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/hacking-incidentes/asi-es-como-una-persona-compro-google-com-por-solo-12-dolares/
TAGS: 12 dólares, google.com

En una de esas historias que hasta parecen broma, un hombre fue dueño por unos minutos de una de las direcciones de internet más famosas del mundo, "google.com", que además adquirió por sólo 12 dólares.


La historia, más que una anécdota curiosa, se trata de un grave problema de seguridad de la compañía, porque además, la compra del dominio se realizó a través de Google Domains, el servicio creado por la compañía para la compra de direcciones, quien nunca se percató que su propio dominio estaba a la venta en su propio servicio. ¡Increíble!.



Si vas a vender dominios, primero verifica que no esté el tuyo


Para buena suerte de Google, la persona que descubrió este error fue un ex empleado de la compañía, Sanmay Ved, quien relata toda la historia en su perfil en LinkedIn, explica con capturas y detalles, el procedimiento que lo llevo a ser dueño de google.com por unos minutos.


Todo surgió un día jugando en Google Domains, cuando se le ocurrió verificar la URL "google.com", la que sorpresivamente estaba disponible y con un valor de 12 de dólares. Pensó que se trataba de algún error en la plataforma y como cualquier otra persona, decidió añadirla a su carro de compras y efectuar el pago.




Los 12 dólares fueron cargados a su tarjeta de crédito y recibió dos notificaciones, una por parte del banco y otra por parte de Google, que le confirmaban la transacción. La dirección ya aparecía dentro de su panel de control, junto a las notificaciones del estatus del domino, lo que confirmaba que era el nuevo y flamante dueño de la dirección más popular en varias regiones del mundo.




Por supuesto se trataba de un error, y Google tardó unos 5 minutos en reaccionar, pero no lo hizo aceptando el error, no, simplemente le envió un correo a Sanjay donde le decían quehabía un error en su transacción y no podían procesar su reciente compra de dominio, y en ese momento le reembolsaron sus 12 dólares.



Por supuesto Google resolvió el problema de una forma (algo) rápida y sin muchas complicaciones, pero repito, esto se debe a que Sanmay Ved trabajó para Google entre 2007 y 2012, así que además de descubrir el fallo, dio aviso a la compañía. Después de esto, los dominios con Google ya no están disponibles para su compra, bueno, casi todos, ya que si buscamos "google-idiots.com" ésta aún está disponible por 12 dólares.



Un caso similar se presentó en 2003, cuando Microsoft olvidó renovar su dominio "hotmail.co.uk", que estuvo alojado en Nominet UK, así que al estar libre, una persona lo adquirió y Microsoft no pudo hacer nada al respecto, ya que la compañía no les pertenecía.


Fuente: http://magnet.xataka.com/


Noticias de seguridad informática

Vulnerabilidad en WhatsApp: falsificación de mensajes manipulando la base de datos

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/vulnerabilidades/vulnerabilidad-en-whatsapp-falsificacion-de-mensajes-manipulando-la-base-de-datos/
TAGS: WhatsApp

WhatsApp es la aplicación de mensajería instantánea más utilizada del mundo. Más de setecientos millones de usuarios en todo el planeta (la décima parte de toda la Humanidad), la utiliza para intercambiar mensajes de texto y de voz, ficheros de audio y de vídeo, etc. El hecho de que sea una aplicación universalmente utilizada, implica también que muchas personas, involucradas en procesos judiciales, presenten los mensajes de WhatsApp como prueba si quieren demostrar que una conversación, en unos términos concretos, ha tenido lugar entre determinados interlocutores.


Existe ya jurisprudencia en España en la admisión como prueba de mensajes de WhatsApp, como por ejemplo en la Sentencia de la Audiencia Provincial de Alicante Número 4/2014, de 9 de enero, en el ámbito civil, o la Sentencia de la Audiencia Provincial de Madrid Número 533/2014, de 24 de julio, en el ámbito penal. También han sido rechazados, como por ejemplo en la Sentencia de la Audiencia Provincial de Madrid Número 51/2013 de 23 de septiembre, por entenderse que, según transcripción textual de la sentencia, los “contenidos no han sido reconocidos por el acusado, ni se ha practicado sobre los mismos prueba pericial informática que acredite su autenticidad y su envío”, lo cual quiere decir que, si la otra parte no reconoce el envío de los mensajes, se deberá presentar un peritaje informático que avale la autenticidad de los mismos. Además, recientemente se ha fallado por el Tribunal Supremo en la STS 2047/2015 que, en general, para la admisión como prueba de cualquier conversación mantenida a través de una red social, es necesaria la presentación de un informe pericial informático por parte de un perito informático.


Que actualmente ya se estén admitiendo como pruebas los mensajes enviados y recibidos a través de WhatsApp, otorga una dimensión extraordinaria a esta aplicación, de tal forma que debe tenerse en cuenta la posibilidad de que los mensajes puedan ser manipulados, no sólo a la hora de realizar el envío del propio mensaje, como ya fue demostrado por dos ingenieros informáticos españoles, sino también una vez los mensajes han sido enviados o recibidos, es decir, directamente sobre la base de datos en la que se almacenan los mismos. Éste es el archivo sobre el que debe practicarse la prueba pericial informática cuando se presentan los mensajes de WhatsApp en un procedimiento judicial, por lo que es de vital importancia que dicho fichero permanezca íntegro o, al menos que, si se manipula maliciosamente, esta alteración pueda ser advertida tras un análisis forense por parte de un perito informático. Lo que se pretende demostrar en el presente artículo, es que dicho archivo de base de datos puede ser manipulado, alterando las conversaciones de tal forma que la manipulación podría perfectamente pasar inadvertida para un perito informático que realizase una investigación forense sobre el terminal móvil.


En primer lugar, se procederá a un intercambio de mensajes de WhatsApp (los que luego serán manipulados), entre dos terminales móviles cuya versión de WhatsApp instalada es la 2.12.250 en ambos. Estos terminales son un Samsung Galaxy S6 y un Wiko Goa, cuyo sistema operativo en ambos casos es Android, versión 5.1.1 y 4.4.2, respectivamente. Así pues, a continuación, se muestran los mensajes enviados y recibidos a modo de ejemplo entre ambos terminales.


hoy


Seguidamente, se ha de indicar que la base de datos interna de WhatsApp utiliza SQLite como Sistema Gestor de Base de Datos, por lo que se trata, por tanto, de un sistema relacional. Asimismo, una copia de esta base de datos, se encuentra fácilmente accesible conectando el terminal móvil al ordenador, estando ésta cifrada mediante criptografía simétrica utilizando el algoritmo AES, cuyo funcionamiento puede observarse en el siguiente diagrama.


texto


Como se puede apreciar, la clave de cifrado y descifrado es la misma. Esto equivale a decir que la misma clave se utiliza para cifrar y para descifrar la base de datos, estando ésta almacenada y accesible en el directorio que utiliza WhatsApp. Sin embargo, la base de datos original, es decir, la que es utilizada por la aplicación para almacenar los mensajes inmediatamente después de ser enviados o recibidos, no está cifrada, sino que se encuentra almacenada en texto claro en uno de los directorios que la aplicación tiene en el sistema operativo. Esta base de datos no es accesible conectando directamente el terminal al ordenador, pero sí lo es una vez el terminal Android ha sido rooteado, es decir, configurado para ser accedido en modo súper-usuario, lo cual es algo muy sencillo de realizar incluso para usuarios no expertos.


Así pues, una vez el móvil ha sido rooteado (para este ejemplo, se usará el Wiko Goa), tener acceso a la base de datos original es una operación muy sencilla. Para ello, usando la utilidad ADB para Windows de las herramientas de desarrollo de Android, es necesario ejecutar los siguientes comandos al objeto de abrir una sesión con el terminal (primeramente es necesario haber instalado correctamente las herramientas de desarrollo de Android y los drivers del dispositivo móvil del cual se desea obtener su base de datos de WhatsApp, así como haber activado el “modo de depuración USB” en el citado terminal Android):


C:\android-sdk-windows\platform-tools>adb devices
C:\android-sdk-windows\platform-tools>adb shell


Una vez se han ejecutado estos dos comandos, la utilidad ADB abre una sesión con el terminal móvil, tal y como se observa en la siguiente imagen.


shell


Es necesario indicar que, como servidor de ADB en el dispositivo móvil, es posible que sea necesario instalar y ejecutar una aplicación comoADB Insecure, más conocido como ADBD, al objeto de que se pueda transferir información entre el móvil y Windows y viceversa. Esto es así debido a que ciertas características de la utilidad ADB de serie no pueden ser utilizadas en versiones estables, es decir, finales, de Android, sino únicamente en versiones de desarrollo.


A continuación, es necesario acceder en modo súper-usuario al terminal, ya que la base de datos original de WhatsApp se encuentra en un directorio que sólo puede ser visualizado con privilegios de administrador. Para ello, es necesario ejecutar el comando “su”, tal y como se aprecia en la siguiente imagen.


shell_


Siendo ya súper-usuario, es necesario moverse al directorio en el que se encuentra la base de datos original de WhatsApp, ejecutando el siguiente comando:


# cd /data/data/com.whatsapp/databases


Al ejecutar un listado de los ficheros presentes en dicho directorio, mediante el comando “ls -la”, se aprecian los siguientes archivos:


Shell adb


Como se puede observar, el fichero que interesa es el remarcado en rojo. Ésta es la base de datos original de WhatsApp en la que se almacenan los mensajes inmediatamente después de ser enviados o recibidos. Una vez se ha visualizado el archivo que interesa, es necesario ejecutar el comando “exit” dos veces para volver a Windows, ya que será desde allí desde donde se tomará el archivo de base de datos de WhatsApp.


Ya en Windows, es necesario ejecutar el siguiente comando, al objeto de traer a Windows la base de datos (aunque es necesario, previamente, para disponer de todos los mensajes, incluyendo los enviados y recibidos en último lugar, haber realizado una copia de seguridad de los mensajes desde la propia aplicación WhatsApp, en el menú Ajustes -> Chats y llamadas -> Guardar chats):


C:\android-sdk-windows\platform-tools>adb pull /data/data/com.whatsapp/databases/msgstore.db


La ejecución exitosa del comando presenta la siguiente información en la consola:


del sistema



La siguiente captura de pantalla del directorio de Windows en el que se encuentra la utilidad ADB, muestra que en dicha carpeta ha sido depositado el fichero “msgstore.db” (seleccionado en la imagen):


tipo


Para abrir el mencionado fichero de base de datos, será necesario un cliente de SQLite, habiendo sido seleccionado para este ejemplo el cliente de código abierto SQLiteStudio. Así pues, es necesario abrir el programa y, posteriormente, navegar hasta el menú Database -> Add a database, al objeto de añadir una nueva base de datos, por lo que se deberá buscar y seleccionar el archivo de base de datos que se desea alterar, en este caso “msgstore.db”, localizado en el directorio en el que se encuentra la utilidad ADB. Una vez añadida la base de datos, ésta aparece en SQLiteStudio como se aprecia en la siguiente imagen (remarcada en rojo).


sql_


Seguidamente, es necesario conectarse a la base de datos. Para ello, con la base de datos seleccionada, hay que navegar hasta el menúDatabase -> Connect to the database, de tal forma que el cliente se conecta inmediatamente a la base de datos. Desplegando la base de datos, se puede observar que ésta está conformada por once tablas, tal y como se observa en la siguiente imagen.


null


De todas estas tablas, las que interesan son las siguientes:



  • messages, que almacena los mensajes enviados y recibidos, así como varias propiedades de los mismos.

  • messages_fts_content, que almacena los mensajes enviados y recibidos sin ninguna propiedad, únicamente con la misma clave primariaque en la tabla messages.

Para modificar un mensaje enviado o recibido es tan sencillo como realizar los siguientes pasos:


En primer lugar, es necesario conocer la clave primaria del mensaje que se desea modificar. Para ello, lo más óptimo es ejecutar una consulta de búsqueda por el patrón del mensaje en el propio cliente de SQLite. Así pues, para modificar el mensaje del ejemplo, se ejecutará la siguiente consulta, que proporcionará todos aquellos mensajes donde aparece la palabra “whatsapp”, de tal forma que pueda tomarse el identificador del mensaje que se desea modificar:select * from messages where data LIKE “%whatsapp%”;


La ejecución de la consulta se aprecia en la siguiente imagen, en la que únicamente se han devuelto dos registros, debido a que la palabra “whatsapp” sólo aparece dos veces en todos los mensajes (se ha remarcado en rojo, asimismo, el botón del cliente de SQLite con el cual se puede acceder al editor de SQL).

sql__

Ampliando la imagen sobre los mensajes, remarcados en rojo, se ve claramente que se trata de los mensajes recibidos desde el Samsung Galaxy S6 en el Wiko Goa:


data_



El mensaje que se va a modificar va a ser el que tiene como clave 7934. Por tanto, es necesario anotar dicha clave y, acto seguido, editar el campo data de la tabla messages, directamente desde el propio resultado devuelto por la consulta, escribiendo lo que interese, para inmediatamente después pulsar en el botón commit al objeto de persistir los cambios realizados. En la siguiente imagen se muestra el registro ya modificado y persistido tras haber pulsado el botón commit (el cual se halla remarcado en rojo).


data 1


La nueva frase, como se puede observar, es “WhatsApp es una aplicación segura. No hay nada que temer sobre ella.” Nótese que la anterior frase era “WhatsApp es una aplicación insegura.”

Posteriormente, es necesario editar la tabla messages_fts_content, para lo cual hay que dirigirse al árbol de tablas, pinchar con el botón derecho en la misma y seleccionar la opción Edit the table. Una vez en el editor, es necesario aplicar un filtro (remarcado en rojo y usando la clave, 7934), al objeto de encontrar el registro deseado, tal y como se aprecia en la siguiente imagen.

7934

Una vez se ha localizado al registro, es necesario proceder a cambiar el texto. A continuación, se muestra una imagen con el registro modificado y persistido, procurando mantener el estilo de la citada tabla (todo el texto en minúsculas, las palabras separadas por tres espacios y los signos de puntuación separados de la palabra anterior por un espacio):


7934_


En realidad, la modificación de esta tabla no sería estrictamente necesaria para que en la aplicación se viesen los mensajes alterados como si fuesen auténticos, pero sí es necesario si se quiere dificultar el trabajo del perito informático que vaya a analizar los mensajes y dictaminar si realmente fueron enviados y/o recibidos, es decir, si son auténticos.


Una vez realizados todos los pasos anteriores, es necesario seleccionar con el botón derecho del ratón la base de datos en SQLiteStudio y ejecutar la opción Disconnect from the database, para acto seguido salir del programa. Posteriormente, se debe copiar la base de datos alterada en el teléfono, sustituyendo la original. Para ello, es necesario ejecutar el siguiente comando en la consola de Windows (como se mencionó anteriormente, la aplicación ADB Insecure debe encontrarse en ejecución en el móvil):


C:\android-sdk-windows\platform-tools>adb push msgstore.db /data/data/com.whatsapp/databases/msgstore.db


La ejecución exitosa de este comando presenta la siguiente salida por pantalla:


sistema_


Para dejar el menor rastro posible de la manipulación, es necesario modificar tanto el propietario como el grupo del fichero de base de datos, que al haberlo copiado como root, es decir, como súper-usuario, tendrá tanto este propietario como este grupo. Para apreciarlo, se debe navegar hasta el directorio en el que se encuentra la base de datos, ejecutando los siguientes comandos:


C:\android-sdk-windows\platform-tools>adb shell
# su
# cd /data/data/com.whatsapp/databases
# ls –la


Tras la ejecución de los comandos anteriores, la salida es la siguiente:



Como se puede apreciar dentro del rectángulo remarcado en rojo, el nuevo propietario del fichero “msgstore.db”, es el súper-usuario, así como también el nuevo grupo del fichero es el grupo del súper-usuario. Para revertir esta situación, es necesario ejecutar el siguiente comando:adb


# chown u0_a88:u0_a88 msgstore.db


Posteriormente, ejecutando el comando “ls –la”, se puede observar que tanto el propietario como el grupo ya han cambiado, tal y como se observa en la siguiente imagen:


adb14



Como se puede apreciar, el nuevo propietario y el nuevo grupo del fichero “msgstore.db” es u0_a88, que es el mismo que tienen todos los demás ficheros. Para abandonar el modo de depuración, es necesario ejecutar dos veces el comando “exit” y, posteriormente, ya desde Windows, es necesario ejecutar el comando “exit” para cerrar la consola.


Una vez realizado todo el proceso, debe reiniciarse el teléfono móvil y acceder, mediante la utilidad ADB, al directorio en el que se encuentra la base de datos, al objeto de comprobar que las fechas de último acceso de la misma se han actualizado y que no es pòsible determinar si la base de datos ha sido sustituida por una alterada. Para ello, es necesario ejecutar los siguientes comandos:


C:\android-sdk-windows\platform-tools>adb devices
C:\android-sdk-windows\platform-tools>adb shell
# su
# cd /data/data/com.whatsapp/databases
# ls -la


La ejecución de estos comandos ofrece el siguiente resultado:


adb shell 14



Como se puede observar, la fecha de última modificación de la base de datos es muy similar al resto de fechas de los otros archivos utilzados por WhatsApp, por lo que sería muy difícil dictaminar que la base de datos ha sido manipulada. Para ello, serían necesarias técnicas de file carving, es decir, recuperación de ficheros borrados, las cuales son muy costosas debido a las herramientas hardware y software necesarias y, además, no garantizan el éxito porque las áreas del sistema de ficheros ocupadas por ficheros borrados, son sobrescritas por el sistema operativo en función de las necesidades de éste.


A continuación, se muestra el resultado del proceso visualizado en el WhatsApp del teléfono Wiko Goa, junto a la imagen original de los mensajes enviados por el Samsung Galaxy S6:


hoy_


Como se puede observar, el último mensaje ha sido alterado, de tal forma que ha pasado de aparecer “WhatsApp es una aplicación insegura.”, a “WhatsApp es una aplicación segura. No hay nada que temer.” Seguidamente, se adjunta una captura de pantalla en la que aparecen tanto la versión original como la modificada, para apreciar las diferencias.


samsung ga


Como se puede apreciar, la manipulación es sencillamente indetectable a simple vista y, aún realizando un examen pericial informático, resultaría muy difícil de detectar si se han tomado todas las precauciones indicadas en este artículo. También es necesario indicar que muchas más precauciones pueden ser tomadas para evitar que un perito informátuico detecte una manipulación en el envío y la recepción de mensajes de WhatsApp, puesto que la tecnología y la informática evolucionan cada día.


Cabe añadir que, de la misma forma que se han manipulado los mensajes ya enviados y/o recibidos, también es posible y relativamente sencillo generar mensajes que no existían, aparentemente procedentes de cualquier teléfono del mundo, incluso de números inexistentes, haciéndose pasar por auténticos y siendo también muy difícil determinar si lo son o no. Para ello es necesario, además de manipular las tablas en las que se almacenan los mensajes, alterar también la tabla que almacena los contactos, es decir, la denominada chat_list.


Como conclusión, se extrae que WhatsApp es una aplicación muy poco segura y fácilmente manipulable, por lo que la aceptación de conversaciones mantenidas a través de la misma como prueba en un juicio, debe realizarse con cautela y, por supuesto, siempre con el aval de un perito informático colegiado. Por tanto, cuando un perito informático se enfrente a la realización de un peritaje informático sobre la autenticidad de determinadas conversaciones mantenidas a través de WhatsApp, deberá realizar un profundo análisis forense de todos los elementos a su alcance para dictaminar si las conversaciones son o no auténticas.


Fuente:http://peritoinformaticocolegiado.es/


Noticias de seguridad informática

Los responsables de Shopify se niegan a solucionar una vulnerabilidad RFD

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/vulnerabilidades/los-responsables-de-shopify-se-niegan-a-solucionar-una-vulnerabilidad-rfd/
TAGS: RFD (Reflected File Download), Shopify

Cada vez son más los servicios que te ayudan a crear tu página web o tu tienda en línea de una forma rápida y sencilla. Sin embargo, la seguridad de estas plataformas no siempre es del todo adecuada, sirviendo como ejemplo Shopify, que después de seis meses desde que se detectó una vulnerabilidad desde esta han informado que se niegan a solucionarla.


Los ataques RFD (en inglés Reflected File Download) pueden resultar sumamente peligrosos para los usuarios, ya que los atacantes utilizan sitios web legítimos para provocar que el usuario descargue archivos malware. El usuario en ningún momento sospecha, ya que se encuentra en un sitio web legítimo y se cree que se trata de un archivo que no contiene ningún tipo de amenaza. Sin embargo, su ejecución provoca la instalación de virus y pone en peligro la seguridad de los datos de los usuarios.


Esta es la vulnerabilidad que sufre la plataforma Shopify y por lo tanto todos los sitios web creados haciendo uso de esta. Pero lo sorprendente no es esto, sino que esta fue notificada hace seis meses y los responsables del servicio acaban de confirmar que no van a resolverla.


En función del navegador web utilizado las consecuencias de la vulnerabilidad que afecta al dominio app.Shopify.com cambian. Por ejemplo, en el caso de Internet Explorer 8 y 9 se produce la descarga de un archivo .bat, mientras que en el caso de Google Chrome se realiza la apertura de pestaña en la que se puede leer cierto código.


shopify


Por lo tanto, este no solo puede permitir la descarga de archivos con contenido malware, sino que los ciberdelincuentes podrían ejecutar código, otorgándoles la posibilidad de controlar el equipo.


La vulnerabilidad fue descubierta el pasado mes de marzo y desde entonces se ha notificado en varias ocasiones a los responsables del servicio. Sin embargo, no han hecho ningún tipo de caso de las advertencias y ahora el experto en seguridad encargado de descubrirla cree que su publicación en páginas web puede alentar a los responsables de Shopify para que implementen una solución al problema.


Fuente:http://www.redeszone.net/


Noticias de seguridad informática

Nuevos correos de Clinton revelan que recibió mensajes con malware

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/malware-virus/nuevos-correos-de-clinton-revelan-que-recibio-mensajes-con-malware/
TAGS: Hillary Clinton

El departamento de Estado de Estados Unidos publicó hoy una nueva remesa de correos electrónicos de Hillary Clinton que revelan que en su etapa como secretaria de Estado (2009-2013) recibió mensajes con "malware", código maligno que hubiese permitido a los atacantes robarle información. El 3 de agosto de 2011, Clinton recibió en su cuenta de correo electrónico personal (la que usaba para asuntos oficiales) varios correos supuestamente procedentes del departamento de Vehículos a Motor del estado de Nueva York en los que se le notificaba una violación de los límites de velocidad.


Los mensajes eran en realidad "malware" que hubiese permitido a los piratas informáticos obtener información o incluso tomar el control del ordenador en caso de que Clinton hubiese abierto el documento que llevaban adjunto.


Se desconoce si la exsecretaria de Estado y actual precandidata demócrata a la Casa Blanca abrió los documentos adjuntos o no.


Expertos en seguridad informática afirmaron que el código maligno estaba diseñado para enviar la información que obtuviesen a "por lo menos" tres servidores ubicados fuera de EE.UU., uno de ellos en Rusia.




[caption id="attachment_6553" align="alignnone" width="620"]Hillary Clinton Hillary Clinton[/caption]

Los más de 3.800 nuevos correos publicados hoy también revelan una conversación entre Clinton y sus ayudantes precisamente sobre las dudas en materia de seguridad que les planteaba el hecho de que un gran número de altos funcionarios de la diplomacia estadounidense utilizasen sus cuentas de correo electrónico personal.


"Nadie utiliza el ordenador facilitado por el Gobierno e incluso los altos funcionarios a menudo terminan usando sus cuentas de e-mail para poder hacer su trabajo de forma rápida y eficiente", escribió a Clinton Anne-Marie Slaughter, por aquel entonces directora de Planificación Política del departamento de Estado.


La conversación sobre esta cuestión (que años después está causando un auténtico quebradero de cabeza a la campaña de Clinton) vino motivada entonces por un ataque global a las cuentas de correo Gmail de Google en 2011.


Los nuevos correos, como todos los publicados hasta la fecha, también dejan ver aspectos menos conocidos y más personales de Clinton, así como episodios curiosos en la relación con sus ayudantes en el departamento de Estado.


"¿Quién tomó la decisión de que el departamento de Estado no usará los términos 'madre y padre' y los sustituirá por "padre uno y dos'?", se quejó Clinton a sus ayudantes en otro correo electrónico.


"Me adecuaría a que la gente de familias no tradicionales elija otra manera para describirlo, pero en la medida en que mantengamos la presunción de padre y madre. Tenemos que solucionar esto hoy o nos enfrentaremos a una tormenta mediática de la Fox liderada por (Sarah) Palin y los otros", lamentó.


Entre los más de 3.800 e-mails publicados hoy, 215 fueron parcialmente censurados al contener información clasificada, y tres de ellos se han marcado como "secretos".


La polémica por el conocido como "escándalo de los e-mails" se desató a principios de este año, cuando Clinton se preparaba para lanzar su carrera presidencial y los medios revelaron que había utilizado su cuenta de correo electrónico privada para asuntos de interés nacional mientras encabezaba la diplomacia estadounidense.


La oposición republicana exigió que se hicieran públicas aquellas comunicaciones que Clinton mantuvo desde su cuenta privada para ver si podrían haber afectado a la seguridad del país.


En respuesta a las reclamaciones de los republicanos y a los de la propia Clinton, que insistió en que se publicaran para despejar dudas, en mayo pasado el departamento de Estado desclasificó cerca de 300 correos, en su mayoría relativos al atentado contra el Consulado de EEUU en Bengasi (Libia) en 2012.


En julio pasado también se publicaron otras 3.000 páginas de unos 1.900 correos de la ex secretaria de Estado, y el 31 de agosto se divulgaron 7.000 nuevas páginas de e-mails, entre los que destaca uno enviado al fundador de WikiLeaks, Julian Assange. Efe


Fuente:http://www.larazon.es/


Noticias de seguridad informática

Exploit en el nuevo OS X El Capitan inutiliza su seguridad

SOURCE: Noticias de seguridad informática http://noticiasseguridad.com/vulnerabilidades/exploit-en-el-nuevo-os-x-el-capitan-inutiliza-su-seguridad/
TAGS: Apple, Gatekeeper, OS X

No ha pasado un día desde que Apple lanzó su nuevo sistema operativo El Capitan, y ya han surgido detalles de un posible exploit que permite pasar por alto la característica de seguridad Gatekeeper de OS X.


Diseñado para combatir diversas formas de malware, la función de seguridad podría evadirse con un simple truco que implica el uso de un binario autorizado.


Aún cuando Gatekeeper está configurado para utilizar su nivel más alto de protección, la facilidad con que las fortificaciones se pueden sortear es asombrosa. Utilizando un archivo que ya ha sido considerado digno de confianza por parte de Apple, es posible engañar al OS X para que ejecute un archivo malicioso almacenado en la misma carpeta.


No se dispone todavía de parche y se cree que el problema afecta a todas las versiones de OS X.


La vulnerabilidad fue descubierta por el investigador de seguridad Patrick Wardle de Synack. Hablando con Threatpost, Wardle explica que ya ha compartido sus hallazgos con Apple, pero la compañía aún está por producir un parche.


gatekeeper


El experto encontró que Gatekeeper, mientras verificaba la autenticación de los archivos desde Apple, no determinaba si las apps controlan otras apps o código que no se han autorizado. Una vez que la app ha recibido el visto bueno de Gatekeeper, es libre de ejecutar cualquier código que quiera en el equipo, y esto es precisamente cómo el exploit funciona.


Los usuarios podrían ser fácilmente engañados para ejecutar un archivo infectado autorizado que podría causar un daño incalculable.


Según Wardle: "No es muy complicado, pero evita efectivamente Gatekeeper por completo. Esto proporciona a los hackers la posibilidad de volver a sus viejos trucos de infectar a usuarios con troyanos, estafas AV o infectar aplicaciones en The Pirate Bay. Lo más preocupante para mí es que esto permitiría que adversarios más sofisticados tengan acceso a la red. Naciones con nivel de acceso superior ven descargas inseguras, pueden intercambiar esta binaria legítima de Apple y este binario malicioso, así como un ataque con intermediario, y Gatekeeper no protegerán a los usuarios de ellos."


La cuestión no está siendo descrito como un error, sino como una limitación de Gatekeeper, por lo que una solución podría tomar algún tiempo. Sobre todo si, como advierte Wardle, la solución requeriría "cambios de código importantes" a OS X.


Fuente:http://computerhoy.com/


Noticias de seguridad informática