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.
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
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.
Gast
#4606909
Boah, ist der Wikipedia-Artikel zu CRAM schlecht. Umgangssprache und voller spezifischer Implementationsbeispiele, ohne einen generellen Überblick zu geben.
Gast
#4606912
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.
Gast
#4606914
Hol dir ein Zertifikat von letsencrypt.com das sollte von allen gängigen Services akzeptiert werden.
Gast
#4606951
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.
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.
Lol, quasi eine Verschlüsselung die zwischen den Ohren stattfindet :-)
Gast
#4606999
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).
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
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.
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.
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.
Gast
#4607074
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.“
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.
Gast
#4607124
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?
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.
Gast
#4607517
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?
Gast
#4607820
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.
Gast
#4608017
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...
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...
Gast
#4608109
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.
Gast
#4608123
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.
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.
Angehängte Dateien:
-
Lichtabsaugung.jpg
(51 KB)
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 :-)
Und das schöne ist, bei dem Prinzip kann man sogar den Befehl schon in die Antwort wie Salz reinstreuen...
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 :-)
Gast
#4615435
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" ?
Gast
#4615557
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.
Nonce und Signatur. HMAC zum Beispiel und fertig ist die Laube.
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.