Auch Apple-Mitarbeiter von Hackern erwischt
von caschy | 13 Kommentare
Diverse Zeitungen, Twitter, Facebook und wahrscheinlich noch viele andere, die einen Angriff bislang nicht bemerkten oder zugaben, sind Opfer von Hackern geworden. Bei Facebook hieß es neulich noch, dass man den Einbruch bemerkte, aber keine Daten entwendet wurden. Nun soll es laut Angaben von Reuters die Firma Apple erwischt haben.
[werbung]
Die Hacker haben, wie bei den Angriffen auf Facebook auch, eine Schwachstelle im Java-Plugin des Browsers für sich entdeckt und ausgenutzt. Über eine speziell präparierte Webseite für mobile Entwickler wurde so Schadcode auf die Rechner gebracht, Daten sollen angeblich nicht entwendet worden sein.
Apple gab mittlerweile an, dass man ein aktualisiertes Tool zum Entfernen der bösartigen Software bereitstellen wolle. Dies dürfte wohl mittlerweile der weitreichendste Angriff auf große Unternehmen in den letzten Jahren sein und ich befürchte, dass da noch mehr auf uns zukommt. Wenn Apple schon bestätigt, dass Rechner von Mitarbeitern kompromittiert wurden, dann ist das Ganze schon ein wenig größer; F-Secure mutmaßt gar, dass das Problem noch weitreichender sein könnte: infizierte Entwickler könnten ihre infizierten Apps weitergeben…
Wird geladen ...
infizierte apps?
ich glaube niemand bei den genanten firmen ist im jahre 2013 noch so dämlich und lässt im buildprozess menschenhände eingreifen oder einwirken. da wird der sourcecode von buildserver ausgechecked, compilieret, signiert und deployed. so machen sogar wir das und wir verdienen nicht einmal geld durch softwareentwicklung.
Java hat im Browser einfach nichts mehr zu suchen. Das ist doch mittlerweile fast grob fahrlässig, Java nicht vollständig im Browser zu deaktivieren.
Java = Beulenpest in Binärform
Infizierte Apps halte ich wegen den von sam schon gennanten gründen für sehr unwahrscheinlich.
Außerdem kann man auch keinen komprimitierten source code committen, es wird immer von mehreren leuten approved werden müssen.
Denke mal Apple wird auf Git, SVN oder HG setzen. Anders ist es mitlerweile auch nicht mehr möglich.
@Sam: wie willst Du denn erkennen, ob ein Tool in den Quellcode des Entwicklers 2 Zeilen eingefuegt hat und er das guten Glaubens eingecheckt hat?
@Leandros: aber glaubst Du denn, dass ein Reviewer Zeile fuer Zeile auch den Code von Dritt-Anbieter-Apps durchliest?
Wenn es auf dem Rechner des Entwicklers in den Quellcode eingetragen wurde und beim Compilieren nicht auffaellt, frage ich mich wer das erkennen soll. Tools wie Git, SVN und Co. haben damit nicht viel zu tun.
@bernd
anhand des commit logs.
Auch GIT hilft nicht dabei zu erkennrn wann welche boeswillige anwendung schadcode eingebracht hat. Und ohne den exakten zeitpunkt der komprimitierung kann auch ein entwickler bei grossen projekten nicht mehr sofort erkennen welche zeilen manipuliert wurden.
Der Commit-Log zeigt einem wann der Schadcode eingefuehrt wurde, aber er verhindert den Schadcode keinesfalls. Ausser jemand liest das Log Zeile fuer Zeile durch, was generell nicht der Fall sein wird.
@rene ouch…
wenn man die änderungen nicht nach verfolgen könnte… warum setzt man dann solche tools ein? weil es hip ist? oder cool? oder einfach nur weil apple auch so etwas nutzt und alle es dann kopieren müssen?
mach dir doch einfach mal den spass und navigiert euch durch das größte auf github gehostete projekt. und zwar nur durch die commits. https://github.com/rails/rails/commits/master
selbst wenn du den code nicht liest, wirst du feststellen, dass es zu jeder code änderung einen eintrag im commit log gibt. darum weiß dass nachgeschaltete build system auch, dass sich der code geändert hat. darum weiß der nachgeschaltete buildserver auch, dass er den source code aus-checken, compilieren und in ein deployable package verwandeln muss. darum weiß dass nachgeschaltete testsystem auch, dass die automatische tests starten muss (die werden den geheimen virus sicher nicht finden, denn dafür sind die tests auch nicht geschrieben), das nachgeschaltete testteam weiß, dass arbeit ansteht. und wenn bis hier hin niemanden der 2 zeilen virus aufgefallen ist (in welcher programmiersprache kann man einen virus in 2 zeilen schreiben?) dann könnte das testteam jetzt die erste instanz sein, die ahnungslos zur arbeit gerufen wird. auf welchen change request hin, wurden 2 zeilen code geändert und durch welche testaufgaben (automatische und manuelle) wird die codeänderung validiert?
also für mich klingt diese fantasy einfach zu amateurhaft um wahr zu sein. es mag ja sein, dass man in kleinen frickelbudel so viel von hand macht, dass ein von einem java virus eingeschleuster 2 zeilen virus nicht auffällt, aber solche arbeitsweisen auch auf apple, facebook und twitter zu übertragen klingt mehr als nach einer absurden idee…
Zwei Zeilen war ein Beispiel, aber um es zu übertreiben: Deine passwd (angenommen Java ist so nett und lässt den Browser diese auslesen), oder private Dokumente an einen Server zu senden braucht kaum mehr Zeilen. Und ich bezweifle, dass bei Apple sicher jeder POST-Request genau angeguckt wird.
Und ich glaube Du verstehst nicht ganz, wo das Problem liegt. Wenn sich niemand die Zeilen durchliest (das sollte bei iOS sicherlich so sein, aber das ist bei dem Großteil der kleineren Apps bspw. nicht der Fall), bringt dein Versionscontrol-System rein gar nichts. Für dieses System sehen die 2 Zeilen Schadcode genauso aus, wie dein absichtlich eingefügter Code. Liest Du Dir beim Checkin jede Zeile noch einmal einzeln durch, die Du eincheckst?
Und Testsysteme müssen auch nicht erkennen, ob etwas faul ist. jUnit und Co. prüfen so etwas nicht. Da gibt es zwar Sicherheitssysteme von Apple, aber auch die — das wurde oft genug gezeigt (siehe Path) — können nicht alles abfangen.
Und anzunehmen, dass es einem Testteam auffallen muss ist mehr als blauäugig. Dazu muss man nur an „File:///“ denken, um zu wissen, dass zwischen der Qualitätsmanagementtheorie und -praxis manchmal Welten liegen.
Und wie gesagt, es muss kein Virus sein. Es geht um Schadcode, und wenn jemand mein ganzes Addressbuch zu seinem Server schickt, ist das sicherlich nicht erfreulich. Wenn es das Addressbuch von einem Star ist wie vor ein paar Jahren, noch weitaus weniger.
Haha,
köstlich, btw. wen es interessiert, natürlich lassen sich Compiler, AV-Produkte, Logs, Versionskontrollsysteme usw. angreifen und manipulieren. Das ist nicht nur machbar sondern bei Angriffen eher die Regel. Darunter fallen auch Root-Kits.
Die Annahme, das wenn man etwas ins SVN eincheckt und bloss nichts mehr „händisch“ anfasst macht den Entwicklungsprozess sicher ist soweit ab vom Schlag…Made my day.
Ich empfehle.mal einen Klassiker: Ken Thompsosn „Reflections on Trusting Trust“ http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
@sam: du bist ja wirklich sehr überzeugt von der Sicherheit eures Workflows 🙂
Laut deiner Beschreibung haben professionelle Entwickler immer völlig Kontrolle über den Code, Pannen passieren nur hinterletzten Klitschen… Ich bin jetzt zu faul alle Vorfälle des letzten Jahres raus zu kramen, aber wenn du regelmäßig Security Meldungen verfolgst (was du als professioneller Entwickler tun solltest!), liest du immer wieder von kompromittiertem Code – gerade auch in großen, professionellen gemanagten Projekten.
„Eine speziell präparierte Webseite für mobile Entwickler“ klingt schon nach einem sehr gezielten Angriff – und es klingt so, als ob auch Leute außerhalb von Apple betroffen sind. [Inzwischen laut Heise bestätigt]. D.h. auch kleine App Schmieden werden betroffen sein.
Bei der kriminellen Professionalisierung des Hackens sollte man nicht so schnell Entwarnung geben. Die Angriff werden immer zielgerichteter und raffinierter. Ich stelle die Arbeitshypothese auf, dass die Täter nicht sofort in Programmcode eingegriffen haben, sondern erst einmal ihre Backdoor platzierten. Danach haben sie alle Zeit der Welt, in Ruhe weitere Angriffs-Vektoren auszuspähen.