Angriff auf Mac OS X ohne Spuren?

[Hausbesetzer]

Niemand dringt in ein gesichertes System ein.

Schön wärs.

Hier mal ein nettes Beispiel von Apples "Security" Verfahrensweise:

CVE-ID: CVE-2009-0006

Available for: Mac OS X v10.4.9 - v10.4.11, Mac OS X v10.5 or later, Windows Vista, XP SP2 and SP3

Impact: Viewing a maliciously crafted movie file may lead to an unexpected application termination or arbitrary code execution

Das Problem wurde im Update vom 21.01.2009 gefixt.
Das Problem wurde - und jetzt kommts - am 23.06.2008 an Apple reportet!!! und zwar von ZDI und wenn eine Lücke mal bei ZDI angekommen ist, wurde die sooft auf dem Schwarzmarkt gehandelt, dass die eh schon jeder kennt.

 

[MacMark]

Der Bug, den Du da aufführtst, funktioniert nur per Trojaner wie ein "guck mal Britney-is-nackt video" und führt dann im schlimmsten Fall (beliebigen) Code mit Benutzerrechten aus.
Für trojanische Pferde braucht man jedoch keinen Bug. Ich kann Dir auch ein Programm schreiben, das etwas Tolles macht, aber nebenei böse ist, ganz ohne Bug. Und das ist um Welten einfacher.
So einen Bug auszunutzen lohnt sich nicht, wenn damit doch nur ein Trojaner geht. Einfach zu viel Aufwand für etwas, was anders viel einfacher geht. Beispielsweise mit dem Trojaner-iLife-09 zum Runterladen. Kein Bug, purer No-Bug-Trojaner.

Stromberg würde sagen: Erst mal ganz locker durch die Hose atmen

 

[Hausbesetzer]

Ein eingebettetes Quicktime Video auf einer Internetseite reicht - und per XSS kann man die auch auf eine vertrauenswürdige Seite legen. 0 Userinteraktion notwendig.
Benutzerrechte reichen für DoS aus - für Spam auch. Was will man mehr? Viren und Trojaner zielen schon lange nicht mehr darauf ab, Schaden auf dem Zielsystem anzurichten - ergo brauchen diese auch keine Admin-Rechte

 

[MacMark]

Die User-Aktion ist das Aufrufen der infizierten Seite. Null User-Aktion ist: Ich schalte den Rechner ein, gehe Kaffee trinken und Du infizierst mich. Mach ma

Die Windows-Zombies (Bot-Netze) laufen brav mit Systemrechten und Hintergrundprozessen. Anderenfalls würden die Botprogramme auffallen.

Bei OS X würden Dir nicht mal Admin-Rechte dafür reichen, weil Du das Paßwort des jeweils infizierten Admins nicht kennst. Admins sind in Gruppe admin und nicht in roots Gruppe wheel. Windows-Admins sind aber in der Super-User-Gruppe. Und da es auf OS X nicht die lustige (auch bei Vista einschaltbare) Debug-Option (DLL-Hooks) zur Erweiterung beliebiger Programme gibt, kommst Du auch nicht dran, da die Dialoge vom Security Agent kommen. Bei Windows hast Du als Admin ohne Paßwort-Eingaben Systemrechte.

Ist alles sehr umfangreich und etwas kompliziert, aber ein UNIX hat nicht diese Bequemlichkeits-Risiko-Funktionen (wie DLL-Hooks für leichtes Debugging) eingebaut, die Windows dem Programmierer und dem Angreifer bietet.

 

[nschum]

Die User-Aktion ist das Aufrufen der infizierten Seite.

Nun, das ist aber durchaus gefährlich. Da muss irgendein Webseiten-Betreiber nur eine nicht-saubere Werbung einblenden. Dem kann man sich nur schwer entziehen, wenn man seinen Rechner tatsächlich benutzen möchte.

Die Windows-Zombies (Bot-Netze) laufen brav mit Systemrechten und Hintergrundprozessen. Anderenfalls würden die Botprogramme auffallen.

Auffallen? Wem denn? Bei mir laufen z.B. die Prozesse: pboard, PTPCamera, ATSService mit User-Rechten. Sagt mir null. Wenn da einer dabei wäre der Spam versendet, würde ich es sicher nicht merken.

Trotzdem sollte man bei der Einschätzung der Sicherheitslücken vorsichtig sein. "May" lead to arbitrary code execution, heißt nicht unbedingt auch, dass ein Exploit möglich ist. Sowas wird durchaus bei jedem Buffer-Overflow gerne geschrieben, ohne dass es in der Praxis auch klappt (etwa wegen NX-Bit).

 

[below]

Auffallen? Wem denn? Bei mir laufen z.B. die Prozesse: pboard, PTPCamera, ATSService mit User-Rechten. Sagt mir null. Wenn da einer dabei wäre der Spam versendet, würde ich es sicher nicht merken.

Es ist tatsächlich auf OS X (und anderen *nix'en) leichter zu erkennen, was gerade warum läuft.

Weil wir gerade dabei sind:

ATSServer, Apple Type Server:
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Support/ATSServer

pbpoard, pasteboard server, provides pasteboard services
/usr/sbin/pboard

PTPCamera läuft bei mir gerade nicht, ist aber die Verbindung zu einer Picture Transfer Protocol Camera

Auf Windows kannst Du ja mal kucken, ob Du so leicht (mit ps -axww) herausbekommst, wer warum läuft. Das ist hier schon leichter

Alex

 

[Hausbesetzer]

Auf Windows kannst Du ja mal kucken, ob Du so leicht (mit ps -axww) herausbekommst, wer warum läuft. Das ist hier schon leichter

Nutzen ca 0,1% aller Macuser - Sicherheitsgewinn? Nein.

Im Übrigen kann ich meinen Schadcode unter MacOS besser verstecken als unter Windows - Unter Windows sehe ich den Prozess (wie auch immer der heißt). Unter MacOS kann ich MEINEN Schadcode in Safari einbauen (Mach-Injection) und keiner sieht oder merkt was (nicht mal Safari selbst). Dh ps ist hier nutzlos.

Und wie schon erwähnt ist eine "infizierte Seite" nichts was mit Pornos oder Warez zu tun hat - es ist schon oft vorgekommen, dass Werbebanner-Server kompromittiert wurden und Schadcode auf Spiegel.de zb geworfen haben. In dem Fall wäre der Aufruf von spiegel.de der Aufruf der "infizierten Seite"

 

[below]

Nutzen ca 0,1% aller Macuser - Sicherheitsgewinn? Nein.

Du hast schon recht. Dennoch finde ich es schon kritisch, dass ich auch als Profi unter Windows relativ dumm aus der Wäsche kucke wenn ich wissen will, welcher Prozess woher kommt, von wem er gestartet wurde und was er da überhaupt treibt.

Allerdings muss ich zugeben, unter Windows 7 sieht das schon besser aus.

Alex

 

[nschum]

Herausfinden kann man das natürlich leicht. Im Zweifelsfall reicht googeln des Namens. Aber wer macht sich schon die Mühe? Und wer kennt die Prozesse intim genug, dass einem "auffällt", wenn da ein ungewöhnlicher Prozess dabei ist.

 

[MacMark]

… "May" lead to arbitrary code execution, heißt nicht unbedingt auch, dass ein Exploit möglich ist. Sowas wird durchaus bei jedem Buffer-Overflow gerne geschrieben, ohne dass es in der Praxis auch klappt (etwa wegen NX-Bit).

Sehe ich auch so. Apple schreibt vorsichtshalber alles theoretisch technisch Mögliche in den Bericht, auch wenn die reale Wahrscheinlichkeit gering und die Schwierigkeit zum Ausnutzen extrem hoch ist im Einzelfall.
Das dient vielleicht ihrer rechtlichen Absicherung, sonst heißt es, sie hätten nicht gewarnt.

 

[MacMark]

…
Im Übrigen kann ich meinen Schadcode unter MacOS besser verstecken als unter Windows - Unter Windows sehe ich den Prozess (wie auch immer der heißt). Unter MacOS kann ich MEINEN Schadcode in Safari einbauen (Mach-Injection) und keiner sieht oder merkt was (nicht mal Safari selbst). …

Nein, das ist unter Windows viel einfacher und viel effektiver:

Einordnung von mach_override und mach_inject
Dynamic Mach overriding, dynamisches Überschreiben und Code Injection: Warum ein Angreifer davon nichts hat:
http://www.macmark.de/osx_dynamic-overriding.php

Kurzfassung: Im schlimmsten Fall, wenn überhaupt möglich, kann man damit per Trojaner arbeiten und hätte extrem viel Aufwand. Das lohnt sich nicht, weil man effektive Trojaner viel einfacher ohne diese Technik hinkriegt.

Bei Windows sieht es hingegen bezüglich Code-Einschleusung mit DLL-Injection, DLL-Hooks, Application Messages und so weiter um Welten schlimmer aus: Das sind effektivere, nicht auf den einzelnen User beschränkte, systemweite und deutlich einfacher einzusetzende Schadcode-Techniken, die Windows da bietet.