139689
29.12.2023
2832
12
0
GMSA kaum sicherer als pre-set ServiceAccount?
Hallo zusammen noch im alten Jahr!
ich frage mich gerade, ob die Sicherheit von diesen group-managed Service Accounts nicht ein Sicherheits-Kuhhandel bzw. potentiell sogar unsicherer als Servicekonten sind.
gMSA Accounts wurden ja mit Server 2012 eingeführt, um über AD verwaltet Konten bereitzustellen, wo das Passwort vom AD verwaltet wird.
Man stellt direkt im Objekt ein, welche Computerobjekte darauf zugreifen können und es nutzen können
Oft ist es ja Usus, einen Serviceaccount ("domain\service") zu erstellen mit fixem, hoffentlich komplexen Passwort, dass dann gesetzt und im Tresor abgelegt wird.
Für Angreifer ein gefundenes Fressen, wenn sie das System kompromittieren, heißt es.
Aber ist das dann für gMSA nicht genauso der Fall? Vor allem, wenn sie genau so einen Host erwischen, der berechtigt ist, im Zuge der Ausbreitung im System.
Zwar gibt es hier wohl kein Passwort, das er im Klartext bzw. in den Anwendungseinstellungen oder im Hash hinterlegt abgreifen kann.
Aber wenn das System übernommen wurde, braucht ein Angreifer nur herausfinden, dass ein gMSA genutzt wird, hier den Namen des Kontos nehmen und schon kann er es frei am System nutzen, für das der gMSA Account gesetzt ist.
Natürlich in beiden Fällen fatal, wenn das gMSA bzw. Servicekonto Mitglied der Domänenadministratoren ist.
Best practice ist natürlich, so wenig Berechtigungen wie möglich zu vergeben, ist klar.
Aber zb. AD-Backup braucht Domain-Admin Rechte.
lokales Systemkonto wäre für lokale Tasks besser, aber manchmal (Scripts) geht es um Remote-Prozedueren. Sei es AD-Abfrage, Exchange-Tasks, ... you name it.
Und vermutlich hat man ohnehin schon eine extrem kritische Situation, wenn ein Angreifer im lateral movement bis zu dem Punkt vordringt, da was heraus zu finden.
Oder fabriziere ich mir da gedanklich zu viel zusammen?
Ansonsten schonmal einen guten Rutsch ins neue Jahr!
ich frage mich gerade, ob die Sicherheit von diesen group-managed Service Accounts nicht ein Sicherheits-Kuhhandel bzw. potentiell sogar unsicherer als Servicekonten sind.
gMSA Accounts wurden ja mit Server 2012 eingeführt, um über AD verwaltet Konten bereitzustellen, wo das Passwort vom AD verwaltet wird.
Man stellt direkt im Objekt ein, welche Computerobjekte darauf zugreifen können und es nutzen können
Oft ist es ja Usus, einen Serviceaccount ("domain\service") zu erstellen mit fixem, hoffentlich komplexen Passwort, dass dann gesetzt und im Tresor abgelegt wird.
Für Angreifer ein gefundenes Fressen, wenn sie das System kompromittieren, heißt es.
Aber ist das dann für gMSA nicht genauso der Fall? Vor allem, wenn sie genau so einen Host erwischen, der berechtigt ist, im Zuge der Ausbreitung im System.
Zwar gibt es hier wohl kein Passwort, das er im Klartext bzw. in den Anwendungseinstellungen oder im Hash hinterlegt abgreifen kann.
Aber wenn das System übernommen wurde, braucht ein Angreifer nur herausfinden, dass ein gMSA genutzt wird, hier den Namen des Kontos nehmen und schon kann er es frei am System nutzen, für das der gMSA Account gesetzt ist.
Natürlich in beiden Fällen fatal, wenn das gMSA bzw. Servicekonto Mitglied der Domänenadministratoren ist.
Best practice ist natürlich, so wenig Berechtigungen wie möglich zu vergeben, ist klar.
Aber zb. AD-Backup braucht Domain-Admin Rechte.
lokales Systemkonto wäre für lokale Tasks besser, aber manchmal (Scripts) geht es um Remote-Prozedueren. Sei es AD-Abfrage, Exchange-Tasks, ... you name it.
Und vermutlich hat man ohnehin schon eine extrem kritische Situation, wenn ein Angreifer im lateral movement bis zu dem Punkt vordringt, da was heraus zu finden.
Oder fabriziere ich mir da gedanklich zu viel zusammen?
Ansonsten schonmal einen guten Rutsch ins neue Jahr!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1159432241
Url: https://administrator.de/forum/gmsa-kaum-sicherer-als-pre-set-serviceaccount-1159432241.html
Ausgedruckt am: 30.12.2024 um 18:12 Uhr
12 Kommentare
Neuester Kommentar
Ja, du fabrizierst komische Sachen. Freitagsthema?
1
Moin, echt schon Freitag, wie schnell die Woche vergeht...
Naja, ein gMSA Account hat schon zwei gute Vorteile gegnüber einem MSA Konto. Das Passwort eines Group Managed Service Accounts ist sehr komplex, außerdem wird es automatisch generiert und alle 30 Tage standardmäßig geändert.
Aber auch ein gMSA kann mittels "Golden gMSA Angriff attackiert werden...
Ob MSA oder gMSA ist eigentlich nicht relevant wir dürfen nicht vergessen das Denstkonten häufig mit unnötigen Zugriffsrechten und Privilegien ausgestattet sind. Hier achten leider auch zu viele Vögel nicht auf den Prinzip des geringsten Privilegs.
Sowohl MSA wie auch gMSA nicht das Problem sondern die Supportler die mit Domänen Rechten sich auf diese Kisten schalten und paar Tage später first level support bei Frau Schmitz leisten.
Naja, ein gMSA Account hat schon zwei gute Vorteile gegnüber einem MSA Konto. Das Passwort eines Group Managed Service Accounts ist sehr komplex, außerdem wird es automatisch generiert und alle 30 Tage standardmäßig geändert.
Aber auch ein gMSA kann mittels "Golden gMSA Angriff attackiert werden...
Ob MSA oder gMSA ist eigentlich nicht relevant wir dürfen nicht vergessen das Denstkonten häufig mit unnötigen Zugriffsrechten und Privilegien ausgestattet sind. Hier achten leider auch zu viele Vögel nicht auf den Prinzip des geringsten Privilegs.
Sowohl MSA wie auch gMSA nicht das Problem sondern die Supportler die mit Domänen Rechten sich auf diese Kisten schalten und paar Tage später first level support bei Frau Schmitz leisten.
Vielleicht bremst Du deine Fantasie etwas und gehst mit objektiven Sachverstand an das Thema ran.
Natürlich kann man alles fahrlässig bis falsch konfigurieren. Dann spricht man aber nicht über Fachlichkeit und Sicherheit.
Wenn Du dein Auto falsch bedienst, wirst Du dich töten.
Manch Jäger erschießt sich beim reinigen der Waffe.
Natürlich kann man alles fahrlässig bis falsch konfigurieren. Dann spricht man aber nicht über Fachlichkeit und Sicherheit.
Wenn Du dein Auto falsch bedienst, wirst Du dich töten.
Manch Jäger erschießt sich beim reinigen der Waffe.
Zitat von @8585324113:
Vielleicht bremst Du deine Fantasie etwas und gehst mit objektiven Sachverstand an das Thema ran.
Natürlich kann man alles fahrlässig bis falsch konfigurieren. Dann spricht man aber nicht über Fachlichkeit und Sicherheit.
Wenn Du dein Auto falsch bedienst, wirst Du dich töten.
Manch Jäger erschießt sich beim reinigen der Waffe.
Vielleicht bremst Du deine Fantasie etwas und gehst mit objektiven Sachverstand an das Thema ran.
Natürlich kann man alles fahrlässig bis falsch konfigurieren. Dann spricht man aber nicht über Fachlichkeit und Sicherheit.
Wenn Du dein Auto falsch bedienst, wirst Du dich töten.
Manch Jäger erschießt sich beim reinigen der Waffe.
Finde ich jetzt ein bisschen als bashing. Da ist sicher Fantasie / Fabrikation dabei, aber auch Sachliches.
Musste mich intern schon mit der Fragestellung konfrontieren lassen, was wir machen, wenn ein Angreifer schon jahrelang als Schläfer bei uns sich lateral ausbreitet und dann am Tag X aktiv wird und ob das dann nicht auch in den Backups und überall infiziert ist....
Klar ist, dass nichts 100% sicher ist
Ich meine, dass ein sicheres, pre-set Servicekonto (Kennwort komplex, nur einmal genutzt und nur im Tresor) ein gewisses Sicherheitslevel hat.
Das oben auch von mir erwähnte Prinzip des geringsten Privilegs muss bei beiden Varianten passen.
Mit der Frage musste ich mich vor paar Jahren auch schon beschäftigen. Ein Privileg Escalation und die anschließende Seitwärtsbewegung kann man auf Dauer nicht wirklich verhindern, die Zeit ist immer mit dem Angreifer.
Fakt ist, die Technik ist nicht clever genug und die Angreifer sind immer einen Schritt voraus. Deshalb sollte die entscheidende Frage für dich sein, hast du ein hoffentlich gutes und zuverlässiges IDPS System im Einsatz und genügend Backups die nicht kompromittiert sind?!
@139689
Musste mich intern schon mit der Fragestellung konfrontieren lassen, was wir machen, wenn ein Angreifer schon jahrelang als Schläfer bei uns sich lateral ausbreitet und dann am Tag X aktiv wird und ob das dann nicht auch in den Backups und überall infiziert ist....
Fakt ist, die Technik ist nicht clever genug und die Angreifer sind immer einen Schritt voraus. Deshalb sollte die entscheidende Frage für dich sein, hast du ein hoffentlich gutes und zuverlässiges IDPS System im Einsatz und genügend Backups die nicht kompromittiert sind?!
@139689
Musste mich intern schon mit der Fragestellung konfrontieren lassen, was wir machen, wenn ein Angreifer schon jahrelang als Schläfer bei uns sich lateral ausbreitet und dann am Tag X aktiv wird und ob das dann nicht auch in den Backups und überall infiziert ist....
2
Ich glaube dein Problem ist, dass Du alles zu einem Brei verrührst und offenkundige nicht weist wie Angriffe funktionieren.
Natürlich ist ein zur Kenntnis gelangtes Kennwort ein Problem. Natürlich kann man sich das das gmsa Kennwort auch im Klartext zeigen lassen.
Du verrührst hier aber einen Brei der beiden Konzepte und willst dann noch einen Vergleich anstellen.
Angriffe auf eine IT sind meistens eine Kette
Oder fast immer eine Kette.
Ketten haben ein Anfang und ein Ende, dazwischen kann es viele Glieder geben.
Es gibt abstrakte und konkrete Gefahren. Und wie wir hier lesen können auch konfuse Gefahren.
Natürlich ist ein zur Kenntnis gelangtes Kennwort ein Problem. Natürlich kann man sich das das gmsa Kennwort auch im Klartext zeigen lassen.
Du verrührst hier aber einen Brei der beiden Konzepte und willst dann noch einen Vergleich anstellen.
Angriffe auf eine IT sind meistens eine Kette
Oder fast immer eine Kette.
Ketten haben ein Anfang und ein Ende, dazwischen kann es viele Glieder geben.
Es gibt abstrakte und konkrete Gefahren. Und wie wir hier lesen können auch konfuse Gefahren.
2
Ich weiß nur das, was ich nachlesen kann in Zeitschriften und Foren. Sonst bin ich hier auf mich allein gestellt und habe ab und an Dienstleister oder versuche mich in Forenbeiträgen wie diesem hier auszutauschen um mehr zu erfahren.
Leider fehlt mir im echten Leben völlig der fachliche Austausch mit anderen und ich denke, da geht es vielen (vor allem am Land, kleine Unternehmen...) so.
Umsetzungen (zb. immutable Storage für Backups) sind in meiner Arbeitsweise nach best effort. Aber dazu muss man sich weiterbilden, lesen, fragen
Und dazu eben auch mal so ein Beitrag, auch wenn es zufällig am Freitag ist.....
Leider fehlt mir im echten Leben völlig der fachliche Austausch mit anderen und ich denke, da geht es vielen (vor allem am Land, kleine Unternehmen...) so.
Umsetzungen (zb. immutable Storage für Backups) sind in meiner Arbeitsweise nach best effort. Aber dazu muss man sich weiterbilden, lesen, fragen
Und dazu eben auch mal so ein Beitrag, auch wenn es zufällig am Freitag ist.....
Gucke dir mal bei cvedetails.com die letzten schweren Lücken an. Brauchte da jemand ein Kennwort für den Schaden?
Ansonsten lasse dein Backup ausschließlich auf Blocklevel autark Arbeiten und halte genug Speicher vor um auch Monate und länger valide Backups zu haben.
Ggf in Kombination mit offsite WORM Storage.
Ansonsten lasse dein Backup ausschließlich auf Blocklevel autark Arbeiten und halte genug Speicher vor um auch Monate und länger valide Backups zu haben.
Ggf in Kombination mit offsite WORM Storage.
2
Du musst dich nicht rechtfertigen, deine Frage war berechtigt. Die meisten KMU sind auf sich alleine gestellt.
Weiterbildung ist die einzige Lösung, ich kann Dir aus eigener Erfahrung nur empfehlen, selbst einmal in die Rolle des Angreifers zu schlüpfen und sich hier Input zu holen. Der Zeitaufwand ist enorm, aber du bekommst ein viel besseres Verständnis als die meisten Admins die sich nicht damit nicht beschäftigen...
https://attack.mitre.org/matrices/enterprise/
Weiterbildung ist die einzige Lösung, ich kann Dir aus eigener Erfahrung nur empfehlen, selbst einmal in die Rolle des Angreifers zu schlüpfen und sich hier Input zu holen. Der Zeitaufwand ist enorm, aber du bekommst ein viel besseres Verständnis als die meisten Admins die sich nicht damit nicht beschäftigen...
https://attack.mitre.org/matrices/enterprise/
2
Ich patche alles, was ich kann / zu patchen ist.
ich habe quasi alles nach Best practice von veeam umgesetzt.
Wurde von einem Dienstleister auditiert und als sauber erklärt...
WORM Medien gibt es
auch noch manuelle Backups dazu
Meinen Kollegen versuche ich noch von den altmodischen, automatischen file-basierten Backups wegzubekommen
Meine Fragestellung war wirklich nach einem möglichen, infizierten Host, der mit gMSA dann "gefährlicher" ist als mit einem ServiceKonto. Aber hab es wohl nicht richtig wiedergegeben.
Letzter Post in diesem Jahr (und vielleicht auch überhaupt hier)
ich habe quasi alles nach Best practice von veeam umgesetzt.
Wurde von einem Dienstleister auditiert und als sauber erklärt...
WORM Medien gibt es
auch noch manuelle Backups dazu
Meinen Kollegen versuche ich noch von den altmodischen, automatischen file-basierten Backups wegzubekommen
Meine Fragestellung war wirklich nach einem möglichen, infizierten Host, der mit gMSA dann "gefährlicher" ist als mit einem ServiceKonto. Aber hab es wohl nicht richtig wiedergegeben.
Letzter Post in diesem Jahr (und vielleicht auch überhaupt hier)
Die Frage ist ganz einfach zu beantworten, Ja, kann muss aber nicht!
Meine Fragestellung war wirklich nach einem möglichen, infizierten Host, der mit gMSA dann "gefährlicher" ist als mit einem ServiceKonto.
Meine Fragestellung war wirklich nach einem möglichen, infizierten Host, der mit gMSA dann "gefährlicher" ist als mit einem ServiceKonto.
1
Moin,
Gruß,
Dani
Aber wenn das System übernommen wurde, braucht ein Angreifer nur herausfinden, dass ein gMSA genutzt wird, hier den Namen des Kontos nehmen und schon kann er es frei am System nutzen, für das der gMSA Account gesetzt ist.
dann ist ein (g)MSA vermutlich dein kleinstes Problem.gMSA Accounts wurden ja mit Server 2012 eingeführt, um über AD verwaltet Konten bereitzustellen, wo das Passwort vom AD verwaltet wird.
Richtig. Damit ist es auch erst einmal out-of-the-box nicht möglich mit solchen Konten sich interaktiv (weder RDP und Konsole noch als "different user") am Server anzumelden. Das kann natürlich mit einem User Account ebenfalls erreicht werden, aber es Bedarf einen Aufwand zu einer regelmäßigen Kontrolle.Man stellt direkt im Objekt ein, welche Computerobjekte darauf zugreifen können und es nutzen können
Das ist ebenfalls ein großer Vorteil. Das (technische) Verhalten (1:1) ist mit einem User Account wohl laut den AD Kollegen schwer umsetzbar.Oft ist es ja Usus, einen Serviceaccount ("domain\service") zu erstellen mit fixem, hoffentlich komplexen Passwort, dass dann gesetzt und im Tresor abgelegt wird.
Heißt aber auch bei einer möglichen Kompromittierung muss das Passwort trotzdem geändert werden. Was dann entsprechend in Mehraufwand endet.lokales Systemkonto wäre für lokale Tasks besser, aber manchmal (Scripts) geht es um Remote-Prozedueren. Sei es AD-Abfrage, Exchange-Tasks, ... you name it.
Sowas kann problemlos mit einem Service Account realisiert werden. Über das einschlägige Gruppen Prinzip ist das problemlos machbar. Es ist eben Aufwand, den keiner sehen möchte. Aber ist aus meiner Sicht der einzige richtige Weg.Aber zb. AD-Backup braucht Domain-Admin Rechte.
richtig. Aber auch hier gibt es Wege, den extra angelegten Service Account entsprechend einzuschränken und entsprechend zu überwachen. Aber auch das kostet Ressourcen in Form von Zeit und damit Geld. Aber neben den angesprochen klassischen Weg gibt es auch für DCs andere Konzepte, die angewendet werden können. So dass ein Service Account mit diesen Rechten nicht mehr erforderlich ist.Gruß,
Dani
1
