{"id":5975,"date":"2015-08-18T09:01:00","date_gmt":"2015-08-18T09:01:00","guid":{"rendered":"https:\/\/kasperskydaily.com\/germany\/?p=5975"},"modified":"2017-09-27T15:02:32","modified_gmt":"2017-09-27T13:02:32","slug":"security-week-digest-33","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/security-week-digest-33\/5975\/","title":{"rendered":"Sicherheitswoche 33: T\u00fcren ohne Schl\u00f6sser, Immunit\u00e4t f\u00fcr Microsoft, Reverse-Engineering und Schmerz"},"content":{"rendered":"<p>Willkommen zu unserem Wochenr\u00fcckblick. Beim <a href=\"https:\/\/www.kaspersky.com\/blog\/security-week-digest-32\/\" target=\"_blank\" rel=\"noopener nofollow\">letzten Mal<\/a> ging es um gehackte Autos, Android Stagefright und um die Privatsph\u00e4re im Internet. Diesmal haben wir unter anderem zwei Themen, die augenscheinlich nichts miteinander zu tun haben, aber dennoch etwas gemeinsam haben: nicht, dass es irgendwo Sicherheitsl\u00fccken gibt, sondern dass Sicherheitsl\u00fccken manchmal vom Widerwillen kommen, Sicherheitsma\u00dfnahmen zu ergreifen. Und das dritte Thema hat gar nichts mit Sicherheit zu tun, sondern mit Beziehungen innerhalb der Branche.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2015\/08\/06133738\/security-week-33-FB.jpg\" alt=\"\" width=\"1600\" height=\"1600\"><\/p>\n<p>Hier noch einmal die Regeln f\u00fcr den Wochenr\u00fcckblick: Die Redakteure von <a href=\"https:\/\/threatpost.com\/\" target=\"_blank\" rel=\"noopener nofollow\">Threatpost<\/a> w\u00e4hlen die drei wichtigsten Meldungen aus, die ich dann ausf\u00fchrlich und schonungslos kommentiere. Alle Wochenr\u00fcckblicke finden Sie <a href=\"https:\/\/www.kaspersky.com\/blog\/tag\/security-week\/\" target=\"_blank\" rel=\"noopener nofollow\">hier<\/a>.<\/p>\n<h3>Das Hacken von Hotelt\u00fcren<\/h3>\n<p><a href=\"https:\/\/threatpost.com\/blekey-device-breaks-rfid-physical-access-controls\/\" target=\"_blank\" rel=\"noopener nofollow\">Der Threatpost-Artikel<\/a>.<\/p>\n<p>Man sagt, es g\u00e4be einen Gegensatz zwischen Naturwissenschaft und Geisteswissenschaft, und die Adepten der beiden Disziplinen k\u00f6nnen sich kaum gegenseitig verstehen. Und es gibt die Ansicht, dass ein Geisteswissenschaftler nie zu einem Naturwissenschaftler oder Ingenieur werden kann.<\/p>\n<p>Das wurde von John Wiegand, einem ausgebildeten Musiker, widerlegt. In den 1930er Jahren war er <a href=\"http:\/\/machinedesign.com\/engineering-essentials\/brushing-wiegand-man-effect-and-wire-changed-engineering\" target=\"_blank\" rel=\"noopener nofollow\">Pianist<\/a> und dirigierte einen Kinderchor \u2013 bis er sich f\u00fcr das Design von Audioverst\u00e4rkern interessierte. In den 1940er Jahren arbeitete er an einer Neuheit dieser Zeit: der Tonbandaufnahme. Und im Jahr 1974 machte er (im Alter von 62 Jahren) seine gr\u00f6\u00dfte Entdeckung: Den Wiegand-Sensor.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\" alignright\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2015\/08\/06133738\/security-week-33-wiegand-220x300.jpg\" alt=\"\" width=\"220\" height=\"300\"><\/p>\n<p>Der Wiegand-Sensor ist ein magnetisches Kabel aus einer Kobalt-Eisen\/Vanadium-Legierung, das so behandelt wird, dass es eine harte \u00e4u\u00dfere Schale um einen weichen Kern bildet. Externe Magnetfelder magnetisieren die \u00e4u\u00dfere Schale leicht und diese widersteht auch der Entmagnetisierung, selbst wenn die externen Felder abgeschaltet werden \u2013 das nennt man h\u00f6here Koerzitivkraft. Das weiche, innere Kabel verh\u00e4lt sich anders: Es wird erst dann magnetisiert, wenn die \u00e4u\u00dfere H\u00fclle voll magnetisiert worden ist.<\/p>\n<p>Genau zu dem Zeitpunkt, wenn die Schale des Kabels voll magnetisiert ist und der Kern beginnen kann, sich zu magnetisieren, wird die Polarit\u00e4t der beiden Kabelteile vertauscht. Das erzeugt einen ziemlichen Strom, der f\u00fcr alle m\u00f6glichen Arten von Sensoren und Bewegungsregistrierungen verwendet werden. Genutzt wird das zum Beispiel in Hotelzimmerschl\u00fcsseln.<\/p>\n<p>Anders als in modernen Schl\u00fcssel- oder Geldkarten, sind die Nullen und Einsen nicht auf einem Chip gespeichert, sondern in der direkten Sequenz einer speziellen Verkabelung. Es ist dadurch unm\u00f6glich, so einen Schl\u00fcssel umzuprogrammieren und deren generelle Anwendung l\u00e4uft nicht wie bei modernen, ber\u00fchrungslosen Bahnkarten oder Zahlungskarten, sondern \u00e4hnlich den \u00e4lteren Magnetkarten \u2013 nur zuverl\u00e4ssiger.<\/p>\n<p>Sollten wir ber\u00fchrungslose Karten also gleich wieder abschaffen? <em>Noch nicht<\/em>. Wiegand hat seinen Namen nicht nur dem entdeckten Effekt gegeben, sondern auch dem Datenaustausch<a href=\"https:\/\/en.wikipedia.org\/wiki\/Wiegand_interface\" target=\"_blank\" rel=\"noopener nofollow\">protokoll<\/a>, das bereits recht alt ist. An diesem Protokoll ist so ziemlich alles recht schlecht. Zum einen wurde es nie richtig standardisiert, so dass es viele verschiedene Implementationen davon gibt.<\/p>\n<p>Zum anderen kann die originale Karten-ID nur bis zu 16 Bit enthalten, was sehr wenige Kombinationen erm\u00f6glicht. Und drittens beschr\u00e4nken diese ber\u00fchrungslosen Karten mit Verkabelung \u2013 die entwickelt wurden, bevor wir gelernt haben, einen ganzen Computer in eine Kreditkarte zu packen \u2013 die Schl\u00fcssell\u00e4nge auf nur 37 Bit und die Zuverl\u00e4ssigkeit beim Auslesen wird bei l\u00e4ngeren Schl\u00fcsseln immer schlechter.<\/p>\n<p>Und nun zeigten die Sicherheitsforscher <a href=\"https:\/\/twitter.com\/ericevenchick\" target=\"_blank\" rel=\"noopener nofollow\">Eric Evenchick<\/a> und <a href=\"https:\/\/twitter.com\/markbaseggio\" target=\"_blank\" rel=\"noopener nofollow\">Mark Baseggio<\/a> auf der Black-Hat-Konferenz ihr Ger\u00e4t zum Abfangen (unverschl\u00fcsselter) Schl\u00fcsselsequenzen w\u00e4hrend der Autorisierung. Das Interessanteste dabei ist, dass die Karten damit gar nichts zu tun haben, da die Informationen bei der \u00dcbertragung vom Kartenleser zum T\u00fcr-Controller gestohlen werden \u2013 und dabei wird schon immer das Wiegand-Protokoll verwendet.<\/p>\n<p>Der Name des Ger\u00e4ts lautet BLEkey \u2013 ein kleines St\u00fcck Hardware, das in einen Kartenleser eingebaut werden muss, zum Beispiel an einer Hotelzimmert\u00fcr. Die Forscher zeigten, dass die ganze Operation nur einige Sekunden dauert. Und dann geht alles ganz einfach: Man liest den Schl\u00fcssel aus, wartet, bis der Gast das Zimmer verl\u00e4sst, und kann dann selbst die T\u00fcr \u00f6ffnen. Oder man wartet gar nicht so lange. Oder man \u00f6ffnet die T\u00fcr nie. Wie auch immer, der Dialog zwischen der T\u00fcr und dem Kartenleser\/Drahtlosger\u00e4t l\u00e4uft etwa so (ohne dabei in technische Details gehen zu wollen):<\/p>\n<p><em>\u201eWer ist da?\u201c<\/em><\/p>\n<p><em>\u201eIch bin\u2019s.\u201c<\/em><\/p>\n<p><em>\u201eAh, Du bist da. Komm rein!\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>Das scheint alles glasklar zu sein, aber es gibt da noch eine Kleinigkeit. Wie immer sind nicht alle Zugangskontrollsysteme f\u00fcr diesen Angriff anf\u00e4llig. Und selbst die anf\u00e4lligen k\u00f6nnen gesch\u00fctzt werden, ohne dass man sie komplett ersetzen muss. Laut den Forschern sind die Kartenleser mit Schutzma\u00dfnahmen vor solchen Hacks ausgestattet, allerdings sind diese Funktionen meist\u2026 nun ja\u2026 ausgeschaltet.<\/p>\n<p>Manche Ger\u00e4te unterst\u00fctzen sogar das <a href=\"http:\/\/www.siaonline.org\/Pages\/Standards\/OSDP.aspx\" target=\"_blank\" rel=\"noopener nofollow\">Open-Supervised-Device-Protokoll<\/a>, das es erm\u00f6glicht, die Schl\u00fcsselsequenz verschl\u00fcsselt zu \u00fcbertragen. Doch diese \u201eFunktionen\u201c werden nicht verwendet. Und zwar \u2013 ich werde nicht m\u00fcde, das zu sagen \u2013, weil es g\u00fcnstiger und einfacher ist, Sicherheitsma\u00dfnahmen zu ignorieren.<\/p>\n<p>Es gibt noch eine weitere interessante <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\">Studie<\/a> dazu aus dem Jahr 2009, inklusive technischer Details. Offensichtlich wurde die Sicherheitsl\u00fccke der Karten (nicht der Kartenleser) schon im Jahr 1992 aufgezeigt, aber damals wurde vorgeschlagen, die Karten entweder zu zerlegen oder zu r\u00f6ntgen. Dazu musste man sie erst einmal in die H\u00e4nde bekommen. Doch nun ist der Hack mit einem kleinen Ger\u00e4t von der Gr\u00f6\u00dfe einer M\u00fcnze m\u00f6glich. Das nenne ich Fortschritt!<\/p>\n<h3>Immunit\u00e4t f\u00fcr Microsoft. Die Feinheiten des Windows Server Update Service.<\/h3>\n<p><a href=\"https:\/\/threatpost.com\/manipulating-wsus-to-own-enterprises\/\" target=\"_blank\" rel=\"noopener nofollow\">Der Threatpost-Artikel<\/a>. Das eigentliche <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\">Whitepaper<\/a> der Forscher.<\/p>\n<p>Der Windows Server Update Service (WSUS) erlaubt es gro\u00dfen Firmen, die Updates f\u00fcr Computer \u00fcber einen internen Server zu zentralisieren, statt eine Quelle au\u00dferhalb des Firmennetzwerks zu verwenden. Und das ist ein sehr zuverl\u00e4ssiges und ausreichend sicheres System. Zun\u00e4chst m\u00fcssen alle Updates von Microsoft signiert sein, und dann wird die Kommunikation zwischen dem Firmen-Update-Server und dem Server des Herstellers per SSL verschl\u00fcsselt.<\/p>\n<p>Das ist ein recht einfaches System. Die Firmenserver erhalten eine Liste von Updates als XML-Datei, in der steht, was, wo und wie herunterzuladen ist. Doch diese erste Interaktion passiert im Klartext. Nein, das ist nicht ganz richtig: Sie <strong>muss<\/strong>\u00a0verschl\u00fcsselt sein und wenn so ein WSUS eingef\u00fchrt wird, wird dem Administrator sehr empfohlen, die Verschl\u00fcsselung einzuschalten. Standardm\u00e4\u00dfig ist sie aber ausgeschaltet.<\/p>\n<p>Das ist nicht so wahnsinnig schlimm, denn es ist nicht einfach, die \u201eAnweisungen\u201c zu ersetzen. Doch wenn ein Angreifer bereits die M\u00f6glichkeit hat, den Datenverkehr abzufangen (also bereits eine Man-in-the-Middle-Attacke l\u00e4uft), ist auch das m\u00f6glich. Die Forscher Paul Stone und Alex Chapman haben herausgefunden, dass man durch das Ersetzen der Anweisungen beliebigen Code mit hohen Privilegien auf dem aktualisierten System ausf\u00fchren kann. Nein, Microsoft pr\u00fcft nat\u00fcrlich immer noch die digitalen Zertifikate, aber dabei werden die Zertifikate jeder Firma akzeptiert. So kann man zum Beispiel das PsExec-Utility vom SysInternals-Kit schmuggeln und mit dessen Hilfe dann alles starten.<\/p>\n<p>Warum ist das m\u00f6glich? Der springende Punkt ist, dass das Einschalten von SSL beim Einrichten des WSUS nicht automatisiert werden kann, da man daf\u00fcr ein Zertifikat generieren muss. Wie die Forscher anmerken, kann Microsoft in diesem Fall nichts anders tun, als das Einschalten von SSL zu empfehlen. Es sieht also so aus, als g\u00e4be es da eine Sicherheitsl\u00fccke und gleichzeitig auch nicht. Und man kann nichts dagegen machen. Und niemand hat Schuld, au\u00dfer dem Administrator.<\/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>Kaspersky Lab entdeckte zudem die <a href=\"https:\/\/securelist.com\/blog\/incidents\/33002\/flame-replication-via-windows-update-mitm-proxy-server-18\/\" target=\"_blank\" rel=\"noopener\">Spyware Flame, die ebenfalls Windows Update f\u00fcr die Infizierung nutzt<\/a>, allerdings auf eine andere Art: Sie schickt einen abgefangenen und gef\u00e4lschten Proxy-Request an die Microsoft-Server und die gelieferten Antwort-Dateien sind dann ein bisschen ver\u00e4ndert, obwohl manche davon wirklich vom Hersteller signiert sind.<\/p>\n<h3>Reverse-Engineering und Schmerz<\/h3>\n<p><a href=\"https:\/\/threatpost.com\/oracle-cso-you-must-not-reverse-engineer-our-code\" target=\"_blank\" rel=\"noopener nofollow\">Der Threatpost-Srtikel<\/a>. Der Original-Post von Oracle (Google <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\">Cache<\/a> und <a href=\"http:\/\/seclists.org\/isn\/2015\/Aug\/4\" target=\"_blank\" rel=\"noopener nofollow\">eine weitere Kopie<\/a> \u2014 das Internet vergisst nie).<\/p>\n<p>Die beiden oben zitierten Pr\u00e4sentationen von der Black-Hack-Konferenz h\u00e4ngen zusammen, da die Autoren der Studien \u2013 Sicherheits-Experten \u2013 Fehler in Technologien oder Produkten entdeckt haben, die von jemand anderem entwickelt worden waren. Sie haben ihre Erkenntnisse ver\u00f6ffentlicht und im Fall von BLEKey auch den gesamten Code und die Hardware vorgestellt. Das ist die Standardvorgehensweise der IT-Sicherheitsbranche, aber nicht jedem gef\u00e4llt das.<\/p>\n<p>Ich will das nicht bewerten, also reicht es wohl, wenn ich sage, dass das ein sehr kontroverses Thema ist. Ist es in Ordnung, den Code anderer zu analysieren und unter welchen Bedingungen ist das richtig? Wie soll man Informationen zu Sicherheitsl\u00fccken ver\u00f6ffentlichen, ohne Schaden anzurichten? Werde ich vielleicht f\u00fcr die gefundenen Fehler sogar bezahlt? Rechtliche Beschr\u00e4nkungen, krimineller Kodex und ungeschriebene Gesetze der Branche \u2013 sie alle beeinflussen das.<\/p>\n<p>Ein Post von Mary Ann Davidson, Chief Security Officer bei Oracle, hat k\u00fcrzlich einen ziemlichen Wirbel ausgel\u00f6st. Der Titel des Artikels lautete \u201e<em>Nein, Du darfst wirklich nicht\u201c<\/em> und er wandte sich fast ausschlie\u00dflich an die Kunden des Unternehmens (nicht an die Branche insgesamt), die Informationen \u00fcber Sicherheitsl\u00fccken eingesandt haben, die sie in den Produkten des Herstellers gefunden hatten.<\/p>\n<p>Eigentlich w\u00e4re es wert, den ganzen Text des Artikels vom 10. August zu zitieren, aber hier die Hauptsache: Wenn ein Kunde eine Sicherheitsl\u00fccke nur durch Reverse Engineering entdecken k\u00f6nne, verletze er damit die Lizenzvereinbarung, und das sei nicht rechtm\u00e4\u00dfig.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2015\/08\/06133737\/security-week-33-sobchak.png\" alt=\"\" width=\"600\" height=\"700\"><\/p>\n<p>Zitat:<\/p>\n<p><em>Ein Kunde darf den Code nicht analysieren, um zu pr\u00fcfen, ob es eine Kontrolle gibt, die einen Angriff verhindert, den das Scanning-Tool meldet (wahrscheinlich ein False Positive). Ein Kunde darf keinen Patch f\u00fcr das Problem erstellen \u2013 nur der Hersteller darf das. Ein Kunde verletzt ganz sicher die Lizenzvereinbarung, wenn er ein Tool verwendet, das eine statische Analyse durchf\u00fchrt (die gegen den Quellcode l\u00e4uft)<\/em>.<\/p>\n<p>Die \u00f6ffentliche Reaktion war <a href=\"https:\/\/twitter.com\/nicboul\/status\/631183093580341248\" target=\"_blank\" rel=\"noopener nofollow\">so<\/a>:<\/p>\n<p>https:\/\/twitter.com\/nicboul\/status\/631183093580341248<\/p>\n<p>Und <a href=\"https:\/\/twitter.com\/briankrebs\/status\/631257607530020864\" target=\"_blank\" rel=\"noopener nofollow\">so<\/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>Und sogar <a href=\"https:\/\/twitter.com\/headhntr\/status\/631081198534664192\" target=\"_blank\" rel=\"noopener nofollow\">so<\/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>Kurz, der Beitrag wurde nach einem Tag wieder gel\u00f6scht, und zwar aufgrund von \u201eUnstimmigkeiten in Bezug auf die [offiziellen] Ansichten zur Interaktion mit Kunden\u201c (aber das Web vergisst nicht). Denken Sie daran, dass Oracle auch Java entwickelt und nur die Faulsten keine Java-Sicherheitsl\u00fccken ausnutzen. Vor drei Jahren <a href=\"https:\/\/securelist.com\/analysis\/publications\/57888\/kaspersky-lab-report-java-under-attack\/\" target=\"_blank\" rel=\"noopener\">z\u00e4hlten wir 12 Monate lang die in Java neu entdeckten Sicherheitsl\u00fccken \u2013 es waren 160<\/a>!<\/p>\n<p>In einer perfekten Welt sollte die Suche und das Schlie\u00dfen von Software-Sicherheitsl\u00fccken vielleicht wirklich exklusiv den Herstellern vorbehalten werden. Doch in der realen Welt passiert es immer wieder, dass die Menschen, die f\u00fcr solche Dinge verantwortlich sind, eher dem Prinzip \u201eBienen gegen Honig\u201c folgen.<\/p>\n<p>Aber lassen wir doch auch die andere Seite zu Wort kommen: In der letzten Woche sprach Jeff Moss, Gr\u00fcnder der Black-Hat-Konferenz, <a href=\"https:\/\/threatpost.com\/software-liability-is-inevitable\/\" target=\"_blank\" rel=\"noopener nofollow\">dar\u00fcber, dass Software-Hersteller f\u00fcr Fehler in ihrem Code verantwortlich seien<\/a>. Er sagte, es sei an der Zeit, die Hinweise in EULAs zu l\u00f6schen, die besagen, dass der Hersteller keine Haftung gegen\u00fcber dem Kunden habe. Das ist eine interessante Erkl\u00e4rung, aber nicht weniger \u00fcberheblich als die Forderung, \u201eDisassembler zu verbieten\u201c. Bisher ist nur eines klar: Wenn Anwender (Firmen und Einzelpersonen), Hersteller und Forscher sich \u00fcberhaupt verstehen k\u00f6nnen, wird das nicht \u00fcber protzige Aussagen und Twitter-Witze passieren.<\/p>\n<h3>Was gab es sonst noch?<\/h3>\n<p>Eine weitere Black-Hat-<a href=\"https:\/\/threatpost.com\/researchers-unveil-square-reader-mobile-pos-hacks\/\" target=\"_blank\" rel=\"noopener nofollow\">Pr\u00e4sentation<\/a> \u00fcber das Hacken des Square Readers, dem Ding, das man mit dem Smartphone verbinden kann, um den Sushi-Lieferservice zu bezahlen. Muss \u00fcberarbeitet werden.<\/p>\n<p>Und in Lenovo-Laptops wurde ein weiteres Hersteller-<a href=\"https:\/\/threatpost.com\/lenovo-hit-with-criticism-over-second-rootkit-like-utility\/114261\" target=\"_blank\" rel=\"noopener nofollow\">Rootkit<\/a> entdeckt (nicht in allen Modellen, aber in einigen). <a href=\"https:\/\/threatpost.com\/lenovo-superfish-certificate-password-cracked\/111165\" target=\"_blank\" rel=\"noopener nofollow\">Hier die fr\u00fchere Geschichte<\/a>.<\/p>\n<h3>Oldies<\/h3>\n<p><img loading=\"lazy\" decoding=\"async\" class=\" alignright\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2015\/08\/06133737\/infosec-digest-32-book1-234x300-1.jpg\" alt=\"\" width=\"234\" height=\"300\"><\/p>\n<p>Die Schadprogrammfamilie \u201eSmall\u201c<\/p>\n<p>Standard-Resident-Viren, werden am Ende von .com-Dateien angef\u00fcgt (au\u00dfer bei Small-114, -118, -122, die an den Anfang geschrieben werden), wenn diese in den Speicher geladen werden. Die meisten Exemplare der Virenfamilie verwenden die Befehle POPA und PUSHA der 80\u00d786-Prozessoren. Small-132 und -149 infizieren bestimmte Dateien fehlerhaft. Sie stammen von unterschiedlichen Autoren. Offensichtlich kann der Ursprung der Small-Familie als Wettbewerb um den k\u00fcrzesten, speicherresidenten Virus f\u00fcr MS-DOS gesehen werden. Bleibt nur noch, die Gr\u00f6\u00dfe des Preises festzulegen.<\/p>\n<p><em>Zitat aus \u201eMS-DOS-Computerviren\u201c von Eugene Kaspersky, 1992, Seite 45.<\/em><\/p>\n<p><em>Hinweis: Diese Kolumne spiegelt die pers\u00f6nliche Meinung des Autors wider. Diese kann, muss aber nicht mit der Position von Kaspersky Lab \u00fcbereinstimmen. Das ist Gl\u00fccksache.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>In diesem R\u00fcckblick finden sich zwei Themen, die augenscheinlich nichts miteinander zu tun haben, aber dennoch etwas gemeinsam haben: n\u00e4mlich, dass Sicherheitsl\u00fccken manchmal vom Widerwillen kommen, Sicherheitsma\u00dfnahmen zu ergreifen.<\/p>\n","protected":false},"author":53,"featured_media":5977,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2711,6],"tags":[608,1285,1582,25,1651,1597,1600,1653,1598,1596,1599,1012],"class_list":{"0":"post-5975","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-threats","8":"category-news","9":"tag-black-hat","10":"tag-blackhat","11":"tag-hacks","12":"tag-microsoft","13":"tag-news","14":"tag-oracle","15":"tag-reverse-engineering","16":"tag-security","17":"tag-sicherheitswoche","18":"tag-threatpost","19":"tag-turen","20":"tag-updates"},"hreflang":[{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/security-week-digest-33\/5975\/"},{"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":"es","url":"https:\/\/www.kaspersky.es\/blog\/security-week-digest-33\/6659\/"},{"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":"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.de\/blog\/tag\/black-hat\/","name":"Black Hat"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/5975","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/users\/53"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/comments?post=5975"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/5975\/revisions"}],"predecessor-version":[{"id":11276,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/5975\/revisions\/11276"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media\/5977"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media?parent=5975"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/categories?post=5975"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/tags?post=5975"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}