In Pishingmail aus Versehen einen Link angeklickt

Kannst du das erläutern, warum das ein Risiko darstellen sollte? Wenn sich ein User per ssh einloggt, macht es meines Erachtens extrem viel Sinn, dass er auch genau das gleiche kann, wie wenn er am Mac direkt sitzt. Und das ist durch den Festplattenvollzugriff der Fall. Er kann aber auch nicht mehr, auch wenn der Wortteil "vollzugriff" das suggeriert. Es gelten immer noch die üblichen Unix-Permisssions, so dass der User die Verzeichnisse / Dateien anderer User auch nicht sehen kann.

@Frau Linde Du musst dir also keine Gedanken darüber machen.
Der Artikel ist einer betreffs dieses Themas:
https://securityreport.com/apple-ss...ted-at-large-remains-unpatched-after-2-years/

In Anbetracht der TE und anderen Benutzern, die nicht in dieser Materie wissentlich "drin stecken", empfiehlt sich da "unchecked".
Da empfinde ich dein Anraten "Du musst dir also keine Gedanken darüber machen." nicht hilfreich.
 
  • Gefällt mir
Reaktionen: dg2rbf

ich kenne den Artikel. Aber was soll daran nun schlimm sein?

Wenn sich ein User via ssh einloggt, soll es nach diesem Artikel ein Sicherheitsrisiko darstellen, dass er auf seinen eigenen Dokumente-Ordner, seine eigenen Kalender-Daten, seine eigenen Fotos zugreifen kann? Was soll daran ein Sicherheitsrisiko sein? Es sind seine Daten. Der User kann aber nach wie vor nicht auf diese Daten von anderen Usern zugreifen. Das verhindern die Unix-Permissions auch dann, wenn ssh-keygen-wrapper vollen Festplattenzugriff hat, oder wenn er gar nicht dort auftaucht.

Wo also liegt das Problem? Oder stört man sich nur am Prinzip "ssh-keygen-wrapper taucht nicht auf, der User hat aber dennoch Zugriff auf seine Daten". Das wäre in meinen Augen aber eine etwas schräge Ansicht, wenn man erwartet, dass ein User keinen Zugriff auf seine Daten haben darf, wenn er sich remote einloggt.
 
In Anbetracht der TE und anderen Benutzern, die nicht in dieser Materie wissentlich "drin stecken", empfiehlt sich da "unchecked".

Warum soll man einem User empfehlen, sich selbst vom Zugriff auf seine eigenen Daten auszusperren?
 
  • Gefällt mir
Reaktionen: dg2rbf
Warum soll man einem User empfehlen, sich selbst vom Zugriff auf seine eigenen Daten auszusperren?
01. Das will ja auch niemand und der TE hat kein einziges Wort über ssh verloren.
02. Geht es hier im Thread um etwas anderes als ssh.
03. Der TE fragte lediglich: "Weiß jemand, was ssh-keygen-wrapper ist?" und nicht nach ssh login.
04. Um den möglichen Exploit nicht zu ermöglichen:
"Deaktivieren Sie Remote Login und stellen Sie sicher, dass sshd-keygen-wrapper zur Liste "Voller Festplattenzugriff" Ihres Macs hinzugefügt wurde,
dort aber nicht markiert ist."

Wohlmöglich kommt jemand auf die Idee sshd-keygen-wrapper zu entfernen.
In Kombination mit aktiviertem "Remote Login" ist es dann unglücklich:
Um vollen Zugriff auf ein beliebiges datenschutzgeschütztes Verzeichnis zu erhalten, muss ein Angreifer lediglich eine ssh-Verbindung herstellen.
Vorausgesetzt, Remote Login ist aktiviert und sshd-keygen-wrapper ist nicht sowohl vorhanden als auch deaktiviert (nicht angekreuzt) in der Liste Full Disk Access,
wird macOS automatisch seinen eigenen Datenschutz ohne weitere Kontrolle umgehen.
Und letztendlich:
Dieses Verhalten kann von Malware und ausgeklügelten "Schwachstellenverkettungen" ausgenutzt werden,
um vertrauliche Dateien, wie z. B. Safari-Browser-Cookies, zu stehlen.

Und da der TE Sorge um einen Klick auf eine vermeintliche Phisingmail, und wegen möglicher Malware deswegen diesen Thread eröffnet hat,
betrachte ich es so als naheliegend diese Antwort zu geben.
Und nicht ein: "Du musst dir also keine Gedanken darüber (sshd-keygen-wrapper) machen."
:noplan:
 
"Remote Login" ist der ssh Zugang.

Darum gibt es zwei mögliche Fälle:

a) man aktiviert den ssh Zugang:
dann macht es doch Sinn, dass der User, der sich darüber einloggt, doch auch auf seine Daten zugreifen kann. Warum sollte man sich selbst vom Zugriff auf seine eigenen Daten aussperren?

b) man aktiviert den ssh Zugang nicht:
Dann kann man sich auch nicht einloggen und es ist vollkommen egal, ob ssh-keygen-warapper aufgeführt, aktiviert oder deaktiviert ist. Man kann sich eben gar nicht erst einloggen.

Ergo:

Das Risiko liegt einzig und alleine darin, ob man den ssh Zugang erlaubt oder nicht erlaubt. Wenn man ihn erlaubt, muss man eben entweder ein sicheres Passwort nehmen oder das pubkey-Verfahren. Wenn man es aber erlaubt, dann macht auch nur der Zugriff auf alle eigenen Daten Sinn.

Und das mit "Schwachstellenketten" hat doch ebenso nichts mit ssh-keygen-wrapper zu tun. Wenn es ein Angreifer schon schafft in ssh einzubrechen, dann ist er doch schon im System. Was hat denn da der ssh-keygen-wrapper noch für eine Bewandnis?

Und wenn man per ssh eingeloggt ist, egal ob als regulärer User oder als Angreifer, dann gibt es immer noch die Unix-Rechte, die verhindern, dass man andere User-Daten lesen kann. Wenn ein Angreifer die umgehen will, hat das auch nichts mit ssh-keygen-wrapper zu tun, da der nur für die eigenen Daten zuständig ist.

Und daher bleibe ich dabei: Mach dir keine Sorgen wegen ssh-keygen-wrapper. Und zwar deswegen, weil sich der TE aufgrund deines Hinweises wegen ssh-keygen-wrapper Sorgen macht und mit "Au weia" in #15 geantwortet hat. Und diese Sorgen sind unbegründet.
 
  • Gefällt mir
Reaktionen: Johanna K und dg2rbf
Inhaltlich verstehe ich nicht mehr alles. Ich hatte übrigens ein 'h' vergessen. Es war ein sshd-keygen-wrapper.
 
Danke für eure Hilfe und die Informationen!
 
  • Gefällt mir
Reaktionen: dg2rbf
a) man aktiviert den ssh Zugang:
dann macht es doch Sinn, dass der User, der sich darüber einloggt, doch auch auf seine Daten zugreifen kann. Warum sollte man sich selbst vom Zugriff auf seine eigenen Daten aussperren?
https://support.apple.com/de-de/guide/mac-help/mh11851/mac
Mit der Option „Entfernte Verwaltung“ der Systemeinstellung „Freigaben“ kannst du anderen Benutzern den Fernzugriff über Apple Remote Desktop auf deinen Computer erlauben.
Um vollen Zugriff auf ein beliebiges datenschutzgeschütztes Verzeichnis zu erhalten, muss ein Angreifer lediglich eine ssh-Verbindung herstellen.
Vorausgesetzt, Remote Login ist aktiviert und sshd-keygen-wrapper ist nicht sowohl vorhanden als auch deaktiviert (nicht angekreuzt) in der Liste Full Disk Access,
wird macOS automatisch seinen eigenen Datenschutz ohne weitere Kontrolle umgehen.
:noplan:
 
  • Gefällt mir
Reaktionen: Apfelfuzzi
Danke, Difool, jetzt verstehe ich ein kleines bisschen mehr. Und werde auf allen Geräten schauen, wie es unter "Freigabe" aussieht.
 

- "Remote Desktop" ist nicht "Remote Login"
- "Remote Desktop" ist auf deutsch in den Systemeinstellungen "Entfernte Verwaltung"
- "Remote Login" ist der ssh-Zugang oder auf deutsch in den Systemeinstellungen "Entfernte Anmeldung"
- Die angebliche Sicherheitslücke geht um "Remote Login" also um den ssh-Zugang und nicht über "Remote Desktop"
- du verlinkst nun aber einen Artikel von Apple zu "Remote Desktop". Das hat aber ein gar nichts mit der angeblichen Sicherheitslücke über "Remote Login" zu tun.

Edit:

Apple umgeht auch nicht seinen eigenen Datenschutz. Warum? Weil jeder User immer Zugriff auf seine Daten hat. Und exakt diesen gleichen Zugriff hat er auch, wenn er sich per ssh einloggt (auf englisch: per Remote Login). Wo also umgeht Apple seine eigenen Datenschutz, wenn der User sowohl in der normalen grafischen Oberfläsche, wenn er driekt vorm MAc sitzt, als auch wenn er sich aus der Ferne per ssh einloggt, Zugriff auf seine eigenen Daten hat?

Ist das wirklich so schwer einzusehen, dass es kein Sicherheitsrisiko darstellt, wenn man seine eigenen Daten lesen kann?

Und ebenso nochmals: "Remote Desktop" ist was ganz anderes als "Remote Login"
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: dg2rbf
Uups, den Link hatte ich tatsächlich verdaddelt. Danke.
Remote Login:
https://support.apple.com/de-de/guide/mac-help/mchlp1066/mac

Gut, aber an der Sachlage ändert das ja imo nichts, wenn macOS sich selbst aushebelt bei gewissen Konstellationen, wie oben beschrieben.
…wenn sich ein Benutzer via ssh einloggt und:
Um vollen Zugriff auf ein beliebiges datenschutzgeschütztes Verzeichnis zu erhalten, muss ein Angreifer lediglich eine ssh-Verbindung herstellen.
Vorausgesetzt, Remote Login ist aktiviert und sshd-keygen-wrapper ist nicht sowohl vorhanden als auch deaktiviert (nicht angekreuzt) in der Liste Full Disk Access,
wird macOS automatisch seinen eigenen Datenschutz ohne weitere Kontrolle umgehen.
Muss ja nicht unbedingt der Datenbesitzer selbst, sondern kann ja ein Dritter mit Erlaubnis sein, der dann Vollzugriff dadurch erhält.
So verstehe ich es zumindest.
 
Muss ja nicht unbedingt der Datenbesitzer selbst, sondern kann ja ein Dritter mit Erlaubnis sein, der dann Vollzugriff dadurch erhält.
So verstehe ich es zumindest.

Genau das geht aber nciht. Das verstehst du leider falsch.

Wenn du dich per ssh einloggst, hast du nur Zugriff auf deine Daten. Das regeln die Unix-Rechte. Du kannst dadurch überhaupt nicht auf Daten anderer User zugreifen, da die Unix-Rechte der anderen User-Verzeichnisse und anderer User-Daten das verhindern.

ssh-keygen-wrapper in den Einstellungen zu "Festplattenvollzugriff" betrifft immer nur die Verzeichnisse des Users, der per ssh eingeloggt ist.

Das kannst du ganz einfach selbst testen, wenn du es mir nicht glaubst. Ich habe es getan. Bei mir hat der ssh-keygen-wrapper Festplattenvollzugriff erlaubt. Wenn ich mich nun auf dem Mac per ssh einlogge, dann kann ich nur auf meine Daten zugreifen, die mir die Unix-Rechte erlauben. Ich habe keine Möglichkeit auf die "datengeschützen" Verzeichnisse eines anderen Users zuzugreifen, da dort die Unix-Rechte mir das nicht erlauben.

Ergo: Ich kann auch mit aktiviertem Festplattenvollzugriff nur auf meine eigenen datengeschützten Verzeichnisse zugreifen und nicht auf die anderer User.

Wo also ist da nun ein Sicherheitsproblem, oder so wie du es sogar bezeichnet hast ?
extremely high security risk
 
  • Gefällt mir
Reaktionen: dg2rbf und UnixCoon

Ich hoffe du hast den Artikel gelesen. Da wird als Beispiel ja irgendein Safari-Verzeichnis angebenen. Hast du dort auch mal diese Verzeichnis genau angesehen? Dann hast du sicher erkannt, dass dort das ~Zeichen steht. Und du weißt ja auch, dass das das Home-Verzeichnis des gerade eingeloggten Users darstellt.

Das angebliche Sicherheitsrisiko betrifft also, dass der User auf eine Datei in seinem eigenen Homeverzeichnis zugreifen kann.

Nun bitte erkläre mir doch mal mit Zitaten aus dem Artikel und mit technischen Erklärungen, warum das ein Sicherheitsproblem sein soll, dass ein User auf seine eigenen Daten zugreifen kann.

Und noch was: Hast du dir schon mal die Mühe gemacht, dich selbst per ssh einzuloggen und auf Daten anderen User zugreifen? Oder schickst du nur Links ohne den Inhalt zu prüfen?

Edit:
Es ist unheimlich schade, dass ich exakte Wege beschreibe, wie du es selbst prüfen kannst und du überhaupt nicht darauf eingehst und weiterhin so tust, als wäre das alles was ich über die Unix-Rechte schreibe vollkommen falsch und gelogen. Bitte setze dich doch mal ganz konkret mit diesen Punkten auseinander.
 
  • Gefällt mir
Reaktionen: dg2rbf
@lisanet
Das mit der Maleware hast du aber schon mitbekommen, oder?
 
@lisanet
Das mit der Maleware hast du aber schon mitbekommen, oder?

Sag mal, willst du mich provozieren, oder was soll dieser Mist?

Das mit den Unix-Rechten hast du aber schon mitbekommen und auch verstanden, oder?

Wenn sich ein User einloggt, oder ein Angreifer als User einloggt, oder eine Malware sich als User einloggt, oder Difool sich als User einloggt, dann kann der User/Angreifer/Malware/Difool IMMER genau das lesen, was dieser User halt lesen kann. Das ist ganz und gar normales Verhalten, bewusst und gewollt, Sinn und Zweck des Einloggens.

Alles andere wäre vollkommen sinnlos. Denn das würde ja bedeuten, dass sich ein User einloggt, und plötzlich seine eigenen Daten nicht mehr lesen kann. Was würde das für einen Aufschrei über die Sinnlosigkeit des Einloggens auslösen? Man loggt sich ein, und kann trotzdem nichts machen. Willst du das wirklich?

Woran genau liegt es nun, dass du es nicht verstehst? Willst du es nicht verstehen? So sieht es für mich aus.
 
  • Gefällt mir
Reaktionen: dg2rbf
Bitte streitet euch nicht und werdet wieder friedlich. Ich schätze sehr euer beider großes Fachwissen und auch eure Bereitschaft anderen Usern zu helfen!
 
  • Gefällt mir
Reaktionen: hevoah, Apfelfuzzi und dg2rbf
Bitte streitet euch nicht und werdet wieder friedlich. Ich schätze sehr euer beider großes Fachwissen und auch eure Bereitschaft anderen Usern zu helfen!

Es geht nicht um Streiten. Ich verzweifle nur gerade, dass man sich Null mit dem konkret auseinander setzt, was ich schreibe, geschweige denn, sich mal selbst via ssh einloggt und dann mit eigenen Augen sieht, dass es kein Sicherheitsproblem gibt.

Das einzige was ich als Reaktion erhalte sind Links und rethorische Fragen ob ich gelesen hätte, dass im Artikel was von Malware steht. Ja, zum Geier, ich habe es gelesen. Und ich habe es sogar verstanden. Und ich weiß daher, dass es eben keinerlei Sicherheitsproblem darstellt, wie ssh-keygen-wrapper einsgestellt ist. ssh-keygen-wrapper betrifft ausschließlich Dateien des eingeloggten Users. Und DAS steht auch exakt so im Artikel. DAS habe ich auch gelesen und verstanden.

Das ist der Artikel auf den sich alle beziehen: https://eclecticlight.co/2018/11/12/who-put-that-in-my-full-disk-access-list-ssh-and-mojaves-privacy-protection/

Und das steht da drin:

Who put that in my Full Disk Access list ssh and Mojave’s privacy protection – The Eclectic Li...png

Die Beispiele in diesem Artikel haben als Pfadangabe das ~Zeichen. Das ist das Homeverzeichnis.

Warum soll es dann ein Sicherheitsproblem darstellen, wenn ein User auf seine Dateien im eigenen Homeverzeichnis zugreifen kann? Warum wird diese Frage nicht beantwortet und mir statt dessen hingeworfen, ob ich nicht gelesen hätte, dass Malware erwähnt wird?

Was eine Malware kann oder nicht kann hat doch rein gar nichts mit ssh-keygen-wrapper zu tun. Ob mit oder ohne ssh-keygen-wrapper, ob via ssh oder im Terminal.app oder auf der GUI: Ein User kann immer auf seine eigenen Daten zugreifen. Das ist doch kein Sicherheitsproblem.

Und wenn man nun unbedarfte User darauf hinweist dass es ein angebliches "extremly high securitiy risk" sei, so wie Difool es getan hat, und der User dann mit "Au weia" antwortet, dann finde ich das in keinster Weise gut. Vorallem dann wenn diese Aussage des Risikos einfach nicht stimmt.
 
  • Gefällt mir
Reaktionen: Johanna K, UnixCoon und dg2rbf
Ich habe jetzt ein Schlagwort für diesen Strang "ssh" eingefügt und dafür das Schlagwort "Sicherheit" rausgeschmissen, damit noch andere von den Informationen profittieren können. :)
 
  • Gefällt mir
Reaktionen: dg2rbf
Zurück
Oben Unten