{"id":6659,"date":"2015-08-18T07:16:45","date_gmt":"2015-08-18T07:16:45","guid":{"rendered":"https:\/\/kasperskydaily.com\/spain\/?p=6659"},"modified":"2019-11-22T11:28:59","modified_gmt":"2019-11-22T09:28:59","slug":"security-week-digest-33","status":"publish","type":"post","link":"https:\/\/www.kaspersky.es\/blog\/security-week-digest-33\/6659\/","title":{"rendered":"Semana de la seguridad 33: Puertas sin cerraduras, Microsoft invulnerable, desensamble y dolor."},"content":{"rendered":"<p>Bienvenidos al resumen semanal de noticias en seguridad, primera temporada. Segundo episodio. <a href=\"https:\/\/www.kaspersky.es\/blog\/security-week-digest-32\/6610\/\" target=\"_blank\" rel=\"noopener\">En la serie anterior<\/a> aprendimos de los nuevos hackeos de coches, la cr\u00f3nica de Stagefright en Android y c\u00f3mo evitar que te vigilen en Internet (de hecho lo fuimos).<\/p>\n<p>En esta publicaci\u00f3n hay dos noticias sin aparente relaci\u00f3n; sin embargo, tienen algo en com\u00fan: y no es que en alg\u00fan lugar haya alguien sensible a un ataque, sino que esa vulnerabilidad a veces surge de la aversi\u00f3n a adoptar medidas de seguridad disponibles. Y la tercera noticia no es sobre seguridad en absoluto, sino que m\u00e1s bien se refiere en particular a las relaciones dentro de la industria. Estos tres son lo suficientemente divertidos como para ser tan diferentes de lo que parecen<\/p>\n<p>Deja que te recuerde las reglas: los editores de <a href=\"https:\/\/threatpost.com\/\" target=\"_blank\" rel=\"noopener nofollow\">Threatpost<\/a> escogen tres noticias de las m\u00e1s importantes, a las que yo agrego un comentario amplio y despiadado. Podr\u00e1s encontrar todos los episodios de la serie <a href=\"https:\/\/www.kaspersky.es\/blog\/tag\/semana-de-la-seguridad\/\" target=\"_blank\" rel=\"noopener\">aqu\u00ed<\/a>.<\/p>\n<p><strong>Hackear puertas de hoteles<\/strong><br>\n<a href=\"https:\/\/threatpost.com\/blekey-device-breaks-rfid-physical-access-controls\/\" target=\"_blank\" rel=\"noopener nofollow\">La publicaci\u00f3n de Threatpost<\/a><\/p>\n<p>Dicen que no hay dicotom\u00eda entre ciencias y humanidades, y los adeptos a estos dos enfoques dif\u00edcilmente puede entenderse. Y hay una fuerte creencia de que ning\u00fan intelectual humanista puede convertirse en un cient\u00edfico o un ingeniero.<\/p>\n<p>Este estereotipo fue desafiado por John Wiegand, un m\u00fasico de profesi\u00f3n. En la d\u00e9cada de 1930 fue pianista y director de orquesta de un coro de ni\u00f1os, hasta que se interes\u00f3 por el dise\u00f1o de amplificadores de audio. En la d\u00e9cada de 1940 trabaj\u00f3 en la novedosa grabaci\u00f3n de casetes. Y en 1974 (a la edad de sus tant\u00edsimos 62 a\u00f1os) hizo su gran descubrimiento.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignright\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/88\/2015\/08\/05220130\/security-week-33-wiegand-220x300.jpg\" alt=\"\" width=\"220\" height=\"300\"><\/p>\n<p>La interface de Wiegand, como actualmente se conoce, es un alambre de hierro, cobalto y vanadio de aleaci\u00f3n magn\u00e9tica tratado de tal manera que conforma un tejido duro exterior alrededor de un n\u00facleo suave interior. Los campos externos magnetizan f\u00e1cilmente la capa exterior, que tambi\u00e9n resiste a la desmagnetizaci\u00f3n, incluso cuando se eliminan los campos externos. Una caracter\u00edstica llamada alta coercertividad. Dentro del alambre suave, este tiene un comportamiento diferente, no es magnetizado hasta que la cubierta lo hace.<\/p>\n<p>El momento en que la cubierta del alambre se magnetiza totalmente y el n\u00facleo finalmente obtiene su propia porci\u00f3n de magnetizaci\u00f3n, tanto el n\u00facleo como la cubierta se polarizan. El interruptor genera cierto voltaje que puede ser aprovechado para todo tipo de aplicaciones de detecci\u00f3n y movimiento, haciendo este efecto \u00fatil, por ejemplo, en las llaves de hotel.<\/p>\n<p>A diferencia de las tarjetas actuales, el c\u00f3digo de \u201cunos y ceros\u201d, no es registrado en el chip, sino en la secuencia del cableado especial establecido. Es imposible re-programar dicha clave o c\u00f3digo y el esquema general de la misma no es como la de las actuales tarjetas de proximidad del transporte p\u00fablico por tarifas o las tarjetas bancarias, pero es similar a las de banda magn\u00e9tica, s\u00f3lo que m\u00e1s confiables.<\/p>\n<p>\u00bfEntonces debemos descartar las tarjetas de proximidad? <em>A\u00fan no<\/em>. Wiegand dio su nombre, no s\u00f3lo por el efecto descubierto, sino tambi\u00e9n por el <a href=\"https:\/\/en.wikipedia.org\/wiki\/Wiegand_interface\" target=\"_blank\" rel=\"noopener nofollow\">protocolo<\/a> de intercambio de datos, el cual es bastante antiguo. Todo en este protocolo es nefasto. En primer lugar, nunca ha sido debidamente estandarizado, y hay muchas implementaciones que var\u00edan entre s\u00ed.<\/p>\n<blockquote class=\"twitter-pullquote\"><p>#Semana de la seguridad 33: \u00a0Puertas sin cerraduras, #Microsoft invulnerable, #desensamble y dolor<\/p><a href=\"https:\/\/twitter.com\/share?url=https%3A%2F%2Fkas.pr%2F887z&amp;text=%23Semana+de+la+seguridad+33%3A+%C2%A0Puertas+sin+cerraduras%2C+%23Microsoft+invulnerable%2C+%23desensamble+y+dolor\" class=\"btn btn-twhite\" data-lang=\"en\" data-count=\"0\" target=\"_blank\" rel=\"noopener nofollow\">Tweet<\/a><\/blockquote>\n<p>En segundo lugar, el ID de la tarjeta puede almacenar o guardar hasta 16 bits, dando muy pocas combinaciones posibles. En tercer lugar, el dise\u00f1o de las tarjetas de proximidad, inventadas mucho antes de saber siquiera c\u00f3mo poner un ordenador completo en una tarjeta de cr\u00e9dito, limita la longitud de la clave a s\u00f3lo 37 bits con la certeza de que no aceptar\u00e1 claves mucho m\u00e1s largas.<\/p>\n<p>As\u00ed que, la semana pasada los investigadores de Black Hat, <a href=\"https:\/\/twitter.com\/ericevenchick\" target=\"_blank\" rel=\"noopener nofollow\">Eric Evenchick<\/a> y <a href=\"https:\/\/twitter.com\/markbaseggio\" target=\"_blank\" rel=\"noopener nofollow\">Mark Baseggio<\/a> mostraron un dispositivo (no cifrado) para interceptar las secuencias de claves, durante la verificaci\u00f3n de autorizaci\u00f3n. El detalle m\u00e1s interesante aqu\u00ed es que las tarjetas no tienen nada que hacer, ya que la informaci\u00f3n es robada durante la transmisi\u00f3n de datos desde el lector de tarjetas al controlador de puertas, d\u00f3nde se utiliza la interface de Wiegand hist\u00f3ricamente.<\/p>\n<p>El nombre de este dispositivo es BLEkey: una peque\u00f1a pieza de hardware que necesita ser integrada en un lector de tarjetas; por ejemplo, en las puertas de un hotel. Los investigadores demostraron que esta operaci\u00f3n tarda alrededor de varios segundos. Entonces todo es muy simple. Leemos la llave, esperamos a que el due\u00f1o salga y abrimos la puerta. O no esperamos. O nunca abrimos. Sin entrar en detalles t\u00e9cnicos, el di\u00e1logo entre la puerta y el lector sucede de la siguiente manera:<\/p>\n<p><em>\u201c\u00bf<\/em><em>Qui<\/em><em>\u00e9<\/em><em>n est<\/em><em>\u00e1<\/em> <em>ah<\/em><em>\u00ed<\/em><em>?<\/em><em>\u201c<\/em><\/p>\n<p><em>\u201c<\/em><em>Soy yo.<\/em><em>\u201c<\/em><\/p>\n<p><em>\u201c<\/em><em>Oh, eres t<\/em><em>\u00fa<\/em><em>. <\/em><em>\u00a1<\/em><em>Entra!<\/em><em>\u201c<\/em><\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Final talk run through! <a href=\"http:\/\/t.co\/TQB472izkO\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/TQB472izkO<\/a><\/p>\n<p>\u2014 Eric Evenchick (@ericevenchick@mastodon.social) (@ericevenchick) <a href=\"https:\/\/twitter.com\/ericevenchick\/status\/629324182459940864?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 6, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Todo parece ser bastante claro, pero hay un peque\u00f1o matiz. Bueno, como siempre, no todos los sistemas de control de acceso son vulnerables a este ataque. E incluso aquellos que lo son pueden ser protegidos sin tener que ser reemplazados. Seg\u00fan los investigadores, los lectores tienen medios para protegerse de estos hackeos, pero esas caracter\u00edsticas suelen ser, claro est\u00e1, inhabilitadas.<\/p>\n<p>Algunos incluso siguen el<a href=\"http:\/\/www.siaonline.org\/Pages\/Standards\/OSDP.aspx\" target=\"_blank\" rel=\"noopener nofollow\"> Protocolo abierto de Dispositivos Supervisados<\/a>, lo que permite cifrar la secuencia de llaves. Estas \u201cfuncionalidades\u201d ya no se utilizan. Nunca dejaremos repetir, porque descuidar las medidas de seguridad es barato y f\u00e1cil.<\/p>\n<p>Aqu\u00ed hay otro interesante <a href=\"https:\/\/www.defcon.org\/images\/defcon-17\/dc-17-presentations\/defcon-17-mike_davis_who_invented_the_proximity_card.pdf\" target=\"_blank\" rel=\"noopener nofollow\">estudio<\/a> del 2009 sobre el tema, con detalles t\u00e9cnicos. Al parecer la vulnerabilidad de las tarjetas (no los lectores) se puso de manifiesto en 1992, pero luego se sugiri\u00f3 que las tarjetas deben ser desensambladas o examinadas por medio de rayos X. Para conseguirlo, ten\u00edan que quit\u00e1rselas al due\u00f1o. Y ahora la soluci\u00f3n est\u00e1 en un peque\u00f1o dispositivo del tama\u00f1o de una moneda. \u00a1Eso es lo que llamamos progreso!<\/p>\n<p><strong>Inmunidad de Microsoft. Los entresijos corporativos de Windows Server Update Services.<\/strong><\/p>\n<p><a href=\"https:\/\/threatpost.com\/manipulating-wsus-to-own-enterprises\/\" target=\"_blank\" rel=\"noopener nofollow\">La Historia de Threatpost<\/a> y las investigaciones originales del <a href=\"https:\/\/www.blackhat.com\/docs\/us-15\/materials\/us-15-Stone-WSUSpect-Compromising-Windows-Enterprise-Via-Windows-Update-wp.pdf\" target=\"_blank\" rel=\"noopener nofollow\">libro blanco<\/a><\/p>\n<p>Los servicios de actualizaci\u00f3n en Windows Server permiten a las grandes empresas centralizar la instalaci\u00f3n de actualizaciones en sus ordenadores mediante un servidor interno, en lugar de una fuente externa. Y, este es un sistema muy fiable y sobradamente seguro. En primer lugar, todas las actualizaciones deben ser firmadas por Microsoft. En segundo lugar, la comunicaci\u00f3n entre el servidor de actualizaci\u00f3n de la compa\u00f1\u00eda y el servidor del proveedor es cifrado por SSL.<\/p>\n<p>Este sistema es bastante simple. El servidor de la compa\u00f1\u00eda recibe un listado de actualizaciones en un archivo XML, el cual indicaba qu\u00e9, c\u00f3mo y d\u00f3nde descargarlo. Y result\u00f3 que esta interacci\u00f3n inicial se env\u00eda en texto plano. No, de hecho est\u00e1 mal decirlo de esa manera. Este <strong>debe<\/strong> ser cifrado y al implementarlo en WSUS, es muy recomendable un administrador para habilitar el cifrado. Pero este se desactiva por defecto.<\/p>\n<p>No es algo terrible porque el reemplazar las \u201cinstrucciones\u201d no es f\u00e1cil, pero si un atacante ya tiene la capacidad de interceptar el tr\u00e1fico (a trav\u00e9s de la estrategia \u201cman-in -the-middle\u201d), entonces es posible. Los investigadores Paul Stone y Alex Chapman se dieron cuenta que mediante la sustituci\u00f3n de las instrucciones, se puede ejecutar un c\u00f3digo arbitrario con privilegios elevados en las actualizaciones del sistema. No, Microsoft s\u00ed verifica certificados digitales; sin embargo, este acepta el certificado de cualquier compa\u00f1\u00eda. Por ejemplo, puedes introducir clandestinamente utilidades PsExec desde los kits SysInternals, y con su ayuda, podr\u00edas lanzar cualquier cosa.<\/p>\n<p>\u00bfPor qu\u00e9 sucede esto? La cuesti\u00f3n es que a la hora de habilitar un SSL, se necesita generar un certificado para la implementaci\u00f3n de WSUS y estos no pueden ser automatizados. Como se\u00f1alaron los investigadores en este caso, Microsoft simplemente no puede hacer nada sino instar a la activaci\u00f3n de SSL. Por lo tanto, parece como si hubiera vulnerabilidad y no la hubiera a la vez. Y no existe ayuda. Y la culpa no es de nadie sino del administrador.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">One of our weaker advertising campaigns for Windows: <a href=\"http:\/\/t.co\/Fon5IvBFnP\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/Fon5IvBFnP<\/a><\/p>\n<p>\u2014 Mark Russinovich (@markrussinovich) <a href=\"https:\/\/twitter.com\/markrussinovich\/status\/631505582139117569?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 12, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Adem\u00e1s, Kaspersky Lab descubri\u00f3 <a href=\"https:\/\/securelist.com\/blog\/incidents\/33002\/flame-replication-via-windows-update-mitm-proxy-server-18\/\" target=\"_blank\" rel=\"noopener\">Flame: un spyware que entra en Windows Update para infectarlo,<\/a> aunque de una manera diferente. Un proxy falso, interceptaba peticiones al servidor de Microsoft, y los archivos de respuesta enviados eran un poco diferentes, de hecho, algunos de ellos fueron firmados por el proveedor.<\/p>\n<p><strong>Ingenier<\/strong><strong>\u00ed<\/strong><strong>a inversa y dolor<\/strong><\/p>\n<p><a href=\"https:\/\/threatpost.com\/oracle-cso-you-must-not-reverse-engineer-our-code\" target=\"_blank\" rel=\"noopener nofollow\">La publicaci\u00f3n de Threatpost<\/a>. La publicaci\u00f3n original de Oracle CSO (<a href=\"https:\/\/webcache.googleusercontent.com\/search?q=cache:ntXM0RlghUUJ:https:\/\/blogs.oracle.com\/maryanndavidson\/entry\/no_you_really_can_t+&amp;cd=1&amp;hl=en&amp;ct=clnk&amp;gl=us\" target=\"_blank\" rel=\"noopener nofollow\">el cache<\/a> de Google y <a href=\"http:\/\/seclists.org\/isn\/2015\/Aug\/4\" target=\"_blank\" rel=\"noopener nofollow\">la copia<\/a> \u2013 Internet nunca olvida)<\/p>\n<p>Las citas anteriores presentadas en las conferencias de Black Hat est\u00e1n relacionadas, ya que los autores de estos estudios (los expertos en seguridad), descubrieron fallos en algunas tecnolog\u00edas o productos desarrollados por otros. Publicaron sus investigaciones y en el caso de BLEKey tambi\u00e9n presentaron el c\u00f3digo completo y el hardware de libre acceso. Esto en general, es la manera m\u00e1s estandarizada de interacci\u00f3n con el mundo exterior en seguridad IT pero no a todo el mundo le gusta esta situaci\u00f3n.<\/p>\n<p>No me gustar\u00eda valorar, por lo que ser\u00eda suficiente con decir que este es un tema muy delicado. \u00bfEst\u00e1 bien analizar el c\u00f3digo de otros y en qu\u00e9 condiciones ser\u00eda correcto? \u00bfC\u00f3mo debemos revelar informaci\u00f3n vulnerable para no hacer da\u00f1o? \u00bfPodemos recibir dinero por los fallos que encontramos? Las restricciones legislativas, el c\u00f3digo penal y las leyes a\u00fan no escritas en la industria nos afectan a todos.<\/p>\n<p>Una reciente publicaci\u00f3n creada por la Directora de Seguridad de Oracle, Mary Ann Davidson cre\u00f3 <em>el efecto de un elefante en una cacharrer\u00eda<\/em>. Se titulaba \u201cNo, realmente no puedes\u201d y fue dedicado totalmente a los clientes de la empresa (no a la industria en general), quienes enviaron informaci\u00f3n acerca de la vulnerabilidad en los productos de la compa\u00f1\u00eda.<\/p>\n<p>El texto entero del 10 de agosto de 2015 publicado en el blog de Oracle vale la pena citarlo, pero os dejo lo m\u00e1s importante: si un cliente pudiera aprender sobre vulnerabilidad por ingenier\u00eda inversa, entonces el cliente violar\u00eda el acuerdo de licencia, y ser\u00eda un error.<\/p>\n<p><a href=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/88\/2015\/08\/05222614\/security-week-33-sobchak.png\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-6661\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/88\/2015\/08\/05222614\/security-week-33-sobchak.png\" alt=\"security-week-33-sobchak\" width=\"600\" height=\"700\"><\/a><\/p>\n<p>Cita:<\/p>\n<p><em>Un cliente no puede analizar un c\u00f3digo para ver si hay un procedimiento que evita un ataque del que la herramienta de escaneo le est\u00e1 avisando (es muy probable que de un falso positivo). Un cliente no puede producir un parche para resolver el problema. S\u00f3lo el vendedor puede hacerlo. Un cliente estar\u00e1 violando el acuerdo de licencia al usar una herramienta que hace el an\u00e1lisis est\u00e1tico (que opera en contra del c\u00f3digo).<\/em><\/p>\n<p>La reacci\u00f3n del p\u00fablico result\u00f3 <a href=\"https:\/\/twitter.com\/nicboul\/status\/631183093580341248\" target=\"_blank\" rel=\"noopener nofollow\">as\u00ed:<\/a><\/p>\n<p>https:\/\/twitter.com\/nicboul\/status\/631183093580341248<\/p>\n<p>O <a href=\"https:\/\/twitter.com\/briankrebs\/status\/631257607530020864\" target=\"_blank\" rel=\"noopener nofollow\">as\u00ed<\/a>:<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Adobe, Microsoft Push Patches, Oracle Drops Drama <a href=\"http:\/\/t.co\/XN4Tpb9RXw\" target=\"_blank\" rel=\"noopener nofollow\">http:\/\/t.co\/XN4Tpb9RXw<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/oraclefanfic?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#oraclefanfic<\/a><\/p>\n<p>\u2014 briankrebs (@briankrebs) <a href=\"https:\/\/twitter.com\/briankrebs\/status\/631257607530020864?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 12, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>O incluso <a href=\"https:\/\/twitter.com\/headhntr\/status\/631081198534664192\" target=\"_blank\" rel=\"noopener nofollow\">as\u00ed<\/a>:<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Don't look for vulns. Fuck bug bounties. We won't even credit you. <a href=\"https:\/\/t.co\/VgCrjGYx1j\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/VgCrjGYx1j<\/a> An <a href=\"https:\/\/twitter.com\/Oracle?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@oracle<\/a> love letter to the security community.<\/p>\n<p>\u2014 Morgan Marquis-Boire (@headhntr) <a href=\"https:\/\/twitter.com\/headhntr\/status\/631081198534664192?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 11, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>En resumen, la publicaci\u00f3n no dur\u00f3 m\u00e1s de un d\u00eda y se retir\u00f3 debido a las \u201cinconsistencias en los puntos de vista [oficiales] sobre la interacci\u00f3n con los clientes\u201d (pero Internet no olvida). Recordemos que Oracle desarrolla Java, y s\u00f3lo los m\u00e1s vagos no explotar\u00edan sus vulnerabilidades. <a href=\"https:\/\/securelist.com\/analysis\/publications\/57888\/kaspersky-lab-report-java-under-attack\/\" target=\"_blank\" rel=\"noopener\">Hace tres a\u00f1os te contamos sobre las vulnerabilidades ocurridas de Java durante 12 meses. \u00a1Encontramos 160!<\/a><\/p>\n<p>Quiz\u00e1s en un mundo ideal la b\u00fasqueda de vulnerabilidades de software y sus soluciones deber\u00edan hacerse exclusivamente por proveedores de software. Pero en un mundo real, \u00bfno sucede a veces eso de que los responsables de mover los hilos siguen el principio de hacer justo lo contrario?<\/p>\n<p><em>Pero veamos el otro lado de la historia.<\/em><\/p>\n<p>La semana pasada, el fundador de Black Hat, Jeff Moss, <a href=\"https:\/\/threatpost.com\/software-liability-is-inevitable\/\" target=\"_blank\" rel=\"noopener nofollow\">habl\u00f3 sobre los proveedores de software como los responsables de las fallos en los c\u00f3digos<\/a>. Dijo que es hora de deshacerse de \u201cEULA\u201d (acabar con las pol\u00edticas de licencia) y de todo aquello d\u00f3nde se dice que la empresa no tienen ninguna responsabilidad hacia sus clientes. La declaraci\u00f3n es interesante, pero no menos pretenciosa que la declaraci\u00f3n: \u201cHay que prohibir desensamblar\u201d. Hasta ahora s\u00f3lo hay algo claro: si los usuarios (empresas y particulares), proveedores e investigadores no pueden entenderse entre s\u00ed, esto no se llevar\u00e1 a cabo por declaraciones llamativas y bromas de Twitter.<\/p>\n<p><strong>\u00bf<\/strong><strong>Qu<\/strong><strong>\u00e9<\/strong> <strong>m<\/strong><strong>\u00e1<\/strong><strong>s sucedi<\/strong><strong>\u00f3<\/strong><strong>?:<\/strong><\/p>\n<p>Otra <a href=\"https:\/\/threatpost.com\/researchers-unveil-square-reader-mobile-pos-hacks\/\" target=\"_blank\" rel=\"noopener nofollow\">conferencia<\/a> de Black Hat sobre hackear Square Reader, aquello que conectas en tu smartphone para pagar a un repartidor de sushi. Requiere soldadura.<\/p>\n<p><a href=\"https:\/\/threatpost.com\/lenovo-hit-with-criticism-over-second-rootkit-like-utility\/114261\" target=\"_blank\" rel=\"noopener nofollow\">Rootkit <\/a> de otro proveedor encontrado en ordenadores port\u00e1tiles Lenovo (no todos, pero s\u00ed algunos). <a href=\"https:\/\/threatpost.com\/lenovo-superfish-certificate-password-cracked\/111165\" target=\"_blank\" rel=\"noopener nofollow\">Sobre la historia anterior.<\/a><\/p>\n<p><strong>Oldies<\/strong><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignright\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/88\/2015\/08\/05220129\/infosec-digest-32-book1-234x300.jpg\" alt=\"\" width=\"234\" height=\"300\"><\/p>\n<p>La \u201cpeque\u00f1a\u201d familia del malware<\/p>\n<p>Generalmente los llamados \u201cVirus Residentes\u201d son a\u00f1adidos al final de los archivos .com (a excepci\u00f3n de Small-114, -118, -122, los cuales aparecen al inicio) cuando se cargan los archivos en la memoria. La mayor\u00eda de las familias de virus, utilizan comandos como POPA y PUSHA en procesadores de 80\u00d786. SMALL-132, -149 infecta ciertos archivos de forma incorrecta. Pertenecen a diferentes autores. Al parecer, el origen de la familia \u201cSMALL\u201d puede ser vista como competencia de los \u201cvirus residentes\u201d en memoria m\u00e1s corta para los MS-DOS. S\u00f3lo queda decidir qui\u00e9n es el ganador.<\/p>\n<p><em>Citas del libro \u201cComputer viruses in MS-DOS\u201d de Eugene Kaspersky, 1992, p\u00e1gina 45.<\/em><\/p>\n<p><em>Legales: <em>Este art\u00edculo refleja \u00fanicamente la opini\u00f3n personal del autor. Usted puede coincidir con la posici\u00f3n de Kaspersky Lab, o no. <\/em><em>Depende de la suerte.<\/em><\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>En esta publicaci\u00f3n hay dos noticias sin aparente relaci\u00f3n; sin embargo, tienen algo en com\u00fan: y no es que en alg\u00fan lugar haya alguien sensible a un ataque, sino que esa vulnerabilidad a veces surge de la aversi\u00f3n a adoptar medidas de seguridad disponibles.<\/p>\n","protected":false},"author":53,"featured_media":6660,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1348,6],"tags":[463,891,1379,1383,1385,1380,553,1381,1384,1434,61,1369],"class_list":{"0":"post-6659","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-threats","8":"category-news","9":"tag-actualizaciones","10":"tag-black-hat","11":"tag-blackhat","12":"tag-hacks","13":"tag-ingenieria-reversiva","14":"tag-microsft","15":"tag-noticias","16":"tag-oracle","17":"tag-puertas","18":"tag-security-week","19":"tag-seguridad","20":"tag-semana-de-la-seguridad"},"hreflang":[{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/security-week-digest-33\/6659\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/security-week-digest-33\/5834\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/security-week-digest-33\/6121\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/security-week-digest-33\/5976\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/security-week-digest-33\/6495\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/security-week-digest-33\/8592\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/security-week-digest-33\/9591\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/security-week-digest-33\/4797\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/security-week-digest-33\/5975\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/security-week-digest-33\/8636\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/security-week-digest-33\/8592\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/security-week-digest-33\/9591\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/security-week-digest-33\/9591\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.es\/blog\/tag\/actualizaciones\/","name":"actualizaciones"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/6659","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/users\/53"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/comments?post=6659"}],"version-history":[{"count":2,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/6659\/revisions"}],"predecessor-version":[{"id":20292,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/posts\/6659\/revisions\/20292"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media\/6660"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/media?parent=6659"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/categories?post=6659"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.es\/blog\/wp-json\/wp\/v2\/tags?post=6659"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}