Zahlreiche Motherboards von MSI betroffen: Secure Boot ohne Funktion

Thread Starter
Mitglied seit
06.03.2017
Beiträge
113.964
Eigentlich sollte Secure Boot Nutzer davor schützen, Systeme zu starten, die mit Schadcode verseucht wurden. Jetzt hat ein Sicherheitsforscher herausgefunden, dass besagte Funktion nicht immer den versprochenen Schutz bietet. Im Detail betrifft dies zahlreiche Mainboards des Herstellers MSI.
... weiterlesen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Es wurde auch nicht ausgehebelt, sondern die defaults sind so gesetzt, dass auch unsignierte Systeme gebootet werden. Man bauscht das aktuell unnötig auf. Vermutung an anderer Stelle war, dass MSI die W11 Voraussetzungen erfüllen will und dennoch standardmäßig alles bootfähig halten möchte.
Dann bootet halt auch jedes Linux ohne das der User fummeln muss und W11 meckert trotzdem nicht.

Ob es sinnvoll ist, das so zu lösen, sei dahingestellt.
 
Es gab doch auch noch eine Lücke, die entstand, wenn man Secure Boot deaktiviert und wieder aktiviert hat, konnten einem falsche Schlüssel eingespielt werden, nur ein neues aufspielen des Bios konnte die Schlüssel wieder in den Auslieferungszustand versetzen. Die Nachricht dazu finde ich aber leider nicht mehr.

Aber das Secure Boot Problem scheint nicht das einzige zu sein.

MSI H510M-Pro Mainboard also has another problem. The Intel Managment Engine Manufactoring Mode is activated.
Quelle
 
Sehr komische News. :unsure:

Ich habe selbst so ein "betroffenes" Board von MSI, dass MSI Pro Z690-A DDR4 WiFi:

Screenshot 2023-01-19 at 11-51-23 MSI has very insecure Secure Boot defaults · Issue #181 · Fo...png


..und die Bios Version x1.43, die der "Professor Lustig" da getestet haben will gibt es bei MSI gar nicht (mehr) und das aus 2 Gründen:
a.) handelt es sich bei dieser Bios Version 100%ig um eine Beta vom 17.05.2022, dafür spricht das "43",
b.) werden Betas von MSI immer durch eine Final abgelöst, in diesem Fall hier die v1.40 vom 24.05.2022, die Betas werden danach dann wieder vom Server genommen.

..und schaut man sich dann einmal die Log zu der final v1.40 vom 24.05.2022 an, dann steht da unter anderen auch folgendes:
v1.40 final.png

Zudem sind nach dem v1.40 noch sage und schreibe 4 weitere Bios Updates gekommen, dass letzte ist vom 11.01.2023, also wenige Tage alt.

..vieleicht sollte der Forscher noch einmal "forschen" und einfach mal die kurz danach erschienene final Biosversion nehmen?
Denn ein "fixed following problem of the previous version setting of Secure Boot" implementiert eigentlich, dass da in der Final etwas gefixt wurde. :unsure:
 
Zuletzt bearbeitet:
  • Beschreibung:
    - Update to AGESA ComboAm4v2PI 1.2.0.7. - Change the default setting of Secure Boot.

mit dem MSI B450-A Pro, absolut garkeine Probleme

Gruss Dennis
Beitrag automatisch zusammengeführt:

Bios ist bei dem Brett ja sogar ziemlich identisch, da die Bretter sich nicht wirklich was nehmen
Unbenannt.jpg

Gruss Dennis
Beitrag automatisch zusammengeführt:

aber da hat man wohl das Januarbios zurückgezogen ja ?
7C02v3C vom 18. Januar 2022
Weil das aktuellste auf der Page ist ja 12-08-2022
Beitrag automatisch zusammengeführt:

Davon ab, wenn das erst Greifen muss, es ist afaik eine Vorrausetzung für Windows 11, für mich auch nicht mehr, wenn Schadware schon soweit gekommen ist, bringt mit eine solche Funktion dann auch nix mehr, denn isses längst zu spät :d

Gruss Dennis
 
Zuletzt bearbeitet:
Wow. Schockierend. Secure Boot war doch sonst immer so sicher und wurde quasi noch nie ausgehebelt.
Secure Boot hat nichts mit verschlüsselung zu tun. Es geht einfach darum, dass nur der von MS signierte Bootloader gestartet werden kann. Sicher oder Sinnvoll war Secure Boot noch nie.
Ich habe noch nie davon gehört, dass ein Trojaner in Windows den Bootloader durch eine VM ersetzt hat und das Windows dann komplett in einer VM läuft. Möglich wäre es ja, aber praktisch?
 
Ich habe nochmal nachgeschaut bei meinem MSI MPG Z790 Edge sind die Defaults mit der neusten produktiven Version ebenfalls auf Durchzug gestellt.

Wer jetzt sagt Secure Boot ist unwichtig, oder es ist alles super, der hat keinen Plan!
Secure Boot dient vor Allem dazu System vor Bootkits und Rootkits und ähnlichem zu schützen, welche am liebsten vor dem Start vom ELAM einnisten, denn dann sind die für AV praktisch unentdeckbar.
Davor schützt auch UEFI Kennwort nicht, wenn sich die Schadsoftware im Kernel einnistet...
SecureBoot.png



SecureBoot_2.png

Nach meinem Verständnis gab es zuviel Stress mit Secure Boot incidents mit Win11 Einführung, wodurch man gesagt hat "ach Hauptsache Windows meckert nicht und wir haben keine Probleme"
Absolutes No-Go ein Sicherheitsfeature so vom Werk aus zu manipulieren. (ACHTUNG SPEKULATION)

@nebulus1

@Mr.Mito
Wie nennst du es dann, wenn man ein Security Feature aktiviert und dann die Einstellungen soweit verändert, dass es ad absurdum führt?
Wer Linux betreiben will, wird schon eine Lösung finden und Secure Boot selbstständig ausmachen. Damit sind aber potentiell Tausende wenn nicht Millionen Kunden ungeschützt unterwegs.
 
Zuletzt bearbeitet:
Deswegen setzt man ja ein Passwort für das UEFI. Toller Sicherheitsexprte! Null Ahnung!
Bei Linux Standard, but Windows... "where is the Button?"
Beitrag automatisch zusammengeführt:

Secure Boot dient vor Allem dazu System vor Bootkits und Rootkits und ähnlichem zu schützen, welche am liebsten vor dem Start vom ELAM einnisten, denn dann sind die für AV praktisch unentdeckbar.
Davor schützt auch UEFI Kennwort nicht, wenn sich die Schadsoftware im Kernel einnistet...
Anhang anzeigen 843562
Ach joa und wie kommen wie auf's System, genau, abgesehen vom TPM schon immer wenn man sichs ins System reinzieht, wenn es am AV auch eben nicht vorhandenem AV (windows defender) dranvorbei schön tief ins System gekommen ist :d
Noch Fragen @nebulus1 ?
Wenn du nen Ubuntu (für einige kein richtiges Linux) aufsetzt ist das standard mit (U)EFI , Secure Boot und dem ganzen Zipp und Zapp aktiviert im Bios.
Da kannste garnicht das OS aufsetzen ohne das Passwort zu setzen ;-)

Unter so einem Sicheren Startschlüssel verstehe ich im übrigen das hier
Das ich mich am OS authentifiziere das ich das bin, weil des meine Karre ist, irgendwie andere Baustelle, genauso wie man wohl "Windows Hello?" sein Gesicht wie bei einem Smartphone verwenden könnte.
Unbenannt.jpg
Da funktioniert seit Jahren, auch auf Windows 10 schon nichts gescheit, lässt sich nicht einrichten.
Meine Fratze mit WebCam wie beim Smartphone, wäre kein Problem, genauso wenig so nen yubikey, is alles vorhanden.
Aber Google und Browser wie Firefox und Chrome unterstützen das schon seit mindestens 5 Jahren etwa, also auch YouTubeaccounts, danach kam denn dieser F2A-Krempel mit der Google-Authenticator app noch dazu....nuja...

Gruss Dennis
 
Zuletzt bearbeitet:
Wer Linux betreiben will, wird schon eine Lösung finden und Secure Boot selbstständig ausmachen. Damit sind aber potentiell Tausende wenn nicht Millionen Kunden ungeschützt unterwegs.

Es kommt auf die Distribution an. Debian, Ubuntu, Fedora haben keine Probleme mit Secure Boot. Man kann die ganze Geschichte sogar noch durch Kernelparameter ergänzen, sodass die frühe Startphase abgesichert ist.
 
Es kommt auf die Distribution an. Debian, Ubuntu, Fedora haben keine Probleme mit Secure Boot. Man kann die ganze Geschichte sogar noch durch Kernelparameter ergänzen, sodass die frühe Startphase abgesichert ist.
Ubuntu wie schon geschrieben, ist des Standard und zwar schon lange :-D

Gruss Dennis
 
Na dann gibt es ja noch weniger Gründe Secure Boot wie ein Scheunentor aufzumachen.
Am Ende bringt das Feature mehr Sicherheit für den Kunden, gerade für den Otto Normal Nutzer, der keinen Plan hat.
 
@Euphoria
is nur blöd das des bei Windows nicht so läuft wie mit beispielsweise Ubuntu, und nu ?
Ich hab mich bisher nicht weiter drum geschert, bei 10 nicht, sowie bei 11 nicht, "because i know what i'm doing" :coffee2:

Gruss Dennis
 
Sehr komische News. :unsure:

Ich habe selbst so ein "betroffenes" Board von MSI, dass MSI Pro Z690-A DDR4 WiFi:



..und die Bios Version x1.43, die der "Professor Lustig" da getestet haben will gibt es bei MSI gar nicht (mehr) und das aus 2 Gründen:
a.) handelt es sich bei dieser Bios Version 100%ig um eine Beta vom 17.05.2022, dafür spricht das "43",
b.) werden Betas von MSI immer durch eine Final abgelöst, in diesem Fall hier die v1.40 vom 24.05.2022, die Betas werden danach dann wieder vom Server genommen.

..und schaut man sich dann einmal die Log zu der final v1.40 vom 24.05.2022 an, dann steht da unter anderen auch folgendes:

Zudem sind nach dem v1.40 noch sage und schreibe 4 weitere Bios Updates gekommen, dass letzte ist vom 11.01.2023, also wenige Tage alt.

..vieleicht sollte der Forscher noch einmal "forschen" und einfach mal die kurz danach erschienene final Biosversion nehmen?
Denn ein "fixed following problem of the previous version setting of Secure Boot" implementiert eigentlich, dass da in der Final etwas gefixt wurde. :unsure:
Der "Professor Lustig" schreibt, dass ab dieser Version der Standard geändert wurde und dein Changelog wiederlegt das auch nicht, sondern sagt nur, dass der Standard geändert wurde. Es ist seit dem also per default an, aber scheinbar eben mit gesetztem "always execute" für unsignierte Bootloader.

Some example locations:

  • Settings/Advanced/Windows OS Configuration/Secure Boot
  • Security/Secure Boot

Then change "Always Execute" to "Deny Execute" on "Removable Media" and
"Fixed Media". Optionally you can also change "Option ROM" to "Deny
Execute", read more about Option ROMs:
Schau doch einfahc selbst mal nach.

Wie nennst du es dann, wenn man ein Security Feature aktiviert und dann die Einstellungen soweit verändert, dass es ad absurdum führt?
Wer Linux betreiben will, wird schon eine Lösung finden und Secure Boot selbstständig ausmachen. Damit sind aber potentiell Tausende wenn nicht Millionen Kunden ungeschützt unterwegs.
Unüberlegt bis ggf. dämlich gelöst nenne ich das. Wie bereits gesagt "Ob es sinnvoll ist, das so zu lösen, sei dahingestellt."
 
@Mr.Mito
Schön zitiert, genau das hab ich gemacht, 0 Problemo, damit an sich.

Aber vielleicht hat ja jemand ne Idee wie man nen Passwort mit Windows einrichten kann, was Ubuntu ab Werk, garnicht ohne zulässt :-)

Gruss Dennis
 
Was hat denn das Boot- oder Login-PW vom OS mit Secureboot zu tun?
 
Bei meinen MSI Torpedo Max wurde das bereits im Juli 2022 gefixt.
 
Danke, endlich stellt mal einer die richtige Frage. Kamst mir leider zuvor.
Kurzum, beispielsweise nach einem Biosupdate, eine Änderung die ja in Ordnung ist, muss du dann beim Hochfahren, bei Linux zumindest so aus der Praxis...,
Das Passwort wieder eingeben, dürfte dann schon im Bootloader so sein, bei Ubuntu ist das typischerweise "GRUB 2"

Du authorisiert dem Bootloader mit deinem gesetztem Passwort das die Änderung im Bios ok ist, dann fährt es auch hoch, ist das passwort falsch, weil da jemand unbefugtes dran war, fährt es nicht hoch, weil der unbefugte das Passwort natürlich nicht kennt.
Das in Zusammenspiel mit einem verschlüsseltem Datenträger (SSD), bei einem Notebook, is natürlich ziemlich save ;-)

Gruss Dennis
Beitrag automatisch zusammengeführt:

Dasselbe wäre es mit dem MBR (master Boot Record) oder eben GPT (GUID Partition Table), für mein Verständnis, aber dann wäre "GRUB 2" oder auch der Windows-Bootloader auch nicht mehr Original, aber da kommt ja eigentlich TPM in's Spiel
Beitrag automatisch zusammengeführt:

Wo aber immernoch nicht geklärt ist ob der Bug bei TPM 2.0 was wir ja alle maximal haben, es den immernoch gibt.
Irgendwann einmal, schon sehr lange her hab ich mal irgendwo nen Link dazu gepostet, ich glaub das war eventuell "heise" oder "golem" da wurde vor X Jahren jedenfalls von einem Bug bei TPM 2.0 berichtet wovon man nie wieder was gelesen oder gehört hat, das des mal gefixt worden ist.

"TPM fail" oder so ?

Gruss Dennis
 
Zuletzt bearbeitet:
Genau das ist nicht Secureboot.
Secureboot sorgt dafür, dass nur signierte Software gebootet wird. Software nicht signiert --> wird nicht gebootet.

Das von dir beschriebene Verhalten hat damit nix zu tun und hast du im übrigen auch bei Windows mit Bitlocker.
 
Hier hab ich mal eben was von 2019 gefunden

Unbenannt.jpg
Keine schlechte Seite, ähnlich wie Deskmodder
Beitrag automatisch zusammengeführt:

Genau das ist nicht Secureboot.
Secureboot sorgt dafür, dass nur signierte Software gebootet wird. Software nicht signiert --> wird nicht gebootet.

Das von dir beschriebene Verhalten hat damit nix zu tun und hast du im übrigen auch bei Windows mit Bitlocker.
Exakt das ist eben nicht Secure Boot, sondern TPM, nur mal kurz drüber nachgedacht warum viele gegen TPM waren als Systemvorraussetzung, keine Signatur keine Execution von der CPU davon...
Am Ende des Tages muss beides gescheit funktionieren, wie beschrieben.
Deswegen war es früher auch egal, wenn man Secure Boot deaktiviert und CSM nutzte, TPM hatten halt die wenigsten und Secure Boot alleine bringt halt nichts, was sich nun mit neuerer Hardware geändert hat, (f)TPM was in den aktuelleren, in all denen integriert ist.

Ansonsten hätte ich gerne eine gescheite Quelle dazu

Gruss Dennis
Beitrag automatisch zusammengeführt:

Bitlocker ist Windows eigenes TrueCrypt im übrigen, ganz andere Baustelle....
Beitrag automatisch zusammengeführt:

Zitat

Der Einsatz von Bitlocker setzt voraus, dass ein Windows-7-Ultimate- oder das Enterprise-Betriebssystem zum Einsatz kommt. Microsoft bietet die Laufwerksverschlüsselung leider nur auf diesen Versionen seines Client-Betriebssystems und auf dem Windows Server 2008 (und auch dem Windows Server 2008 R2) an.
und zudem, komisch das Bitlocker Secure Boot nicht vorraussetzt nicht wahr ?
Secure Boot hat Windows 7 vor kurzem erst bekommen... :d
Beitrag automatisch zusammengeführt:

Nur weil das eine auch eine Passworterstellung verlangt und das auch abfragt ist es nicht dasselbe oder eine "alte" Version davon...
TrueCrypt lief auch auf nem Athlon XP, da gab es kein Secureboot, kein (f)TPM und auch noch kein Bitlocker :-) (truecrypt und bitlocker sind aber an sich dasselbe als solches, datenträgerverschlüsselung mit Passworterstellung und Abfrage für den Zugriff, mitunter Booten ja, logisch, ohne Entschlüsselung kein Booten)
Beitrag automatisch zusammengeführt:

Man das waren noch Zeiten, da war ich noch jung als Truecrypt der heisse :poop: gewesen ist :lol: (ich bin Baujahr 1988 ;-) )
 
Zuletzt bearbeitet:
Statt ellenlange Posts abzusetzen und verschiedene Themen zu vermischen solltest du dich erstmal bezüglich Secureboot informieren.
 
Statt ellenlange Posts abzusetzen und verschiedene Themen zu vermischen solltest du dich erstmal bezüglich Secureboot informieren.
Du solltest mal verstehen, mit logischen Denken, wie deine Kiste funktioniert....
Beitrag automatisch zusammengeführt:

Vor dem Bootloader ist keine Verschlüsselung, man könnte den verschlüsselten Bootloader (partition) sonst nicht Booten, Datenträgerverschlüsselung kommt nach dem Bootloader bzw. mit dem Bootloader, ursprünglicherweise.
TPM ist nun aber mittlerweil Bestandteil davon, das kommt schon viel eher zum Einsatz und Verschlüsselung geht auch:
nennt sich mit meiner Kingston A-2000 dann "TCG-Opal 2.0" und ist soweit ich das sehe Bitlocker-kompatibel
 
Wer redet denn von Verschlüsselung? Darum geht es gar nicht.
Es geht darum, dass Secureboot nur signierte Software startet.

What is UEFI Secure Boot?

UEFI Secure boot is a verification mechanism for ensuring that code launched by firmware is trusted.
Proper, secure use of UEFI Secure Boot requires that each binary loaded at boot is validated against known keys, located in firmware, that denote trusted vendors and sources for the binaries, or trusted specific binaries that can be identified via cryptographic hashing.
Most x86 hardware comes from the factory pre-loaded with Microsoft keys. This means we can generally rely on the firmware on these systems to trust binaries that are signed by Microsoft, and the Linux community heavily relies on this assumption for Secure Boot to work. This is the same process used by Red Hat and SUSE, for instance.
Many ARM and other architectures also support UEFI Secure Boot, but may not be pre-loading keys in firmware. On these architectures, it may be necessary to re-sign boot images with a certificate that is loaded in firmware by the owner of the hardware.
 
Das von dir beschriebene Verhalten hat damit nix zu tun und hast du im übrigen auch bei Windows mit Bitlocker.
....
Beitrag automatisch zusammengeführt:

Ich kann im übrigen nix dazu, wenn du sinnvollen Vergleichen nicht folgen kannst...logisches Denken, weil man die Bude versteht
Und was passiert wenn "GRUB 2" geupdatet worden ist ? quasi ein Update mit Adminrechten..., joa ist ja geil das Secure Boot wa.... :d

Signaturen "fälschen" ist im übrigen nicht so schwer, deshalb schaltet man in AV's am besten auch aus, das wenn Signaturen vorhanden sind in Dateien, das diese dann nicht geprüft werden, weil die nunmal besser gepürft werden mit der Heuristik (wenn se denn gescheit ist und nicht false positive raushauen bis zum Abwinken)
Beitrag automatisch zusammengeführt:

Du solltest mal aufhören mit deinem Tunnelblick wie ein 14-Jähriger und mal das grosse ganze sehen...
Beitrag automatisch zusammengeführt:

Du kannst im Bios bei SecureBoot auch die Keys alle löschen, und dann ?
Da kommt denn das Passwort zum tragen...., auch da dann, damit die wieder eingetragen werden, zum Beispiel eben nach einem Biosupdate, folglich nem CMOS-Clear
Beitrag automatisch zusammengeführt:

Desweiteren, Zitat:
Ein zweiter Schlüssel, Attestation Identity Key (AIK) genannt, schützt das Gerät vor nicht autorisierter Firmware- und Softwareänderung, indem er kritische Abschnitte von diesen hasht, bevor er sie ausführt. Wenn das System versucht, eine Verbindung zum Netzwerk herzustellen, werden die Hashes an einen Server gesendet, der überprüft, ob sie mit den erwarteten Werten übereinstimmen. Bei Änderungen an der gehashten Komponente schlagen die Übereinstimmung fehl und das System erhält keinen Zugang zum Netzwerk.


Alter Kakao...
Was ist denn bitte Firmware... BIOS, genauso auch das was eine Grafikkarte hat, SSD's, HDD's.....
Klingelts ?

Gruss Dennis
Beitrag automatisch zusammengeführt:

Oder auch das Mikrocodeupdate (für die CPU, bei veralteter Version im Bios davon) über Bootloader, was man bei Windows seitens MS mittlerweile genauso macht, seit Win10 spätestens denk sogar Win8 bzw 8.1 sogar schon, wie bei Linux, beispielsweise mit GRUB2 bei der Ubuntu-Distribution....
 
Zuletzt bearbeitet:
Der Sicherheitsexperte scheint ja sein Geld wirklich wert zu sein, wenn er ein nötiges - und bei Powerusern hinlänglich bekanntem - _Feature_ übertrieben aufgebauscht als Sicherheitslücke anprangern muss, um Aufmerksamkeit zu erzeugen.
Wer Motherboards selber einbaut sollte auch ins Bios schauen und macht das auch für gewöhnlich. Da gibts noch ganz andere Optionen die viel unsicherer sind. Ob das default so eingestellt sein sollte, kann man drüber streiten, aber Biossettings zu überprüfen ist Pflicht des Users. Viel wichtiger ist, dass MSI secureboot umgehen kann um die unsäglichen Gängelungen seitens MIcrosoft abfedern zu können, wenn schon die Presse viel zu oft M$ in den Allerwertesten kriecht.. Ansonsten würde so manch anderes Betriebssystem gar nicht booten können. Und Microsoft ist wie bei Browsern kein Move zu schäbig, um Alternativen rauszudrängen oder ganz zu unterbinden... natürlich alles NUR im Sinne des Users und seiner Sicherheit.
 
Meine Randnotiz bezüglich Bitlocker bezog ich auf:
Kurzum, beispielsweise nach einem Biosupdate, eine Änderung die ja in Ordnung ist, muss du dann beim Hochfahren, bei Linux zumindest so aus der Praxis...,
Das Passwort wieder eingeben, dürfte dann schon im Bootloader so sein, bei Ubuntu ist das typischerweise "GRUB 2"

Du authorisiert dem Bootloader mit deinem gesetztem Passwort das die Änderung im Bios ok ist, dann fährt es auch hoch, ist das passwort falsch, weil da jemand unbefugtes dran war, fährt es nicht hoch, weil der unbefugte das Passwort natürlich nicht kennt.

Ich kann im übrigen nix dazu, wenn du sinnvollen Vergleichen nicht folgen kannst...logisches Denken, weil man die Bude versteht
Der Vergleich ist halt einfach Inhaltlich falsch.

Und was passiert wenn "GRUB 2" geupdatet worden ist ? quasi ein Update mit Adminrechten..., joa ist ja geil das Secure Boot wa.... :d
Schau in den oben geposteten Link.

Signaturen "fälschen" ist im übrigen nicht so schwer,
Kann man nicht.

deshalb schaltet man in AV's am besten auch aus, das wenn Signaturen vorhanden sind in Dateien, das diese dann nicht geprüft werden, weil die nunmal besser gepürft werden mit der Heuristik (wenn se denn gescheit ist und nicht false positive raushauen bis zum Abwinken)
Wieder ein ganz anderes Thema.

Du solltest mal aufhören mit deinem Tunnelblick wie ein 14-Jähriger und mal das grosse ganze sehen...
Wenn man inhaltlich nicht weiter kommt... .

Du kannst im Bios bei SecureBoot auch die Keys alle löschen, und dann ?
Dann bootet gar keine Software mehr, bis du wieder Keys importiert oder Secureboot deaktiviert hast.

Da kommt denn das Passwort zum tragen...., auch da dann, damit die wieder eingetragen werden, zum Beispiel eben nach einem Biosupdate, folglich nem CMOS-Clear
Soweit kommst du gar nicht.
 
Puh, selbst wenn in den Beiträgen von Dennis was korrektes drin stehen würde, habe ich irgendwie gar keine Lust mich durch die zusammengefassten Beiträge zu wühlen.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh