Schwachstellen in IT-Sicherheitsprodukten mit BSI-Freigabe?

Lässt das Bundesamt für Sicherheit in der Informationstechnik (BSI) IT-Sicherheitsprodukte zu, die durch eklatante Programmierfehler potentielle Sicherheitsprobleme aufwerfen können? Dieser Verdacht ist bei mir zumindest aufgetaucht und ich dokumentiere im Blog-Beitrag den bisher bekannten Sachverhalt.


Anzeige

Anmerkung: Aktuell kann ich die im Titel gestellte Frage final nicht beantworten und habe das Bundesamt für Sicherheit in der Informationstechnik (BSI) über deren Presseabteilung um Klärung und Stellungnahme gebeten. Jetzt geht es erst einmal darum, den Sachstand, wie er sich mir momentan darstellt, festzuhalten.

Vom BSI zugelassene IT-Sicherheitsprodukte und –systeme

Vom Bundesamt für Sicherheit in der Informationstechnik (BSI) werden IT-Sicherheitsprodukte und ganze IT-Sicherheitssysteme zertifiziert. Das ist in meinen Augen eigentlich eine gute Sache, gibt die Zulassung Endanwendern und IT-Verantwortlichen (speziell in Bereichen, wo Verschlusssachen zu handhaben sind) doch eine Leitlinie an der Hand, welche Sicherheitsprodukte man 'guten Gewissens', da BSI-geprüft, einsetzen kann.

Die Liste dieser Produkte kann z.B. in der BSI-Schrift 7164: Liste der zugelassenen IT-Sicherheitsprodukte und –systeme eingesehen werden. Eine FAQ des BSI gibt umfassend Auskunft, was sich hinter der Liste der zugelassenen Produkte verbirg. Interessant finde ich den Punkt Für welche IT-Sicherheitsprodukte wird eine Zulassung gefordert?:

Grundsätzlich sind alle IT-Sicherheitsprodukte, die für die Verarbeitung und Übertragung von Verschlusssachen eingesetzt werden, einer Prüfung und Sicherheitsbeurteilung zu unterziehen. §37 der VSA legt die Details hierzu fest. Es wird unterschieden zwischen IT-Sicherheitsprodukten, die vom BSI zugelassen sein müssen, und IT-Sicherheitsprodukten, die zugelassen sein sollen. Die zweite Gruppe lässt Ausnahmen zu, falls keine geeigneten zugelassenen Produkte zur Verfügung stehen. Hierbei sind immer die Belange der nationalen Sicherheit zu berücksichtigen. In der Regel kommen dabei IT-Sicherheitsprodukte zum Einsatz, die nach Common Criteria mit nationalem Schutzprofil durch das BSI zertifiziert wurden.

Es geht also um IT-Sicherheitsprodukte zur Verarbeitung und Übertragen von Verschlusssachen, die einer Prüfung und Sicherheitsbeurteilung zu unterziehen sind.

Sicherheitstechnische Programmierfallen

Zum weiteren Verständnis der Problemstellung nun ein kleiner Schlenker. Zum Wochenende habe ich den Beitrag Classic Shell heißt jetzt Open-Shell-Menü veröffentlicht. Im Blog-Beitrag werden auch einige sicherheitsrelevante Schwachstellen durch Programmierfehler im Installationsprogramm dieser Software angesprochen. Solche leicht vermeidbaren Programmierfehler kommen leider häufiger vor. Auf diesen Sachverhalt wurde ich von dem Sicherheitsexperten Stefan Kanthak bereits vor längerer Zeit aufmerksam gemacht.

Diese Programmierfehler führen dazu, dass sich Malware in den Installationsvorgang einer Software einklinken kann, um auf diese Weise administrative Berechtigungen zu erlangen. Zudem könnten Installationsdateien modifiziert werden, so dass sich eine Malware in einem Produkt einnisten kann. Bestimme Fehler ermöglichen es auch in den späteren Betrieb einer Software durch Schadsoftware einzugreifen. Stichwort ist u.a. 'DLL search order hijacking', ein Sicherheitsproblem, welches lange bekannt ist und welches es in der Implementierung von Programmen zu vermeiden gilt.

Sicherheitsexperte Stefan Kanthak stellt für Tests eine Art 'sicherheitstechnisches Minenfeld' bereit (die Tools können von seiner Homepage frei abgerufen werden). Diese Test-Tools decken potentielle Schwachstellen beim Aufruf eines Installers oder beim Betrieb einer Software auf. Nachfolgender Screenshot zeigt das Ergebnis eines solchen Tests mit der im obigen Blog-Beitrag erwähnten Software ClassicStartSetup.

Warnung beim Aufruf
(Zum Vergrößern klicken)


Anzeige

Im konkreten Fall schlägt ein Modul aus dem Minenfeld bereits beim Aufruf der Hilfefunktion des Installers für das oben erwähnte Programm an. Gut, zurück zum Kernproblem, welches in diesem Beitrag umrissen werden soll.

Hat Software mit BSI-Zulassung diese Schwachstellen?

Bisher bin ich davon ausgegangen, dass vom BSI zugelassenen IT-Sicherheitsprodukte und –systeme vorher einer umfassenden Prüfung unterzogen werden (vielleicht bin ich da naiv). Dieses Bild hat aber jetzt Risse bekommen, oder ich habe was falsch verstanden, was die BSI-Zulassung konkret bedeutet. Oder das Problem kann vom BSI nicht bestätigt werden – alles ist möglich.

Worum geht es?

Im Rahmen des Blog-Beitrags Classic Shell heißt jetzt Open-Shell-Menü hat sich ein Blog-Leser mit folgendem Kommentar gemeldet:

Ich möchte (hierzu halbwegs passend) mitteilen, dass selbst vom BSI explizit für die Verarbeitung von VS-NfD-eingestuften Daten zugelassene Programme (siehe hier) diese Probleme aufweisen. Ich nutze sowohl Ecos SBS als auch Sirrix/Rohde und Schwarz Trusted Disk. Der Sentinel von Herrn Kanthak schlägt sowohl beim Enrollment von Ecos an, als auch beim Verwenden der Trusted Disk Hilfskomponente CardOS API von ATOS.

Man sollte meinen, dass das BSI solche Dinge in seinen Prüfungen finden sollte. Ich habe dies auch vor längerer Zeit dem Support von ATOS mitgeteilt, erhielt aber keine Antwort.

[Günter Born]Kurze Anmerkung für nicht so erfahrene Blog-Leser/innen: Enrollment meint die Installation der Software. Aber auch beim Betrieb der Software meldet eine Testkomponente potentielle Sicherheitsprobleme in einer Trusted Disk-Hilfskomponente.

Ich habe natürlich sofort die betreffende Liste in der BSI-Schrift 7164: Liste der zugelassenen IT-Sicherheitsprodukte und –systeme  eingesehen und ein erwähntes Produkt gefunden.


(Zum Vergrößern klicken)

Vom BSI wurde z.B. Trusted Disk in verschiedenen Versionen zugelassen. Ich selbst verfüge nicht über diese Produkte, kann also nichts testen. Der Kommentator gibt aber an, dass in seiner Umgebung das Testprogramm Sentinel von Stefan Kanthak anschlägt und Probleme meldet. Ließ bei mir sämtliche Alarmglocken läuten.

Oh mein Gott: Es geht weiter …

Im Kommentarbereich stellt Stefan Kanthak einige Vermutungen an und stellt einige Fragen. Unter anderem, ob ein Registrierungseintrag der Art:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
"CardOS API"="C:\Program Files\…\cardoscp.exe"

mit Anführungszeichen versehen sei. Hintergrund ist, dass Programmpfade, die Leerzeichen enthalten, in Windows zwingend in Anführungszeichen zu stellen sind. Nur dann kann der Programmpfad zur angegebenen Datei durch Windows korrekt aufgelöst werden. Fehlen die Anführungszeichen, schlägt die Pfadangabe fehlt – Windows kann die angegebene Datei nicht finden und beginnt mit einer Suche nach einer passenden Datei.

Dies ermöglicht Schadsoftware, entsprechende Dateien im Windows-Suchpfad zu platzieren. Statt der erwarteten Komponente lädt Windows dann die von der Schadsoftware manipulierten Programmdateien. Diese Programmierfalle ist seit langem in der Common Weakness Enumeration unter dem Titel CWE-428: Unquoted Search Path or Element beschrieben. Die Einstufung lautet: Abstraction Basic, Structure Simple – sprich, das ist Basiswissen und die Ausnutzung ist einfach. Jeder Software-Entwickler sollte das im Schlaf drauf haben – und eine Qualitätskontrolle muss solche Fehler aufdecken. In diesem Kommentar schreibt der Nutzer der Software:

Du hast Recht bezüglich der Anführungszeichen.

Noch mehr: Ausgabe von Sentinel:
ATTENTION!
This might have been the call and the execution of a malicious executable (worm, virus, trojan horse)!
Executed process: C:\Program.exe
Executed command: C:\Program Files\CardOS API\bin\chkscreg.exe
Calling process: cardoscp.exe
Current directory: C:\WINDOWS\System32

und ein zweites Mal:
Executed process: C:\Program.exe
Executed command: C:\Program Files\CardOS API\bin\chkscreg64.exe
Calling process: cardoscp.exe
Current directory: C:\WINDOWS\System32

Kurz erklärt: Die Anführungszeichen fehlen in einem in der Registrierung vorgenommenen Programmaufruf im Schlüssel Run. Dieser (oben erwähnte) Schlüssel dient dazu, Programme systemweit als automatisch bei jedem Windows-Start auszuführend einzutragen. Sprich: Die fehlenden Anführungszeichen eröffnen einer Malware die Möglichkeit, eine im Suchpfad platzierte Schadsoftware bei jedem Windows-Start auszuführen. Weiterhin wird die 'digitale Mine' Sentinel bei der Ausführung des Programmes Program.exe von einer Hilfskomponente aufgerufen.

Fazit: Anfrage an das BSI

Mein vorläufiger Schluss: Es gibt starke Anhaltspunkte, dass es dort möglicherweise Sicherheitsprobleme in zugelassenen Produkten gibt. Die Relativierung deshalb, weil mir weder die betreffende Software noch Informationen über die in obigem Kommentaren getestete Softwareversion vorliegen.

Ich sehe es auch nicht als meine originäre Aufgabe an, essentielle Sicherheitsforschung in diesem Bereich zu betreiben. Vielleicht halten der betroffene Nutzer und Stefan Kanthak mich bzw. uns diesbezüglich auf dem Laufenden.

Ich habe den Sachverhalt als Blogger zum Anlass genommen, die wichtigsten Eckpunkte in diesem Blog-Beitrag öffentlich zu dokumentieren – und einige Hinweise auf Implikationen für Leser/innen unterzubringen, die nicht so tief 'in der Technik' drin sind. Gleichzeitig habe ich eine Anfrage an die Presseabteilung des BSI geschickt. Dort verweise ich auf diesen Beitrag und bitte um Klärung sowie Stellungnahme zum Sachverhalt. Aus meiner Sicht gibt es nun folgende Szenarien.

  • Entweder, diese Art Prüfungen gehören nicht zum Aufgabenumfang der BSI-Zulassung und das Bundesamt sieht sich nicht zuständig.
  • Oder es gibt dieses Problem nicht (mehr). Dann wäre, zumindest bei den hier kurz angerissenen Produkten, alles im grünen Bereich.
  • Oder das Problem wird bestätigt, der Fall wird aufgegriffen, und die Hersteller bessern nach. Dann hätte der Blog-Beitrag zumindest etwas positives.

Den vierten Fall: Das Problem wird bestätigt, aber nichts tut sich, mag ich erst gar nicht ins Auge fassen. Über weitere Erkenntnisse werde ich meine Blog-Leserschaft auf dem Laufenden halten.

Ähnliche Artikel:
Classic Shell heißt jetzt Open-Shell-Menü
Microsoft und die Office 20xx-Sicherheitslücke in ose.exe
Skype-Sicherheitslücke angeblich seit Oktober 2017 gefixt
Warnung: Auf 7-Zip verzichten


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit abgelegt und mit verschlagwortet. Setze ein Lesezeichen auf den Permalink.

14 Antworten zu Schwachstellen in IT-Sicherheitsprodukten mit BSI-Freigabe?

  1. Theo sagt:

    Ich vermute mal ganz stark Szenario 1:
    Es wird gar nicht getestet was bei einer Installation gemacht werden kann (Umleitung/DLL-Hijacking usw.). Die Software wird installiert und durchgeklickert, fertig. Ich kann mir nicht vorstellen das beispielsweise auch Stack-Overflow usw. zum Testszenario gehören, viel zu langwierig, viel zu kompliziert… ;-)

    Früher waren Coder und Programmierer dafür verantwortlich was mit den Daten passiert, heute ist es halt ein CPU-Fehler den andere patchen müssen. Schöne neue Welt.

  2. Ingo sagt:

    Ich denke, gerade diese Problematik wird an vielen Stellen nicht beachtet. Weder Pfadangaben beim Laden der Prozesse noch Dateiberechtigungen sind ein Thema, welches eine besonders große Aufmerksamkeit erfährt. Egal ob beim BSI oder bei den Herstellern.

    Ich habe vor zwei Jahren an den Hersteller einer Sicherheitssoftware (!) das Problem gemeldet, dass dessen Business-Version einerseits ihre mit Systemrechten geladenen Treiber sowie das Programmverzeichnis mit Dateisystemrechten "Jeder/Vollzugriff" einrichtet.
    Für die Prozesse wurde das einige Wochen später geändert, nachdem man zuerst abgewiegelt hat und eine Ausnutzbarkeit bestritt. Die Prozesse würden ja ständig laufen und sich gegenseitig überprüfen. Was ein Bug in einem der Prozesse kurze Zeit später ad-absurdum geführt hat.
    Die Berechtigung für das Programmverzeichnis selber hat man jetzt nach knapp zwei Jahren korrigiert.

    Das sind so grundlegende Anfängerfehler, dass man Programme in einem Verzeichnis installiert, wo ein User Schreibzugriff hat. Sowas macht man nicht. Sowas macht man nicht als kleiner Jungprogrammierer und sowas macht man absolut keinesfalls bei einer Sicherheitssoftware. Ich schreibe daher ja gerne "Sicherheitssoftware", denn die Installation der Software führte ja mal wieder zu weniger Sicherheit…

  3. Günter Born sagt:

    Antwort des BSI

    Das BSI hat auf meine Anfrage geantwortet. Ich stelle die Antwort einfach mal ohne Kommentar ein. Wer die vom BSI freigegebenen Produkte einsetzt, kann ja nach den obigen Angaben prüfen, ob die Schwachstellen existieren.
    ———————————————————–
    Sehr geehrter Hr. Born,

    vielen Dank für Ihre Hinweise zum ECOS SBS und zu Trusted Disk. Ihrem Wunsch nach Klärung und Stellungnahme zum dargestellten Sachverhalt kommen wir gerne nach.

    Das BSI ist den Hinweisen nachgegangen und hat auch die jeweiligen Hersteller bei der Überprüfung eingebunden. Im Ergebnis kommt das BSI zu dem Schluss, dass die vom BSI zugelassenen Versionen sicher sind und die dargestellten Sicherheitsprobleme dort nicht auftreten. Bei dieser Bewertung wurde die Einhaltung der Einsatz- und Betriebsbedingungen unterstellt, welche ein Ergebnis des Evaluierungsprozesses sind. Die Evaluierung ist der Zulassung der Produkte grundsätzlich vorgeschaltet. Ohne Einhaltung der Einsatz- und Betriebsbedingungen ist kein zulassungskonformer Betrieb gegeben und die Sicherheit kann nicht garantiert werden.

    Bei weiteren Fragen steht Ihnen die BSI-Pressestelle gerne zur Verfügung.

    Mit freundlichen Grüßen,

    —–
    Ich interpretiere dies so, dass der Einsatz der Sicherheitsprodukte auf einem Schadprogramm-freien Betriebssystem erfolgen muss, damit die Einsatz- und Betriebsbedingungen erfüllt sind.

    • Ralf Lindemann sagt:

      So würde ich die Stellungnahme des BSI auch verstehen. Der springende Punkt scheint zu sein: Das Ausnutzen der beschriebenen Schwachstelle setzt voraus, dass ein System kompromittiert und mit Malware behaftet ist. Ein sicherer Betrieb ist in diesem Fall generell nicht gewährleistet: das Kind ist sozusagen längst in den Brunnen gefallen … – Erschreckend an der Geschichte ist die Sorglosigkeit, mit der offenbar selbst renommierte Software-Hersteller bewusst Risiken in Kauf nehmen, die nicht nötig wären. Die eher phlegmatische Reaktion des BSI macht es nicht besser.

  4. Uwe Kernchen sagt:

    Das BSI ist der Feind.

    2008 wandte sich das Bundeskriminalamt (BKA) an das BSI und bat dieses, den als "Remote Forensic Software" (RFS) titulierten Bundestrojaner "im Bereich der kryptographischen Absicherung" mitzuentwickeln. Im Juli 2008 entschied der damalige Bundesinnenminister Wolfgang Schäuble (CDU), dass das BSI dem Gesuch "in vollem Umfang" nachkommen, aber nicht am "operativen Einsatz" der Schadsoftware mitwirken solle, um nach außen hin weiter eine weiße Weste präsentieren zu können. Know-how solle über das Kompetenzzentrum Telekommunikationsüberwachung ausgetauscht werden.

    Quelle: https://www.heise.de/newsticker/meldung/Geheimpapiere-BSI-entwickelte-Bundestrojaner-mit-2577582.html

    Im aktuellen IT-Sicherheitsgesetz werden Betreiber kritischer Infrastruktur verpflichtet, alle potetiellen Schwachstellen ihrer Infrastruktur an eben jenes BSI zu übermitteln.
    Wer das macht, ist verraten und verkauft…

  5. Bernhard Diener sagt:

    Oh Mann. Das BSI ist diesen Problemen in keinster Weise nachgegangen, anderfalls hätten sie diese Fehler sofort zugeben müssen, denn sie lassen sich ja auf sauberen Systemen ganz gleich welche Windows OS, sofort nachstellen: Kanthaks Sentinel installieren, Atos Card OS API 5.4 Update 11 installieren, Rechner neustarten, anmelden – Bums springt einem die Sentinel Warnemldung ins Gesicht.
    Geht das BSI davon aus, dass man sich nun mit dieser Aussage abfindet?

    Zudem kommt: das Ecos-Problem wurde von Herrn Born ja nicht einmal benannt, es wurde nur namentlich angedeutet – das BSI kann diesem gar nicht nachgegangen sein. Ich verwende das Ecos-Produkt und kann ja mal den Support von Ecos befragen, ob das BSI bei denen überhaupt angeklopft hat – ich melde mich.

  6. Bernhard Diener sagt:

    und noch einmal der Vollständigkeit halber zu Ecos: Sie benutzen Reiner SCT Cyberjack Cardreader und die brauchen einen Treiber und der ist das Problem. Steckt man zum Rollout lediglich den Cardreader an, kommt von Sentinel

    —————————
    Vulnerability and Exploit Detector
    —————————
    ATTENTION!

    This might have been the call and the execution of a malicious executable (worm, virus, trojan horse)!
    Executed process: C:\Program.exe
    Executed command: C:\Program Files (x86)\REINER SCT\cyberJack\cjcc.exe /CH /PNP
    Calling process: cjpcsc.exe
    Current directory: C:\WINDOWS\system32
    Privilege or integrity level: Medium Mandatory Level

    Das Treiberprogramm ist frei verfügbar: http://downloads.reiner-sct.de/bc_7_6_1.exe

    Kann jeder ausprobieren, der ein Reiner Cyberjack Cardreadergerät hat. Diese werden auch von Banken zum sicheren onlinebanking ausgegeben.

    Das kommt davon, wenn man als 3rd party Infos weitergibt, Herr Born: es wird schlicht nicht verstanden. Einfache reproduzierbare Schritte, einfache, konkrete Fragen und Bitten dazu, besser als Links auf riesige Forendiskussionen.

    • | Das Treiberprogramm ist frei verfügbar: …

      Das ist nicht der Treiberprogramm, sondern das "Treiber"-Installationsprogramm, und wie industrie-üblich, MINDERWERTIGER und UNSICHERER SCHROTT!

      1. Reiner SCT hat es mit einer selbstverständlich VÖLLIG veralteten Version von InstallShield verbrochen, die alle von einem Angreifer gewünschten Schwachstellen hat.

      Rechtsklick auf bc_7_6_1.exe, dann zum Reiter Version wechseln:
      | Copyright (c) 2013 Flexera Software LLC. All Rights

      2. Das Programm bc_7_6_1.exe hat folgende statische Abhängigkeiten (sprich: DLLs), die es (mit Ausnahme der "known DLLs" und deren Abhängigkeiten) aus seinem "application directory" (sprich: dem Verzeichnis, in dem es selbst gespeichert ist) lädt:

      | LINK.exe /DUMP /DEPENDENTS bc_7_6_1.exe

      | Image has the following dependencies:
      |
      | COMCTL32.dll
      | VERSION.dll
      | LZ32.dll
      | msi.dll
      | KERNEL32.dll
      | USER32.dll
      | GDI32.dll
      | ADVAPI32.dll
      | SHELL32.dll
      | ole32.dll
      | OLEAUT32.dll
      | RPCRT4.dll

      Mindestens VERSION.dll und MSI.dll werden mit dem Programm geladen. und deren Start-Routinen noch VOR dem Programm selbst ausgeführt. Zusätzlich dürften nach dem Start des Programms noch UXTheme.dll und/oder DWMAPI.dll sowie etliche andere DLLs geladen werden.

      Otto Normalverbraucher speichert dieses Programm wie all den anderen Müll typischerweise in seinem "Downloads"-Ordner … wo andere Programme (oder der für "drive-by"-Downloads missbrauchte Web-Browser) die gerade genannten DLLs ablegen können.

      3. Das im Programm bc_7_6_1.exe eingebettete "application manifest" spezifiziert
      | <requestedExecutionLevel level="requireAdministrator"

      Die o.g. DLLs werden also mit Administratorrechten ausgeführt.

      Um es mit Boris Becker^WAOL zu sagen: bin ich schon drin?!

      • Bernhard Diener sagt:

        Danke für die Ausführungen, Stefan.

        Ich habe auch Ecos angeschrieben und erhielt heute Antwort:
        ———–
        Sehr geehrter Herr Y,

        der Reiner SCT Reader ist für den Betrieb am ECOS SECURE BOOT STICK eine von zwei Alternativen und in dem Zusammenhang auch getestet. Dies bezieht sich aber nur auf den Betrieb am Bootstick und hat erstmal nichts mit dem Schreiben von Smartcards unter Windows zu tun.

        Es bietet sich natürlich auch an diesen Reader dann unter Windows für das Smartcard-Enrollment zu nutzen. Dies ist aber nicht Teil der ECOS Software und auch nicht Teil der vom BSI zugelassenen Lösung. Es steht Ihnen insofern frei unter Windows einen anderen Smartcardreader einzusetzen. Vom BSI für den zugelassen Betrieb ist aber sehr wohl vorgeschrieben, das das Smartcard-Enrollment in einer sicheren Umgebung stattfinden muss. Dies ist auch naheliegend, da die Smartcards ja der zentrale Sicherheitsanker sind. Insofern ich davon ausgehe, dass dies auch bei Ihnen der Fall ist, sehe ich kein _akutes_ Sicherheitsproblem.

        Sehr wohl nehmen wir das aber sehr ernst. Da es sich nicht um unsere Software handelt, müssen wir dazu aber den Softwarehersteller befragen und sind auf ein Update von diesem angewiesen.
        Wir haben eine entsprechende Anfrage gestellt und ich informieren Sie sobald es von dieser Seite Neuigkeiten gibt.

        Sollte der Softwarehersteller in einer angemessenen Zeit kein Update zur Verfügung stellen, empfehlen wir, einen anderen Smartcardreader einzusetzen.

        Für weitere Fragen stehe ich gern zur Verfügung

        Mit freundlichen Grüßen

        X.X
        Technischer Geschäftsführer
        ——————

        Die Antwort von Sirrix steht noch aus. Sie sagten mir aber schon, sie würden mit Atos Kontakt aufnehmen.
        Dass sich das BSI bei ihnen wegen dieser Angelegenheit schon gemeldet hätte, erwähnte niemand, habe ich aber auch nicht gefragt.

        • Ich LIEBE Aussagen wie "Vom BSI für den zugelassen Betrieb ist aber sehr wohl vorgeschrieben, das das Smartcard-Enrollment in einer sicheren Umgebung stattfinden muss." von Herstellern, deren kaputte Software (m)eine sichere Umgebung Dank BLUTIGER Anfängerfehler unsicher macht!

          JFTR: es gibt zahlreiche Möglichkeiten, beliebige ausführbare Dateien unter den Namen %SystemDrive%\Program, %SystemDrive%\Program.com und %SystemDrive%\Program.exe, bzw. "%SystemDrive%\Program Files\REINER", "%SystemDrive%\Program Files\REINER.exe" und "%SystemDrive%\Program Files\REINER.com" zu erstellen, in Standard-Installationen von Windows auch OHNE UAC-Prompt…

  7. Bernhard Diener sagt:

    Schick… nun werden meine Kommentare schon gelöscht!?

    • Günter Born sagt:

      @Bernhard Diener: Den Abschnitt 'Das kommt davon, wenn man als 3rd party Infos weitergibt, Herr Born: es wird schlicht nicht verstanden. Einfache reproduzierbare Schritte, einfache, konkrete Fragen und Bitten dazu, besser als Links auf riesige Forendiskussionen." musst Du mir erklären.

      Und 'Schick… nun werden meine Kommentare schon gelöscht!?' verstehe ich in Bezug auf den Blog erst Recht nicht. Vielleicht auch den Beitrag Hinweise zur Kommentarfunktion (siehe auch FAQ im Seitenkopf) im Blog mal lesen – obwohl ich im Papierkorb nichts gefunden habe – d.h. es müsste da was gravierendes im Kommentar gewesen sein, dass die SPAM-Filter alles kommentarlos gelöscht haben. Bewusst gelöscht wurde von mir nichts …

  8. Bernhard Diener sagt:

    Ich hatte den Kommentar von 10:45, welcher nun auf wundersame Weise wieder da ist, gemeint. Ich hatte mehrmals refreshed, aber der Kommentar war weg.

    Zu meinem "Das kommt davon…" – ich denke, das BSI macht es sich sehr einfach: Pressestelle fragt: "sind uns Sicherheitsprobleme derzeit bekannt?" -> Zertifizierung: "nö, wir haben einen zugelassenen Zustand und dort ist nichts an Problemen bekannt". Hätte man Ihnen geschrieben: 1) laden Sie cardos api runter, installieren Sie, 2) laden Sie Sentinel runter, installieren Sie, 3) starten Sie den Rechner neu und melden Sie sich an, schon kommt die Warnmeldung, dann hätte der Tester aus der Zertifizierung einen klaren Auftrag zum Reproduzieren gehabt, den er in 5 Minuten hätte nachstellen können.

    Sagt man ihm jedoch, schau Dir mal folgenden, seitenlangen Thread an, dann liest doch mancher nur quer und versteht kaum, worum es überhaupt geht und tut die Sache ab. Die Sache hat mit "Einhaltung der Einsatz- und Betriebsbedingungen" mal rein gar nichts zu tun, denn diese untersagen keinesfalls, Rechner neu zu starten und es wäre absurd zu fordern, dass diese Software nur auf Rechnern eingesetzt werden darf, wo keine weitere Software wie Sentinel läuft. Von Malware ist meinerseits doch gar nicht die Rede – ich nutze Sentinel und ich möchte keine Programme, die Sentinel nicht mag, benutzen, das ist alles (bin aber dazu gezwungen, da ich R&S trusted Disk nutze, bzw. Ecos SBS). Dass BSI würde mit Sicherheit zustimmen, dass da ein Fehler vorliegt, wenn sie es nur verstehen würden.

  9. Gerald Richter / ECOS sagt:

    Der ECOS SECURE BOOT STICK ist ein Linux basiertes System, insofern war ich etwas verwundert zu lesen, dass dieser eine nur auf Windows vorkommende Schwachstelle haben soll.

    Nachdem der eigentliche Beitrag das völlig im Dunkeln lässt, zeigt der Kommentar von Herrn Diener, dass es gar nicht um die ECOS Software geht, sondern anscheinend um die Smartcardreader-Software, die in diesem Fall benutzt wird, um für den ECOS SECURE BOOTSTICK Smartcards zu erstellen. Ich möchte drauf hinweisen, dass diese Software nicht Teil der ECOS Lösung ist und auch nicht Teil der BSI Zulassung des Bootsticks war. Die Smartcards müssen, laut Zulassung, in einer sicheren Umgebung personalisiert werden. Diese muss aber nicht mit einem bestimmten Smartcardreader erfolgen.

    Schade ist, dass dies vom Blog Autor nicht vorher recherchiert wurde und vom ursprünglichen Kommentarschreiber dies niemals an uns gemeldet wurde, damit wir dem hätten nachgehen können. So bleibt statt der beabsichtigten Warnung vor einer Sicherheitslücke, ein fader Beigeschmack der Unprofessionalität übrig.

Schreibe einen Kommentar zu Stefan Kanthak Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.