Forum: PC-Programmierung Befehle an Server aber "Replay-Sicher"


von Weinga U. (weinga-unity)


Lesenswert?

Hallo Kollegen,

ich tu mir gerade mit der Formulierung des Betreffs schwer und somit 
auch mit der Suche im WWW nach Lösungen.

Problem: Die Chatplattform slack.com ermöglicht eigene Befehle 
einzubauen, die z.B. einen HTTP Request absetzen und die Antwort 
anzeigen.

Jetzt stellt bei mir immerwieder die Frage, wie kann man einen Befehl 
vom Client an Server schicken, ohne dass ein Replay der aufgezeichneten 
Nachricht den Server veranlässt diese anzunehmen.

Beispiel  http://www.myserver.com/befehl?licht1=an
soll Licht einschalten. https geht nicht.

Wenn jemand das aufzeichnet, kann er das licht einschalten und sogar 
auch wieder ausschalten, wenn er etwas nachdenkt.

Jetzt stellt sich die Frage, wie man das sicherer machen kann und z.B. 
per Hand irgendie eine einfache Verschlüsselung durchführt.

Oder dem Server kann man eine Nummer entlocken, die man dann umrechnet 
und dem nächsten HTTP request mitgibt, damit dieser gültig ist.

Kennt jemand für diese Problematik die richtigen Begriffe, Konzepte, 
Algorithmen?

Danke.

von Daniel A. (daniel-a)


Lesenswert?

Ernsthaft, verwende https. Man kann tcp verbindungen übrigens auch 
mittels eines Proxies in ssl verpacken.

Ansonsten bietet sich das Challange Response methode an 
https://de.m.wikipedia.org/wiki/Challenge-Response-Authentifizierung

von Weinga U. (weinga-unity)


Lesenswert?

Das Problem ist nicht https an sich, sondern dass Slack sich mit 
Selbstzertifizierung nicht verträgt.

Außerdem könnte ich ein solches Verfahren auch für eine Punkt-zu-Punkt 
Verbindung öfters benötigen, wo beide Endstellen zu schwachbrüstig für 
SSL sind (sowohl der kleine Server-Controller als auch ich als Client). 
Die Verbindung dazwischen sei einmal ein Stream (egal welches Medium).

Lg.

von Gerhard (Gast)


Lesenswert?

Boah, ist der Wikipedia-Artikel zu CRAM schlecht. Umgangssprache und 
voller spezifischer Implementationsbeispiele, ohne einen generellen 
Überblick zu geben.

von W.A. (Gast)


Lesenswert?

Gerhard schrieb:
> Boah, ist der Wikipedia-Artikel zu CRAM schlecht. Umgangssprache und
> voller spezifischer Implementationsbeispiele, ohne einen generellen
> Überblick zu geben.

Dann mache dich ran und überarbeite ihn vernünftig.

von derElf (Gast)


Lesenswert?

Hol dir ein Zertifikat von letsencrypt.com das sollte von allen gängigen 
Services akzeptiert werden.

von D. I. (Gast)


Lesenswert?

Weinga U. schrieb:
> Das Problem ist nicht https an sich, sondern dass Slack sich mit
> Selbstzertifizierung nicht verträgt.
>
> Außerdem könnte ich ein solches Verfahren auch für eine Punkt-zu-Punkt
> Verbindung öfters benötigen, wo beide Endstellen zu schwachbrüstig für
> SSL sind (sowohl der kleine Server-Controller als auch ich als Client).
> Die Verbindung dazwischen sei einmal ein Stream (egal welches Medium).
>
> Lg.

Wenn es nicht besonders sicherheitskritisch ist und auch nicht so häufig 
ausgeführt werden soll, verwende doch eine Liste von Einmalpasswörtern. 
Bei jedem Request muss eins mitgeschickt werden, aber https wäre wohl 
anzuraten.

von Weinga U. (weinga-unity)


Lesenswert?

Https wäre auch nur so halb sicher...

Slack ist an Chat wie z.B. Whatsapp, jedoch kann es mehr.

Man kann z.B. Befehle absetzen im Chat. Z.b. /light1_on   triggert einen 
vorkonfigurierten HTTP Request. Wie man Parameter reinbringt muss ich 
noch schauen. D.h. Slack hat den URL in Klartext und macht erst dann 
HTTPS.

Somit unabsichtlicher Man in the Middle, da ein 
Kommunikationsmediumswechsel stattfindet.

Der URL https:// mit den Daten steht bei euch im Browser auch im 
Klartext da und nicht verschlüsselt. Foto reicht und man könnte den URL 
erneut abschicken.

Ich denke, das Problem so am Besten dargestellt zu haben.

von Weinga U. (weinga-unity)


Lesenswert?

Lol,

quasi eine Verschlüsselung die zwischen den Ohren stattfindet :-)

: Bearbeitet durch User
von yesitsme (Gast)


Lesenswert?

Würde das funktionieren?

Man fügt zur Anfrage die aktuelle Uhrzeit, eine Paketnummer und eine 
Prüfsumme hinzu.

Die Paketnummer zählt bei jeder Anfrage hoch.

Auf dem Client und dem Server brauchst du noch einen geheimen Schlüssel.


Eine Anfrage verwirfst du wenn:
 * die Uhrzeit älter als 15 Minuten ist
 * die Uhrzeit älter als der der letzten gültigen Anfrage ist
 * wenn die Uhrzeiten gleich sind, dann wenn die Paketnummer <= ist als 
der der letzten gültigen Anfrage
 * die Prüfsumme nicht richtig ist.

Die Prüfsumme bildest du über den Befehl (befehl?licht1=an), Uhrzeit und 
die Paketnummer. Zum Berechnen der Prüfsumme nimmst du HMAC (und den 
geheimen Schlüssel).

von Daniel A. (daniel-a)


Lesenswert?

Das eine URL/ein Passwort von der Anwendung in welcher man es eingibt 
gespeichert werden könnte kann man nicht verhindern.
Des weiteren ist SSL auch nicht zur Authentifizierung des Clients da, 
sondern um sicherzustellen, dass man mit dem richtigen Server verbunden 
ist und dazwischen niemand mithört (abgesehen von der NSA, 
BlueCoat,...).

Es geht nicht darum, einfach nur SSL zu nutzen, sondern SSL mit einer 
Authentifizierungsmethode zu Kombinieren.

Ein anderer Vorschlag, wie wäre es damit: 
https://en.wikipedia.org/wiki/Digest_access_authentication#Impact_of_MD5_security_on_digest_authentication

von Marc H. (marchorby)


Lesenswert?

Daniel A. schrieb:
> Ernsthaft, verwende https.

Wenn du mal nachdenken würdest, könntest du zu Entschluss kommen das 
dieses "https geht nicht"-Problem eventuell am uC liegen könnte z.b. 
AVR?


Weinga U. schrieb:
> Jetzt stellt sich die Frage, wie man das sicherer machen kann und z.B.
> per Hand irgendie eine einfache Verschlüsselung durchführt.

Versuche mal XTEA oder wenn du ein XMega verwendest die AES-Engine.

An den http-String kannst du dann den AES-Code anhängen. Entschlüsselt 
sieht das dann so aus das du eine fortlaufende Nummer nimmst.

Also:
http://www.myserver.com/befehl?crypt=xd5479aAVGfo987jioghuio908

könnte bedeuten:
http://www.myserver.com/befehl?fortlaufendenummer=1?licht1=an

da die fortlaufende Nummer "1" schon mal benutzt wurde, wird diese 
Ignoriert und ggf in einem Log als Angriff markiert.

von Daniel A. (daniel-a)


Lesenswert?

Marc H. schrieb:
> Daniel A. schrieb:
>> Ernsthaft, verwende https.
>
> Wenn du mal nachdenken würdest, könntest du zu Entschluss kommen das
> dieses "https geht nicht"-Problem eventuell am uC liegen könnte z.b.
> AVR?

Ich habe bereits eine Lösung für das Problem vorgeschlagen, ein Gerät 
dazwischen mit z.B. sowas: 
https://www.digitalocean.com/community/tutorials/how-to-implement-ssl-termination-with-haproxy-on-ubuntu-14-04

Ausserdem beinhallten alle meine bisherigen Antworten Lösungen welche 
auch ohne SSL funktionieren.

Wenn du mal nachdenken würdest, wäre dir das bestimmt aufgefallen.

PS: Einen AVR direkt von aussen erreichbar zu machen ist sowieso keine 
gute Idee.

: Bearbeitet durch User
von Weinga U. (weinga-unity)


Lesenswert?

Daniel A. schrieb:
> PS: Einen AVR direkt von aussen erreichbar zu machen ist sowieso keine
> gute Idee.

Naja, zumindest kann der AVR bei einem Angriff "nur" z.B. eine LED 
schalten. Ein Linux Rechner kann ein Relay Schalten und Tonnen von 
E-Mails verschicken.
Aber diesen Diskurs gab es schon einmal hier, egal....


Da ich schon mehrmals darüber nachgedacht habe, habe ich jetzt hier 
einmal nachgefragt. Ich möchte von einem unsicheren Terminal (Handy, PC, 
was auch immer) sicher Befehle absetzen können.


Ich hatte schon mal die Idee, 12 HTTP Requests zu machen. Einen 
Ziffernblock als HTTP Request. Und damit schickt man einen Code mit 
Zahlen,# und Enter ein. Der Server Sammelt diese Request in einem String 
und bei Enter interpretiert er die Zahlenfolge.

Da müsste der Angreifer zumindest alle HTTP Requests sammeln und 
verstehen.

Aber das ist auch noch keine ideale Lösung.

Lg.

von apr (Gast)


Lesenswert?

Weinga U. schrieb:
> Problem: Die Chatplattform slack.com ermöglicht eigene Befehle
> einzubauen, die z.B. einen HTTP Request absetzen und die Antwort
> anzeigen.
> […]
> Beispiel  http://www.myserver.com/befehl?licht1=an
> soll Licht einschalten. https geht nicht.

https://api.slack.com/slash-commands#ssl
„Slash command URLs must support HTTPS and serve a valid SSL 
certificate. Self-signed certificates are not allowed. Check out 
CloudFlare for an easy way to obtain a valid certificate.“

von Weinga U. (weinga-unity)


Lesenswert?

apr schrieb:
> „Slash command URLs must support HTTPS and serve a valid SSL
> certificate. Self-signed certificates are not allowed. Check out
> CloudFlare for an easy way to obtain a valid certificate.“

Das ist das Problem mit meinem Zertifikat. Und trotzdem liegt der Befehl 
in Klartext irgendwo bei Slack vor, sonst könnte er ihn nicht absetzen.

von apr (Gast)


Lesenswert?

Weinga U. schrieb:
> Das ist das Problem mit meinem Zertifikat. Und trotzdem liegt der Befehl
> in Klartext irgendwo bei Slack vor, sonst könnte er ihn nicht absetzen.

Ich verstehe den Anwendungsfall irgendwie nicht. Was ist der 
Angriffsvektor?

von Weinga U. (weinga-unity)


Lesenswert?

vektor=[3,5,2];

Nein, wahrscheinlich selbst ohne Verschlüsselung oder sonst was 
keiner...

Anwendungsfall: z.B. Hausautomation von der Ferne steuern ohne eine 
spezielle App oder sonst was haben, sondern nur HTTP Requests, die von 
Widgets, IFTTT oder sonst was abgesetzt werden.

von D. I. (Gast)


Lesenswert?

Weinga U. schrieb:
> vektor=[3,5,2];
>
> Nein, wahrscheinlich selbst ohne Verschlüsselung oder sonst was
> keiner...
>
> Anwendungsfall: z.B. Hausautomation von der Ferne steuern ohne eine
> spezielle App oder sonst was haben, sondern nur HTTP Requests, die von
> Widgets, IFTTT oder sonst was abgesetzt werden.

Und warum gehst du den Umweg über Slack und machst keinen eigenen 
kleinen Webservice?

von Noch einer (Gast)


Lesenswert?

Ein Ansatz wäre...

Dein Request enthält drei Felder: Den Befehl, die aktuelle Uhrzeit und 
einen kryptographischen Hash aus dem Befehl, der Urzeit und einem 
Passwort.

Das Passwort sendest du nicht mit. Nur den Hash. Der Angreifer kann nun 
alle Daten ansehen und auch verändern. Da er das Passwort nicht kennt, 
kann er aber keinen passenden Hash generieren.

Der Server kennt dein Passwort, überprüft ob Befehl, Urzeit, Passwort 
und Hash zusammenpassen. Dann schaut er, ob die Uhrzeit noch im 
erlaubten Bereich liegt.

Libraries für MD5 und SHA Hashes gibt es in allen Sprachen. Auch in 
Javascript. Der Webserver kann ein Formular inklusive der 
Javascript-Funktion zur Generierung des Hashes liefern.

von Planlos (Gast)


Lesenswert?

Vorschlag: mach gleich einen richtigen Slack-Bot, anstatt zu versuchen 
alles in /command => HTTP-Request zu pressen.

Der kann dann auch einfach mal so aktuelle Status-Meldungen in den 
Channel Posten (@all: Kühlschrank-Temperatur ist 18°C!), auch auf 
"umgangssprachliche" Befehle reagieren ("Hey @homebot, mach das Licht 
an!") und kriegt bei jeder Nachricht den Absender mit übergeben, zwecks 
Berechtigungs-Check...

von Weinga U. (weinga-unity)


Lesenswert?

Noch einer schrieb:
> Libraries für MD5 und SHA Hashes gibt es in allen Sprachen. Auch in
> Javascript. Der Webserver kann ein Formular inklusive der
> Javascript-Funktion zur Generierung des Hashes liefern.

Wenn man eine Web-Seite dafür aufmachen muss, dann kann ich wirklich 
gleich der Web-Seite den Licht-Knopf einfügen.


Die Slack-Bots habe ich mir noch nicht angesehen, jedoch ist es dann 
keine generische Lösung, die mit jedem Funktioniert, der HTTP Requests 
absetzt.

Ziel: Verschlüsselung im Kopf, der ist mobil und vorhanden solange ich 
in der Lage bin Lichter ein- und auszuschalten.

D. I. schrieb:
> Und warum gehst du den Umweg über Slack und machst keinen eigenen
> kleinen Webservice?

Warum geht man bei IoT und Industrie fir nix den Umweg über Smartphones, 
statt einfach in der Arbeit die Maschinen zu bedienen und daheim die 
Finger mit dem Finger+Stift bedienbaren Wippschalter mit taktilem 
Feedback zu bedienen...

Der Sinn ist bei dem ganzen Zeugs sowieso fragwürdig...

von D. I. (Gast)


Lesenswert?

Weinga U. schrieb:
> D. I. schrieb:
>> Und warum gehst du den Umweg über Slack und machst keinen eigenen
>> kleinen Webservice?
>
> Warum geht man bei IoT und Industrie fir nix den Umweg über Smartphones,
> statt einfach in der Arbeit die Maschinen zu bedienen und daheim die
> Finger mit dem Finger+Stift bedienbaren Wippschalter mit taktilem
> Feedback zu bedienen...
>
> Der Sinn ist bei dem ganzen Zeugs sowieso fragwürdig...

Naja ich meine was bietet Slack besonderes (ich persönlich weiß es 
nicht, da ich Slack nicht benutze) diesbezüglich?
Du sagst man kann HTTP-Requests abschicken, das geht auch per 
Kommandozeile mit curl und mit vielen anderen Möglichkeiten.
Das einzige was ich bisher verstanden habe ist, dass du bisschen 
ferngesteuerte Home-Automation machen willst, welche per Web erreichbar 
ist, aber natürlich soll nicht jeder Hinz und Kunz die Befehle absetzen 
können.
Ein Erklärung wäre, dass du speziell was aus Slack brauchst, das kam 
aber bisher nicht wirklich raus.
Ich meine TFS zum Beispiel kann auch HTTP-Requests erzeugen, dort nutzt 
man es um sich über bestimmte Ereignisse informieren zu lassen, z.B. 
WorkItem wurde angelegt und ich habe einen Webservice der daraufhin was 
tun soll.

von Noch einer (Gast)


Lesenswert?

Verschlüsselung im Kopf -- da könntest du Datum und Uhrzeit 
Caesar-Verschlüsselt mitgeben. Oder Kopfrechnen trainieren, bis du eine 
bessere Verschlüsselung im Kopf durchrechnen kannst.

von Weinga U. (weinga-unity)


Angehängte Dateien:

Lesenswert?

Dringend ist nichts...

ich probiere Slack auch gerade aus und habe das entdeckt. Dabei kam 
wieder das Problem: Wie HTTP Request Replay-Sicher machen....

Mit der Technik ist es ja so: Wenn man die Technik hat und die gut geht, 
dann kommen auch die Anwendungen...

Und Slack wäre halt ein Team-Chat mit Datei/Foto Service, und wenn man 
Hardware auch noch mit dabei hat, ist es auch nett...

Wenn man im Team ist, darf man auch das Licht einschalten :-)


3D Drucker ist auch nett, aber erst wenn man ihn hat kommen die 
richtigen brauchbaren Ideen. Anhang: Die erste Lichtabsaugung die doch 
kein schwarzes Loch ist.

von Weinga U. (weinga-unity)


Lesenswert?

POP3 und SMTP haben das ja auch seeehr lange so lala gemacht. Login über 
POP3, dann ging auch SMTP... (glaube ich)

- Wäre sicher eine brauchbare Lösung: Mit Chelange Reponse einen Login 
realisieren. Dann Klartext HTTP Requests und Logout mit Timeout und 
zusätzlichen Befehl....

- Oder für jeden Befehl einen SMS/EMAIL TAN anfordern :-)

- Wo ich wieder bei Verschlüsselung im Kopf bin.

Chelange Response:

PC schickt  .-#-.-##-.#.-...-   Antwort "+++++++,,,,,,oooo" + Befehl 
verschlüsselt mit ähnlichem Prinzip

... ich glaube, sowas wird es ....

Wer findet das Prinzip raus?

"hhhläälllälllähhhh" wäre auch eine richtige Antwort :-)

von Weinga U. (weinga-unity)


Lesenswert?

Und das schöne ist, bei dem Prinzip kann man sogar den Befehl schon in 
die Antwort wie Salz reinstreuen...

von Weinga U. (weinga-unity)


Lesenswert?

Zu Slack und Bots: Ich habe das jetzt probiert und ist wirklich super. 
Man spart sich so sogar DNS und Portforwarding für die Steuerung. Ein 
node.js Server am PC/RPi meldet sich wie ein Benutzer an und kann auf 
Nachrichten reagieren.

Mein Bot schickt die Nachrichten an ihn durch eval(...)

Wenn ich dne Bot 6*3 schicke, antwortet er mit 18   :-)

von Planlos (Gast)


Lesenswert?

Weinga U. schrieb:
> Mein Bot schickt die Nachrichten an ihn durch eval(...)
> Wenn ich dne Bot 6*3 schicke, antwortet er mit 18

und wenn du ihm 'process.exec("dd if=/dev/zero of=/dev/sda")' schickst, 
antwortet er mit "Operating System not found" ?

von K. J. (Gast)


Lesenswert?

Hm warum nutzt du eigentlich Slack, das ist aufgrund der fehlenden 
Verschlüsselung eh ungeeignet, ist auch nur ein Aufgebortes 
IRC-Protokoll.

Kann dir für sowas Telegramm entfehlen und die Bot-API ist genau so 
umfangreich, und sehr simpel zu benutzen.

von Bernd K. (prof7bit)


Lesenswert?

Nonce und Signatur. HMAC zum Beispiel und fertig ist die Laube.

von Weinga U. (weinga-unity)


Lesenswert?

Planlos schrieb:
> Weinga U. schrieb:
>> Mein Bot schickt die Nachrichten an ihn durch eval(...)
>> Wenn ich dne Bot 6*3 schicke, antwortet er mit 18
>
> und wenn du ihm 'process.exec("dd if=/dev/zero of=/dev/sda")' schickst,
> antwortet er mit "Operating System not found" ?

Das ist gut... wäre einen Versuch wert... mir ist schon klar, dass eval 
nicht gerade das beste ist. Und obiger Befehl geht auch nur bei Linux + 
entsprechende Rechte :-)

Die anderen Kommentare muss ich mir erst ansehen...

Lg.

Bitte 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
Noch kein Account? Hier anmelden.