Hallo zusammen, wir hatten hier neulich eine Diskussion, wie man Zugangsdaten für Programme fest hinterlegen kann, ohne, dass man damit eine Sicherheitslücke schafft. Es ging in unserem Fall um einen Zugang zu einem ERP Produktivsystem, wobei der verwendete Nutzer weitgehend nur Leseberechtigung in ausgewählte Bereiche hat. Schindluder kann damit eigentlich nicht getrieben werden, sensible Bereiche sind mit diesem Zugang nicht einsehbar, nur die Materialstammdaten und Produktionsdaten zu Fertigungsaufträgen und ähnlichem. Aber ganz generell: So ein String in einer Exe ist eine förmliche Einladung, den Disassembler anzuwerfen. Die Credentials herauszufinden ist für erfahrene Cracker eigentlich nur eine Fingerübung. Obfuskation hilft da auch nicht viel, wenngleich es den Aufwand erhöht. Ändert aber am Kern nichts. Da wurde die Diskussion dann ganz generell: Wie machen das Programme, die Zugriff auf irgendwelche Serverdaten erhalten? Mal als profanes Beispiel die ELSTER-Software. Sie hat eine direkte Verbindung auf die Finanzamtserver, um dort Steuererklärungen abzulegen. Irgendwie muss sich ja der Client dort verifizieren. Der Nutzer selbst, der die Steuererklärung dort hinsendet, kann kaum Mittel zur Verifikation sein, da bis letztes Jahr noch kein Zertifikat notwendig war, um eine Erklärung abzuschicken. Und selbst wenn, wäre es doch unbändig aufwändig, potentiell 80 Mio. Zugangsdaten dort für jeden erdenklichen Bürger zu hinterlegen. Ich rede da jetzt bewusst nicht von der Datenabfrage, weil die sehr wohl über eine Benutzerkennung verifiziert wird (Private/Public Key Encryption). Aber zurück zu unserem Beispiel: Eine Software soll aus dem ERP Daten auslesen und ohne Benutzeranmeldung funktionieren. Wie wird sowas gelöst?
Indem man die Daten öffentlich macht. Dann braucht es auch keine Credentials und es gibt auch nichts zu hacken.
Die Software kontaktiert den Server und kriegt so erst zur Laufzeit für kurze Zeit einen gültigen Zugang.
Aber auch dafür, also den Authentifizierungstoken, braucht es erstmal die login Daten. Und um die geht es ja hier. Wo die stehen, ob in einer .exe, auf einem USB stick oder im Kopf des Anwenders, ist ja erstmal unerheblich. Bzw genau darum geht es ja hier...
Martin S. schrieb: > Der Nutzer selbst, > der die Steuererklärung dort hinsendet, kann kaum Mittel zur > Verifikation sein, da bis letztes Jahr noch kein Zertifikat notwendig > war, um eine Erklärung abzuschicken. Auf welche Daten hatte man denn ohne Zertifikat Zugriff?
Wenn du es ordentlich und sicher haben willst. Hardwaretoken/Chipcard. Mit diesen holt man sich einen temporären Token mit dem man auf den Server zugreifen kann, der aber nach einigen Minuten/Stunden/Tagen abläuft.
meckerziege schrieb: > Wenn du es ordentlich und sicher haben willst. Hardwaretoken/Chipcard. > Mit diesen holt man sich einen temporären Token mit dem man auf den > Server zugreifen kann, der aber nach einigen Minuten/Stunden/Tagen > abläuft. Das ist aber nur ordentlich und sicher, wenn niemand den Token vorhersagen oder abfangen kann. Wenn jemand die Zugangsadaten aus der Software ablesen kann, kann er vielleicht auch die Software verändern.
Mombert H. schrieb: > Auf welche Daten hatte man denn ohne Zertifikat Zugriff? Keine. Aber wenn sich jede Anwendung einfach als Elster ausgeben kann, wäre das Ziel nach spätestens einen Monat einer breiten DDoS Attacke ausgesetzt. Was wäre besser, als ein Server, auf den man ohne Verifikation wild Steuererklärungen hochladen kann? Stell Dir mal vor, man würde die Finanzbehörde mit hunderten Millionen falscher Steuererklärungen bombardieren, wobei dort noch genug legitime Ziele vorhanden sind. Idealerweise macht man das kurz vor dem Stichtag, denn dann fällt der Traffic erstmal gar nicht auf. Es muss also irgendeine Form der Verifikation geben, die dem Server sagt: Ja, die Anfrage ist valide. Und die kann nur im Client stecken.
Mombert H. schrieb: > Wenn jemand die Zugangsadaten aus der > Software ablesen kann, kann er vielleicht auch die Software verändern. Ja klar. Und wenn er dann auch noch den privaten Schlüssel aus der Anwendung extrahieren kann, dann hat er freies Spiel, legitime Zugriffe zu generieren. Ist ja nicht so, als wäre das nicht schon oft genug vorgekommen. In einer Hardware, in der der private Schlüssel in einer Security Enclave hinterlegt ist, kommt man nicht ran, außer man hackt sie (siehe Intel) aber das ist dann doch eher die Ausnahme. Bei Software sieht die Sache dann nochmal anders aus, weil im Prinzip alle Daten erstmal vorliegen. Man muss dann nurnoch finden, was man sucht, hat aber keine Restriktionen, wie bei einer Enclave.
Martin S. schrieb: > Aber zurück zu unserem Beispiel: Eine Software soll aus dem ERP Daten > auslesen und ohne Benutzeranmeldung funktionieren. Wie wird sowas > gelöst? Kenn mich nicht GUT aus, aber wenn ich es richtig verstanden habe, wäre ein Hashwert möglich (mit einer kryptographischen Hashfunktion): Das ist ja so, dass man aus dem Passwort einen Hashwert berechnen kann, aber die Umkehrung sehr schwierig ist. D.h. das Programm kann prüfen, ob das eingegebene Passwort "echt" ist, kennt das Passwort aber selber nicht. Kuckt man hier: https://de.wikipedia.org/wiki/Kryptographische_Hashfunktion Man korrigiere mich gerne. Bin eher interessierte Laie in dem Bereich als Vollprofi.
Aber jetzt mal ein ganz andres Problem: Wie willst du verhindern, dass derjenige, der sich mit dem Disassembler spielt, einfach dein Programm manipuliert? D.h. die Passwort-Prüffunktion so manipuliert, dass sie immer "alles gut" zurückliefert?
Martin S. schrieb: > Aber wenn sich jede Anwendung einfach als Elster ausgeben kann, > wäre das Ziel nach spätestens einen Monat einer breiten DDoS Attacke > ausgesetzt. Was wäre besser, als ein Server, auf den man ohne > Verifikation wild Steuererklärungen hochladen kann? Seit wann muss man für DDos Daten hochladen? Martin S. schrieb: > Stell Dir mal vor, man würde die Finanzbehörde mit hunderten Millionen > falscher Steuererklärungen bombardieren, wobei dort noch genug legitime > Ziele vorhanden sind. Idealerweise macht man das kurz vor dem Stichtag, > denn dann fällt der Traffic erstmal gar nicht auf. Hast du mal beim Finanzamt nachgefragt was die Sicherheitsmechanismen sind gegen die ganzen falschen Steuererklärungen, die in den letzen Jahrzehnten in deren Briefkästen gelandet sind?
Haschfunktion schrieb: > Wie willst du verhindern, dass derjenige, der sich mit dem Disassembler > spielt, einfach dein Programm manipuliert? > > D.h. die Passwort-Prüffunktion so manipuliert, dass sie immer "alles > gut" zurückliefert? Die Prüfung findet durch das ERP statt. Der Login läuft über eine API, der dann ein PW-Eingabedialog des ERP selbst öffnet. Allerdings lassen sich die Credentials auch direkt an die API übergeben. Das Scheunentor wäre also, diese Credentials in die Applikation zu compilieren, das ja eigentlich zu vermeiden gilt. Hashberechnungen bringen mich hier also nicht weiter.
Mombert H. schrieb: > Seit wann muss man für DDos Daten hochladen? DoS heißt nichts anderes, als dass man einen Server so lange mit Anfragen überfährt, dass die Anbindung so ausgelastet wird, dass er faktisch totgelegt wird. Ob das nun massenhafte HTTP-Requests sind (DDoS), oder ein gezieltes Lahmlegen durch das Hochladen von invaliden Daten (DoS), sei dahingestellt.
Martin S. schrieb: > Was wäre besser, als ein Server, auf den man ohne Verifikation wild > Steuererklärungen hochladen kann? Davon hätte man genau was? Martin S. schrieb: > Es muss also irgendeine Form der Verifikation geben, die dem Server > sagt: Ja, die Anfrage ist valide. Und die kann nur im Client stecken. Blödsinn. Da gibt's vielleicht ein paar Plausibilitätschecks. Es gibt schliesslich auch ein Webfrontend, das man mit jedem Browser benutzen kann. Zu Deinem Problem: Beim ersten Login die Zugangsdaten abfragen und verschlüsselt ablegen, z.B. damit: https://en.wikipedia.org/wiki/Data_Protection_API
Martin S. schrieb: > Mombert H. schrieb: >> Seit wann muss man für DDos Daten hochladen? > > DoS heißt nichts anderes, als dass man einen Server so lange mit > Anfragen überfährt, dass die Anbindung so ausgelastet wird, dass er > faktisch totgelegt wird. > > Ob das nun massenhafte HTTP-Requests sind (DDoS), oder ein gezieltes > Lahmlegen durch das Hochladen von invaliden Daten (DoS), sei > dahingestellt. Aber warum soll dann die Verifikation gegen DDoS helfen? Deine Aussage ist doch gewesen: Martin S. schrieb: > Aber wenn sich jede Anwendung einfach als Elster ausgeben kann, > wäre das Ziel nach spätestens einen Monat einer breiten DDoS Attacke > ausgesetzt. Was wäre besser, als ein Server, auf den man ohne > Verifikation wild Steuererklärungen hochladen kann? Für mich liest sich das als "ohne Verifikation ist man Ziel für DDoS"
:
Bearbeitet durch User
Sinnlos... Die Zugangsdaten die du "bereitstellst" sollten schon von der Serverseit aus keinen Zugriff auf was anderes haben als die Daten die für den Client nötig sind. Was soll ein Hacker mit den Daten anfangen können wenn nur das geliefert wird was nötig ist? Baue eben für jeden Client nur die Daten in einer eigenen Datenbank zusammen die er braucht und Gib jeder Datenbank einen eigenen "Host".(VM, whatever) Wenn die Infrastruktur zur Abfrage der Daten so gestaltet ist das nur berechtigte clienten die Informationen abrufen können die für sie wichtig sind ist das "Problem" keines mehr.
Haschfunktion schrieb: > Kenn mich nicht GUT aus, aber wenn ich es richtig verstanden habe, wäre > ein Hashwert möglich (mit einer kryptographischen Hashfunktion): > Das ist ja so, dass man aus dem Passwort einen Hashwert berechnen kann, > aber die Umkehrung sehr schwierig ist. Ich glaube, du sitzt grad einem Irrtum auf (und bist dabei in bester Gesellschaft). Wenn du das Passwort durch seinen Hash ersetzt und den für den login verwendest, dann ist der Hash das "shared secret" und kann genauso ausgelesen und weiterverwendet werden, wie im ursprünglichen Problemszenario. Sozusagen "grausliches Klartextpasswort" statt "Klartextpasswort". Es bleibt leider so: Wenn ein statisches Geheimnis im Executable drin ist, kann mans auch rausholen und verwenden - egal wieviel crypto man drum rumwickelt. Bleibt nur Hardware-Token (wie schon erwähnt) oder die Bindung an User-Credentials (wo dann z.B. der passwortmerkende Schädel das sichere "Storage" für das shared secret oder den key dazu ist). PS: Hash schreibt sich nicht wie Haschisch.
Martin S. schrieb: > Aber ganz generell: So ein String in einer Exe ist eine förmliche > Einladung, den Disassembler anzuwerfen. Die Credentials herauszufinden > ist für erfahrene Cracker eigentlich nur eine Fingerübung. > > Obfuskation hilft da auch nicht viel, wenngleich es den Aufwand erhöht. > Ändert aber am Kern nichts. EXE-Packer sind schon mal eine gute erste Hürde.
Martin S. schrieb: > wie man Zugangsdaten für Programme fest hinterlegen kann, ohne, dass man > damit eine Sicherheitslücke schafft. Gar nicht. Jeder, der das Programm hat, kann zugreifen. Jeder, der das Programm simuliert, kann zugreifen. Das liegt in der Natur der Sache, wenn keine Zusatzinformationen (eingegebenes Passwort) notwendig sind, reicht offenbar die vorliegende Information aus. Martin S. schrieb: > Mal als profanes Beispiel die ELSTER-Software. Sie hat eine direkte > Verbindung auf die Finanzamtserver Elster verwendet eine Credentials-Datei. Das Programm selbst also keinen Schlüssel Mit Credentials kommst du natürlich rein, du musst nur dasselbe machen wie das Programm. Dass die Credentials nicht im Klartext übertragen werden, sondern im challenge response Verfahren, damit mithören auf der Leitung nicht reicht, ist selbstverständlich. Wenn man jedoch Zugriff auf den Rechner hat, braucht man gar nicht mithören, man kann die Credentials direkt kopieren. Hash-Mich schrieb: > Bleibt nur Hardware-Token ( Auch den könnte man mit einer Software die nicht Elster ist auf dem Rechner auslesen wenn er steckt, um für challenge response Verfahren ein response zu bekommen. Es ist ja schon einfach genug, mit gefälschten Eingabedialogen ein Passwort abzufangen, das gar nicht auf dem Rechner gespeichert ist sondern Einzelbuchstabenweise eingegeben wird.
rbx schrieb: > Martin S. schrieb: >> Aber ganz generell: So ein String in einer Exe ist eine förmliche >> Einladung, den Disassembler anzuwerfen. Die Credentials herauszufinden >> ist für erfahrene Cracker eigentlich nur eine Fingerübung. >> >> Obfuskation hilft da auch nicht viel, wenngleich es den Aufwand erhöht. >> Ändert aber am Kern nichts. > > EXE-Packer sind schon mal eine gute erste Hürde. Um Virenscanner auf Trab zu halten? Das mag nicht jeder... merciless
> EXE-Packer sind schon mal eine gute erste Hürde.
Nicht wirklich. Jeder .EXE-Packer kann die ursprüngliche ungepackte
Version problemlos wiederherstellen. Und wenn man was eigenes bastelt,
sowas wie eine verschlüsselte .EXE, kriegt man das mit einem guten
Debugger und etwas Ahnung auch vergleichsweise schnell "geknackt".
Ohne den Aufwand eines Hardware-Tokens würde ich es mit einer
Softwarelizenz machen, ähnlich wie Computerspiele. Diese kann auf dem
Server geprüft werden bevor dieser Daten rausrückt und bei Problemen
kann man sie temporär sperren oder ggf. komplett widerrufen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.