{"id":6005,"date":"2015-08-24T11:25:07","date_gmt":"2015-08-24T11:25:07","guid":{"rendered":"https:\/\/kasperskydaily.com\/germany\/?p=6005"},"modified":"2022-05-26T17:53:12","modified_gmt":"2022-05-26T15:53:12","slug":"security-week-34","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/security-week-34\/6005\/","title":{"rendered":"Sicherheitswoche 34: Man kann nicht einfach patchen\u2026"},"content":{"rendered":"<p>Was f\u00fcr eine schlimme Woche war das f\u00fcr die Sicherheitsbranche. Nach <a href=\"https:\/\/www.kaspersky.com\/blog\/tag\/black-hat\/\" target=\"_blank\" rel=\"noopener nofollow\">gefundenen Fehlern<\/a>, Zero-Day-L\u00fccken und <a href=\"https:\/\/www.kaspersky.com\/blog\/tag\/def-con\/\" target=\"_blank\" rel=\"noopener nofollow\">anderen von Forschern begehrten Kuriosit\u00e4ten<\/a>, kommen die schmerzlichen Nachwehen, und all das m\u00fcndet in angreifbare Software. Das ist wichtig, l\u00f6st aber oft auch Langeweile aus. Immer wenn mir unser News-Blog <a href=\"http:\/\/www.threatpost.com\" target=\"_blank\" rel=\"noopener nofollow\">Threatpost<\/a> die drei wichtigsten Sicherheitsnachrichten vorstellt, bei denen es um das Patchen von Sicherheitsl\u00fccken geht, ist das meist schwer verdaulich.<\/p>\n<p>Nun, es ist deshalb nicht weniger wichtig! Es hei\u00dft, dass man nicht einfach so eine Sicherheitsl\u00fccke finden kann, aber noch schwieriger ist es, diese zu schlie\u00dfen, ohne dabei alles andere zu demolieren. Man kann viele Gr\u00fcnde finden, warum ein bestimmter Fehler nicht gepatcht werden kann \u2013 zumindest nicht sofort, oder im n\u00e4chsten Vierteljahr, oder\u2026 jemals. Doch das Problem muss trotzdem gel\u00f6st werden. Die heutige Hitparade bringt uns drei Geschichten zu Fehlern, die bedauerlicherweise noch nicht gepatcht wurden.<\/p>\n<p>Kurz zur Erinnerung: Das Threatpost-Team w\u00e4hlt jede Woche drei wichtige Neuigkeiten aus, die ich hier rastlos kommentiere. Die vorhergehenden Kommentare finden Sie <a href=\"https:\/\/www.kaspersky.com\/blog\/tag\/security-week\/\" target=\"_blank\" rel=\"noopener nofollow\">hier<\/a>.<\/p>\n<h3>Noch ein Android-Fehler, diesmal in Google Admin<\/h3>\n<p><a href=\"https:\/\/threatpost.com\/zero-day-in-android-admin-app-can-bypass-sandbox\/114274\" target=\"_blank\" rel=\"noopener nofollow\">Der Threatpost-Artikel<\/a>. Die <a href=\"https:\/\/labs.mwrinfosecurity.com\/advisories\/2015\/08\/13\/sandbox-bypass-through-google-admin-webview\/\" target=\"_blank\" rel=\"noopener nofollow\">Forschungsarbeit von MWR<\/a>.<\/p>\n<p><em>Was wurde gefunden?<\/em><\/p>\n<p>Ist Ihnen schon einmal aufgefallen, dass die Liebesbriefe von solchen Fehlern immer haufenweise eintrudeln? Wow, <a href=\"https:\/\/www.kaspersky.com\/blog\/blackhat-jeep-cherokee-hack-explained\/\" target=\"_blank\" rel=\"noopener nofollow\">ein Auto ist gehackt worden<\/a>? Lasst uns <a href=\"https:\/\/www.kaspersky.com\/blog\/tesla-s-hacked-and-patched\/\" target=\"_blank\" rel=\"noopener nofollow\">ein Dutzend weiterer Sicherheitsl\u00fccken in Autos finden<\/a>! Das gleiche Muster kann man auch bei den aktuellen News rund um Android feststellen. Erst <a href=\"https:\/\/threatpost.com\/android-stagefright-flaws-put-950-million-devices-at-risk\/\" target=\"_blank\" rel=\"noopener nofollow\">Stagefright<\/a>, dann ein paar kleinere Fehler, und jetzt Google Admin.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2015\/08\/06133748\/security-week-34-kid.jpg\" alt=\"\" width=\"1280\" height=\"853\"><\/p>\n<p>Google Admin, eine von Androids System-Apps, kann URLs aus anderen Apps akzeptieren \u2013 und wie sich jetzt herausstellte wirklich jede, selbst solche, die mit \u201efile:\/\/\u201c beginnen. Dadurch k\u00f6nnen ganz einfache Netzwerkaktionen, etwa das \u00d6ffnen von Webseiten, zu kompletten Dateimanager-Dingen werden. Sollten eigentlich nicht alle Android-Apps voneinander isoliert sein? Sind sie nicht, und Google Admin hat h\u00f6here Rechte als andere Apps. Wenn man ihr also eine sch\u00e4dliche URL unterjubelt, kann eine App der Sandbox entkommen und pl\u00f6tzlich auf private Daten zugreifen.<\/p>\n<p><em>Wie wurde das gepatcht?<\/em><\/p>\n<p>Lassen Sie mich zun\u00e4chst kurz auf die unabh\u00e4ngige Forschungsarbeit eingehen, die die Sicherheitsl\u00fccke aufgedeckt hat. Das war bereits im M\u00e4rz. Gleichzeitig wurde auch Google dar\u00fcber informiert. F\u00fcnf Monate sp\u00e4ter pr\u00fcften die Forscher die L\u00fccke erneut und mussten feststellen, dass sie nach wie vor nicht geschlossen war. Am 13. August wurde sie daher \u00f6ffentlich gemacht, um Google dazu zu bringen, den Patch endlich zu ver\u00f6ffentlichen.<\/p>\n<p>\u00dcbrigens hat Google ein eigenes Forschungsteam, das ebenfalls nach solchen Fehlern sucht, und das nicht nur in der hauseigenen Software. Das so genannte <a href=\"http:\/\/googleprojectzero.blogspot.ru\/\" target=\"_blank\" rel=\"noopener nofollow\">Project Zero<\/a> gibt normalerweise 90 Tage Frist, bevor es Fehler ver\u00f6ffentlicht \u2013 wobei man sich fragen muss, ob Google es \u00fcberhaupt schafft, Fehler innerhalb von 90 Tagen zu verbessern.<\/p>\n<p>Aber bei Google Admin ging irgendetwas schief: Zum einen war etwas komplett falsch, zum anderen wissen wir alle, dass ein Patch das Problem nicht unbedingt auf allen Android-Ger\u00e4ten l\u00f6st. Sie fragen nach <a href=\"https:\/\/threatpost.com\/google-plans-monthly-security-updates-for-nexus-phones\/114148\" target=\"_blank\" rel=\"noopener nofollow\">monatlichen Sicherheits-Updadtes<\/a>? Aber wie kann man dann ein halbes Jahr an einem einzigen Patch arbeiten? H\u00f6rt, h\u00f6rt.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2015\/08\/06133747\/security-week-34-kitten.jpg\" alt=\"\" width=\"1280\" height=\"1280\"><\/p>\n<h3>Offene Sicherheitsl\u00fccke in SCADA von Schneider Electric<\/h3>\n<p><a href=\"https:\/\/threatpost.com\/risky-schneider-electric-scada-vulnerabilities-remain-unpatched\/\" target=\"_blank\" rel=\"noopener nofollow\">Der Threatpost-Artikel<\/a>. Die <a href=\"https:\/\/ics-cert.us-cert.gov\/alerts\/ics-alert-15-224-02\" target=\"_blank\" rel=\"noopener nofollow\">Warnung von ICS-CERT<\/a>.<\/p>\n<p>Willkommen in der faszinierenden Welt der kritischen Infrastrukturen! Setzen Sie sich, machen Sie es sich bequem, dr\u00fccken Sie nicht auf den roten Knopf und ber\u00fchren Sie niemals die Kabel, die aus diesem Ding dort herausstehen. Ja, die sollen dort herausstehen. Das ist ok. Richtig, das ist schon seit ewigen Zeiten so. Wenn Sie diese Kabel ber\u00fchren, sind wir alle verloren.<\/p>\n<p>SCADA-Systeme sind ein Teil kritischer Infrastrukturen, die daf\u00fcr verantwortlich sind, wichtige Dinge zu steuern \u2013 von der Heizung in Ihrem Appartementgeb\u00e4ude bis zu Kernkraftwerken. Solche Systeme sollen nicht ver\u00e4ndert, ausgeschaltet oder neu gestartet werden. Man spielt nicht an ihren Parametern herum und man ber\u00fchrt einfach nichts!<\/p>\n<blockquote class=\"twitter-pullquote\"><p>Sicherheitswoche 34: Ungepatchte #Sicherheitsl\u00fccken in #Android, #Mac OS X, Schneider Electric #SCADA<\/p><a href=\"https:\/\/twitter.com\/share?url=https%3A%2F%2Fkas.pr%2F6KDt&amp;text=Sicherheitswoche+34%3A+Ungepatchte+%23Sicherheitsl%C3%BCcken+in+%23Android%2C+%23Mac+OS+X%2C+Schneider+Electric+%23SCADA\" class=\"btn btn-twhite\" data-lang=\"en\" data-count=\"0\" target=\"_blank\" rel=\"noopener nofollow\">Tweet<\/a><\/blockquote>\n<p>Und bevor Sie selbst etwas daran \u00e4ndern, sollten Sie <a href=\"https:\/\/securelist.com\/analysis\/publications\/36594\/securing-critical-information-infrastructure-trusted-computing-base\/\" target=\"_blank\" rel=\"noopener\">unseren Artikel dazu lesen<\/a>. Denn auch wenn solche Systeme wahnsinnig kritisch sind, laufen sie dennoch recht h\u00e4ufig auf regul\u00e4ren PCs mit dem guten, alten Windows. Anders als Firmen, die ihre Hardware und Software zumindest alle f\u00fcnf Jahre oder so erneuern, laufen einige Industrieroboter oder Zentrifugen, die ein paar t\u00f6dliche Chemikalien verarbeiten, 24 Stunden am Tag, und das jahrzehntelang.<\/p>\n<p><em>Was wurde gefunden?<\/em><\/p>\n<p>Nun, in einem dieser Systeme wurde eine ganze Menge Fehler entdeckt, und zwar im <a href=\"http:\/\/www.schneider-electric.com\/en\/product-range\/1468-modicon-m340\/\" target=\"_blank\" rel=\"noopener nofollow\">Modicon M340<\/a> von Schneider Electric, in der PLC Station P34 CPU. Die Sicherheitsl\u00fccken erlauben es einem Hacker, die Kontrolle \u00fcber alles zu \u00fcbernehmen, das von dem System gesteuert wird. Auch ein recht h\u00e4ufiger Fehler wurde gefunden (der \u00fcbrigens regelm\u00e4\u00dfig auch in Routern und Ger\u00e4ten des Internet der Dinge entdeckt wird), den wir als Hard-Coder-Rechte bezeichnen.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Risky Schneider Electric SCADA Vulnerabilities Remain Unpatched <a href=\"https:\/\/t.co\/2oGDTbr7qE\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/2oGDTbr7qE<\/a> via <a href=\"https:\/\/twitter.com\/threatpost?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">@threatpost<\/a> <a href=\"http:\/\/t.co\/eyPAY6Aikn\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/eyPAY6Aikn<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/633365728075378688?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 17, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Was auch immer fest in das industrielle SCADA-System codiert wurde, bleibt geheim (aus offensichtlichen Gr\u00fcnden), aber wir k\u00f6nnen davon ausgehen, dass es sich um Standard-Login-Daten handelt, die ein Hersteller bietet, um leichtere Wartung zu erm\u00f6glichen. Oder ein Hersteller vergisst einfach, ein Test-Passwort aus dem Code zu l\u00f6schen. Oder jede andere Ausrede, die ihnen noch einf\u00e4llt.<\/p>\n<p><em>Wie wurde das gepatcht?<\/em><\/p>\n<p>Es wurde nicht gepatcht. Zwei Wochen sind vergangen, seit der Forscher Aditya Sood die Sicherheitsl\u00fccke auf der <a href=\"https:\/\/www.kaspersky.com\/blog\/tag\/def-con\/\" target=\"_blank\" rel=\"noopener nofollow\">DEF CON<\/a> aufgedeckt hat, aber noch ist kein Patch in Sicht. Das ist verst\u00e4ndlich: Ein Hersteller steht hier vor einer schweren Aufgabe, denn die Herausforderung, einen Patch zu erstellen, wird hier noch herausfordernder, da die Systeme beim Kunden daf\u00fcr oft Ausfallzeiten ben\u00f6tigen, und das ist bei vielen Kunden einfach nicht m\u00f6glich.<\/p>\n<p>Wie lange w\u00fcrde das Ausliefern des Patches also dauern? Wie lange m\u00fcsste der Kunde den Stillstand hinnehmen? Funktioniert anschlie\u00dfend \u00fcberhaupt alles? Wurden alle Besonderheiten der Endpoint-Ger\u00e4te in Betracht gezogen? Alles in Allem eine Qual \u2013 wobei das dennoch eine schlechte Ausrede daf\u00fcr ist, Fehler nicht auszubessern. Und es wurde schon oft genug bewiesen, dass das Trennen kritischer Infrastrukturen vom Internet oder der Schutz durch eine Firewall <a href=\"https:\/\/www.kaspersky.com\/blog\/when-going-offline-doesnt-help\/9078\/\" target=\"_blank\" rel=\"noopener nofollow\">nicht ausreichen<\/a>.<\/p>\n<div style=\"width: 650px\" class=\"wp-caption aligncenter\"><img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/media.kasperskydaily.com\/wp-content\/uploads\/sites\/96\/2015\/08\/06133747\/security-week-34-keynote.jpg\" alt=\"Entwickler bei der Enth\u00fcllung\" width=\"640\" height=\"480\"><p class=\"wp-caption-text\">Entwickler bei der Enth\u00fcllung<em>\u00a0<\/em><\/p><\/div>\n<h3>Ein ungepatchter Fehler in Mac OS X<\/h3>\n<p><a href=\"https:\/\/threatpost.com\/inside-the-unpatched-os-x-vulnerabilities\/114344\" target=\"_blank\" rel=\"noopener nofollow\">Der Threatpost-Artikel<\/a>.<\/p>\n<p>Und wieder kommen wir zu dem Thema der verantwortungsbewussten Ver\u00f6ffentlichung von Sicherheitsl\u00fccken. Beim oben genannten Google-Fehler waren die Forscher f\u00fcnf Monate lang still, bevor sie den Fehler \u00f6ffentlich machten. Und das, obwohl sich Google selbst nur eine Frist von 90 Tagen gibt. Wie lange sollte man also warten? Wie viel Zeit gibt man einem Entwickler, eine Sicherheitsl\u00fccke zu schlie\u00dfen?<\/p>\n<p>K\u00f6nnte eine zu lange Frist die Entwickler nur dazu bringen, den Patch immer wieder zu verschieben? Oder w\u00fcrde die sofortige Ver\u00f6ffentlichung der Sicherheitsl\u00fccke den Entwickler dazu bringen, m\u00f6glichst schnell einen Patch zu entwickeln? Wie auch immer, es gibt keinen Standard \u2013 und dennoch sind sich alle Forscher einig, dass es nicht richtig ist, eine Sicherheitsl\u00fccke zu ver\u00f6ffentlichen, ohne vorher den entsprechenden Entwickler zu informieren.<\/p>\n<p><em>Was wurde gefunden?<\/em><\/p>\n<p>Hier ein Beispiel daf\u00fcr, wenn ein Entwickler nicht oder mit zu kurzer Frist informiert wird und nicht genug Zeit f\u00fcr eine entsprechende Reaktion hat\u2026 Der 18 Jahre alte Sicherheitsforscher Luca Todesco ver\u00f6ffentlichte Details zu einer ernsten Sicherheitsl\u00fccke in Mac OS X Yosemite und Mavericks (10.9.5 \u2013 10.10.5), die es einem Angreifer erlaubt, Root-Rechte auf dem angegriffenen Ger\u00e4t zu erlangen.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Inside the unpatched OS X vulnerabilities <a href=\"https:\/\/t.co\/4mUVYrtVwa\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/4mUVYrtVwa<\/a><\/p>\n<p>\u2014 Eugene Kaspersky (@e_kaspersky) <a href=\"https:\/\/twitter.com\/e_kaspersky\/status\/634056512868978688?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 19, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Der Fehler ist allerdings nicht aus der Ferne ausnutzbar: Der Angreifer muss den Nutzer dazu bringen, einen Exploit herunterzuladen und zu starten \u2013 aber das ist leider gar nicht so schwer. Es gibt auch bereits einen Proof-of-Concept. Hacker m\u00fcssen den nur noch nehmen und einsetzen.<\/p>\n<p><em>Wie wurde das gepatcht?<\/em><\/p>\n<p>Tja, es wurde noch nicht gepatcht. Laut dem Forscher hat sich Apple dazu nicht ge\u00e4u\u00dfert, obwohl er das Unternehmen mehrmals kontaktierte. Dass er die Sicherheitsl\u00fccke bereits \u00f6ffentlich gemacht hat, macht ihm keine Sorgen: Er habe nur eine neue M\u00f6glichkeit f\u00fcr das Jailbreaking <a href=\"https:\/\/twitter.com\/qwertyoruiop\/status\/632966294804017153\" target=\"_blank\" rel=\"noopener nofollow\">erkundet<\/a>, nicht mehr. Das sei keine gro\u00dfe Sache, sagt er.<\/p>\n<p>Nun, das ist ein schlechter Vergleich: Einen Jailbreak machen Nutzer, die genau wissen, was sie tun, absolut freiwillig. Man kann einen iPhone-Nutzer nicht einfach so dazu bringen, sein Handy zu jailbreaken, au\u00dfer der Nutzer will das. Und bei Todescos Fehler ist das nicht immer der Fall. Kein Wunder, dass er sich harte <a href=\"https:\/\/twitter.com\/engadget\/status\/633385331476287489\" target=\"_blank\" rel=\"noopener nofollow\">Kritik<\/a> von seinen Kollegen anh\u00f6ren musste:<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"en\" dir=\"ltr\">Developer reveals Mac security hole without telling Apple <a href=\"http:\/\/t.co\/siVCVIP3Ff\" target=\"_blank\" rel=\"noopener nofollow\">http:\/\/t.co\/siVCVIP3Ff<\/a> <a href=\"http:\/\/t.co\/UUrECGbwJu\" target=\"_blank\" rel=\"noopener nofollow\">pic.twitter.com\/UUrECGbwJu<\/a><\/p>\n<p>\u2014 Engadget (@engadget) <a href=\"https:\/\/twitter.com\/engadget\/status\/633385331476287489?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 17, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/p>\n<p>Unklar ist nach wie vor, ob dieser Fehler das neue Mac OS X El Capitan beeintr\u00e4chtigen wird. Warten wir also auf den Patch.<\/p>\n<h3>Was gab es sonst noch?<\/h3>\n<p>Microsoft hat einen Fehler im Internet Explorer <a href=\"https:\/\/threatpost.com\/emergency-ie-patch-fixes-vulnerability-under-attack\/\" target=\"_blank\" rel=\"noopener nofollow\">ausgebessert<\/a> (naja, wenigstens hat irgendjemand irgendetwas ausgebessert), indem ein dringender Patch au\u00dfer der Reihe ver\u00f6ffentlicht wurde \u2013 der zweite in diesem Monat.<\/p>\n<p>Die privaten Daten, die Hacker von der Seitensprung-Webseite Ashley Madison <a href=\"https:\/\/www.kaspersky.com\/blog\/cheating-website-hacked\/\" target=\"_blank\" rel=\"noopener nofollow\">gestohlen hatten<\/a>, sind nun <a href=\"https:\/\/www.kaspersky.com\/blog\/ashley-madison-data-finally-leaked\/\" target=\"_blank\" rel=\"noopener nofollow\">online<\/a>, wie es die Hacker angek\u00fcndigt hatten.<\/p>\n<p>https:\/\/twitter.com\/kaspersky\/status\/634349398198218752<\/p>\n<p>Kaspersky Lab hat <a href=\"https:\/\/securelist.com\/blog\/research\/71876\/new-activity-of-the-blue-termite-apt\/\" target=\"_blank\" rel=\"noopener\">Blue Termite entdeckt<\/a>, eine gro\u00dfe Cyber-Spionagekampagne, der in Japan bereits einige zum Opfer gefallen sind. Es bleibt einfach nicht unentdeckt, wenn Cyber-Spione, die schon seit \u00fcber zwei Jahren aktiv sind, pl\u00f6tzlich ihre Aktivit\u00e4ten verst\u00e4rken, nachdem sie einen Flash-Exploit in die H\u00e4nde bekommen haben, der als Teil eines Data-Dumps ver\u00f6ffentlicht wurde, der wiederum vom <a href=\"https:\/\/threatpost.com\/apt-group-exploiting-hacking-team-flash-zero-day\/\" target=\"_blank\" rel=\"noopener nofollow\">\u00a0Hacking Team gestohlen worden war<\/a>.<\/p>\n<blockquote class=\"twitter-tweet\" data-width=\"500\" data-dnt=\"true\">\n<p lang=\"fr\" dir=\"ltr\"><a href=\"https:\/\/twitter.com\/hashtag\/BlueTermite?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#BlueTermite<\/a> <a href=\"https:\/\/twitter.com\/hashtag\/APT?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#APT<\/a> exploits <a href=\"https:\/\/twitter.com\/hashtag\/Flash?src=hash&amp;ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">#Flash<\/a> CVE-2015-5119 exploit to further infection <a href=\"https:\/\/t.co\/Fj0eAJkCTH\" target=\"_blank\" rel=\"noopener nofollow\">https:\/\/t.co\/Fj0eAJkCTH<\/a><\/p>\n<p>\u2014 Kaspersky (@kaspersky) <a href=\"https:\/\/twitter.com\/kaspersky\/status\/634387066684600320?ref_src=twsrc%5Etfw\" target=\"_blank\" rel=\"noopener nofollow\">August 20, 2015<\/a><\/p><\/blockquote>\n<p><script async src=\"https:\/\/platform.twitter.com\/widgets.js\" charset=\"utf-8\"><\/script><\/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\/06133746\/infosec-digest-32-book1-234x300.jpg\" alt=\"\" width=\"234\" height=\"300\"><\/p>\n<p>\u201eJustice\u201c<\/p>\n<p>Sehr gef\u00e4hrlich; bef\u00e4llt .COM-Dateien, wenn diese von den DOS-Funktionen 43h, 4Bh, 3Dh, 56h aufgerufen werden. Das Schadprogramm wird an das Ende der Dateien geschrieben und ver\u00e4ndert\u00a0 f\u00fcnf Byte an deren Anfang (NOP; NOP; JMP Loc_Virus). Der Prozess zur Kompromittierung von COMMAND.COM nutzt die gleiche Methode wie der Lehigh-Virus. Stiehlt regelm\u00e4\u00dfig Daten, wenn diese auf das Laufwerk geschrieben werden, und schreibt sie in einen anderen Sektor. Enth\u00e4lt den Text \u201eAND JUSTICE FOR ALL\u201c. \u00dcbernimmt int 13h und int 21h.<\/p>\n<p><em>Zitat aus \u201eMS-DOS-Computerviren\u201c von Eugene Kaspersky, 1992, Seite 72.<\/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>Man kann viele Gr\u00fcnde finden, warum ein bestimmter Fehler nicht gepatcht werden kann \u2013 zumindest nicht sofort, oder im n\u00e4chsten Vierteljahr, oder\u2026 jemals. Doch das Problem muss trotzdem gel\u00f6st werden.<\/p>\n","protected":false},"author":53,"featured_media":6006,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2711,6],"tags":[55,109,1585,1586,810,39,34,1111,1606,1605,1653,382],"class_list":{"0":"post-6005","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-threats","8":"category-news","9":"tag-android","10":"tag-apple","11":"tag-def-con","12":"tag-defcon23","13":"tag-fehler","14":"tag-google","15":"tag-os-x","16":"tag-patches","17":"tag-scada","18":"tag-schneider-electric","19":"tag-security","20":"tag-sicherheitslucken"},"hreflang":[{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/security-week-34\/6005\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/security-week-34\/5862\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/security-week-34\/6149\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/security-week-34\/6011\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/security-week-34\/6665\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/security-week-34\/6526\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/security-week-34\/8644\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/security-week-34\/9637\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/security-week-34\/4813\/"},{"hreflang":"ja","url":"https:\/\/blog.kaspersky.co.jp\/security-week-34\/8687\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/security-week-34\/8644\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/security-week-34\/9637\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/security-week-34\/9637\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.de\/blog\/tag\/android\/","name":"android"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/6005","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=6005"}],"version-history":[{"count":4,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/6005\/revisions"}],"predecessor-version":[{"id":28709,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/posts\/6005\/revisions\/28709"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media\/6006"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/media?parent=6005"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/categories?post=6005"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.de\/blog\/wp-json\/wp\/v2\/tags?post=6005"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}