Fragen zum neuestem Update / Sicherheit

  • Fragen zum neuestem Update / Sicherheit

    Hi,

    nach dem neuesten Update kann ich die Bouquetsliste per Console nicht mehr laden.

    Quellcode

    1. root@dm7080:~# wget -q -O - "http://127.0.0.1/web/servicelistreload?mode=2"
    2. wget: server returned error: HTTP/1.1 412 Precondition Failed
    Abhilfe schafft,

    Token-basierte Sicherheit -> an: auf aus
    Einfache Anti-Hijack Maßnahme -> an: auf aus

    Wie macht es denn dreamboxEdit oder der bouqueteditor im webif? Ich schalte die Optionen ungern ab, möchte jedoch trotzdem zu mein Ziel kommen :)
    Ich bin Guybrush Threepwood, ein mächtiger Pirat!
  • Korrektur: So einfach geht das nicht wenn token-basierte security an ist.
    Der Sinn dieser Funktion ist ja gerade, dass man mit einem request alleine nicht mehr ans Ziel kommen kann sondern vorab erst einmal eine session-id holen und diese für den weiteren Verlauf immer mitschicken muss (bis einem die box ggf mitteilt dass man ne neue brauch).

    Eine Möglichkeit wäre die token abzuschalten und dann einen POST Request abzusetzen

    Nachtrag:
    Ihr müsst euch halt immer im klaren sein was ihr da tut. Im Prinzip ist ein von außen erreichbares WebIf mit aktivem https und Authentifizierung gegen unerwünschten Zugriff durch 3. ausreichend geschützt.
    Vorausgesetzt euer Passwort ist nicht trivial.
    Die Änderungen die wir jetzt da gemacht haben sind leider nötig weil viele User sehr unbedacht einfach eine offenen Dreambox ins Internet hängen (hoffensichtlich denken einige "die findet eh keiner").
    Durch die Anpassungen müssen sie aktiv mehrere Optionen Ändern damit dieses vorgehen "unmittelbar fatal" ist.
    Anti-Hijack forciert lediglich POST-Requests was gegen simple fake-image basierte CSRF-Attacken hilft.

    Das in Kombination ist eigentlich für den "Normalen Hausgebrauch" schon ziemlich ausreichend.
    mfg ,
    Reichi
  • Das muss der Entwickler der App einbauen. Als Alternative bleibt dir nur die beiden Security-Maßnahmen wieder auszuschalten.
    Solange die Box nur aus vertrauenswürdigen Netzwerken erreichbar ist, kann man das schon so machen. Dann kann man auch auf HTTPS und Authentifizierung verzichten (Auth mit HTTP bietet wiederrum auch absolut 0 Sicherheit). Den Port der Box ins Internet freizugeben ist NICHT vertrauenswürdig!!
    Wie der Author des Exploits/Sicherheitsberichts empfiehlt sollte zumindest VPN genutzt werden: seclists.org/fulldisclosure/2017/Jan/18

    Aber nochmal: Das sind zwei Einstellungen, die seit Jahren für das Original-Webinterface verfügbar sind. Sie wurden offenbar nur von allen Entwicklern (außer @dhwz für DreamboxEdit :thumbsup: ) von Apps und Tools rund um e2 ignoriert, weil das vermutlich einfacher war :cursing:
    Soweit ich weiß bietet das im OpenWebIF solche Funktionen nicht einmal an.
    DMM hat in Reaktion auf die Veröffentlichung eines Exploits für das WebAdmin-Plugin nun die Standard-Einstellungen geändert. Das finde ich sehr gut, weil es ja offensichtlich das Bewusstsein schärft, dass hier ein Problem existiert. Die Einstellungen jetzt wieder auszuschalten mag individuell eine Lösung sein, aber sicher nicht für die Allgemeinheit.

    Und die Warnung des Authors, dass enigma2-Boxen Teil des nächsten Botnetzes sein können, halte ich für untertrieben. Viele sind es nämlich sicher schon heute :thumbdown: Zumindest findet man über die einschlägigen Suchmaschinen jede Menge ungeschützte e2-Boxen im Netz.
    so long
    m0rphU

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von m0rphU () aus folgendem Grund: besser?

  • Wir haben auch den WebAdmin nochmal überprüft, aufgeräumt und etwas verbessert (es gibt nun eine recht coole rein Browser-basierte shell auf Basis von shellinabox).

    Zum Anderen sind ja die Default-Einstellungen im WebIf nun so, dass man aus dem LAN ohne Benutzer/Passwort zugreifen kann, von außen jedoch eine Anmeldung benötigt.
    Die weiteren Sicherheitsoptionen schützen gegen CSRF Attacken
    1. Es ist IMMER die Same-Origin-Policy aktiviert
    2. Anti-Hijack schützt zusätzlich gegen <img>-tag basierte CSRF Attacken.
    3. Token-Basierte Sicherheit sorgt dafür dass man nen richtigen Client schreiben muss damit's überhaupt geht und in Verbindung mit 1 und 2 sorgt es dafür dass man sich für echte Attacken schon ordentlich anstrengen muss
    Bei aktivierter HTTP-Authentifizierung mit nem ordentlichen Passwort hat man nach unserem aktuellen Kenntnissstand so gut wie keine Chance überhaupt so weit zu kommen es zu versuchen :)
    Damit keiner eine Box mit leerem Passwort im Netz hängt ist das ab sofort im WebInterface nicht mehr erlaubt

    Gegen grobe Mißkonfiguration ist im Prinzip kein Kraut gewachsen aber man kann zumindest sinnvolle Standards vorgeben und den User so zwingen aktiv "nachlässig" zu sein.
    mfg ,
    Reichi
  • m0rphU schrieb:


    Wie der Author des Exploits/Sicherheitsberichts empfiehlt sollte zumindest VPN genutzt werden: seclists.org/fulldisclosure/2017/Jan/18
    Mal noch ein Wort zu diesem Bericht. Wahrscheinlich war es der erste „Exploit“ des Autors und es war sicher aufregend für ihn, ihn zu entdecken. Nun sucht er nach etwas Anerkennung. Dabei hat er einiges übersehen.

    1.) Normalerweise kontaktiert man heutzutage den Hersteller, bevor man an fulldisclosure schreibt. Ja, wir sind nicht die Autoren des Plugins, aber die Dreambox wird in dem Bericht mehrmals erwähnt, d.h. wir haben die Konsequenzen zu tragen.

    2.) Er vergisst zu erwähnen, dass das webadmin-Plugin manuell installiert werden muss.

    3.) Er hat einen Programmierfehler im webadmin entdeckt, der es erlaubte, Shell-Befehle auszuführen, sofern kein Passwort verlangt wurde. Das absurde daran ist, dass das webadmin-Plugin dazu da ist, Shell-Scripts hochzuladen und auszuführen, .deb-Pakete hochzuladen und zu installieren und die Pakete zu verwalten. Objektiv betrachtet ist das Konzept des webadmin-Plugins schon eine Sicherheitslücke an sich.

    Nun haben wir etwas Aufwand betrieben, damit man uns nicht nachsagen kann, nichts getan zu haben. Ich denke auch, dass es sinnvolle Änderungen waren, und unter anderem dürfte der Programmierfehler beseitigt worden sein, der zu dem Bericht führte. Leider schränkt es einige Funktionen in den neuen Standard-Einstellungen ein, aber auf lange Sicht dürfte das von Vorteil sein. Es werden vermutlich noch einige Änderungen folgen, aber keine tiefgreifenden.

    P.S.: Es stellt sich im Übrigen generell die Frage, wieviele der im Internet öffentlich zugänglichen Dreamboxen keine Honeypots sind. Es dürfte den meisten Besitzern doch ziemlich schnell übel aufstoßen, wenn Fremde oder Suchmaschinen-Bots sich durch das Menü hangeln und Sender wechseln, Timer ändern oder die Box ausschalten.
  • Mein UserScripts Plugin WebIf war schon ewig ein Problem wenn man den webif Port weitergeleitet hat, weil wie wobi richtig sagt es ist dafür da sachen scripts auf der box auszuführen, da kann man zwar herumproggen um nicht jedes script sondern nur die installierten zu erlauben, aber 100%ig kann das nie sein.

    Insofern macht Euch keinen Stress. Wobei die meisten hacks um einen box zu machen derzeit nur auf /mp scripte ablegen die dann Dinge nachladen bis /tmp oder der Flash voll ist, was aber schon unangenehm genug sein kann.
    Einmal Rupert und Zurück
  • Auch wenn der Thread schon ein paar Tage alt ist, will ich hierzu noch was beitragen. Der m0rphU hat mich freundlicherweise auf die Änderung am Webinterface und diese Diskussion hier hingewiesen.

    Zunächst mal will ich zwei Dinge sehr positiv hervorheben, die hier noch gar nicht genannt sind: Zum einen ist auch die HTTP Authentifizierung jetzt standardmäßig eingeschaltet, und zum anderen ist die Anmeldung mit leerem Kennwort nicht mehr möglich. Das beides finde ich sehr gut!

    Zu den beiden anderen Optionen habe ich ehrlich nicht verstanden, was die bringen sollen. Wenn eine Box ohne Passwortschutz übers Internet erreichbar ist, dann wird es einen potentiellen Angreifer kaum ausbremsen, dass er seine Requests als POST schicken und sich per /web/session von der Box erstmal eine Session-ID für seinen Angriff geben muss. Wie das geht, kann er wunderbar nachlesen.

    Okay, die beiden Optionen sollen vor CSRF-Attacken schützen. Aha. CSRF bedeutet, dass jemand eine bestehende Anmeldung an der Box von einer fremden Seite aus kapert.

    Das Szenario muss ich mir so vorstellen: Ich hab meine Box mit einem sicheren Kennwort geschützt, das der Angreifer nicht rauskriegt, deshalb versucht er CSRF.

    Ich bin also mit meinem Browser am Webinterface der Box angemeldet, was ich ja durchaus einmal im Monat mache, oder einmal alle zwei Monate. Und anschließend wechsle ich ohne den Browser zu beenden ganz zufällig auf eine vom Angreifer kompromittierte Webseite. Und der Angreifer muss genau die IP Adresse meiner Box kennen und in seine Seite eingebaut haben, zum Beispiel in ein manipuliertes <img> oder in ein JavaScript. Na das ist ja mal naheliegend.

    Aber ich bin schlau gewesen und habe die beiden Sicherheitsoptionen aktiviert. Und die bewirken, dass das mit dem <img> schon mal gar nicht geht, und das JavaScript ne Ecke komplizierter ausfallen muss. Den der Angreifer müsste erst /web/session absetzen und dann die Session-ID aus dem XML holen und so viel Aufwand schreckt den Angreifer bestimmt ab...

    So richtig glauben kann ich das nicht. Was ich weiß ist, dass der Zusatz „may break clients“ getrost geändert werden kann in „will definitely break many clients“.

    Es ist halt ein heiden Aufwand, das nachzuziehen, aber einen praktischen Mehrwert oder Nutzen bringt es nicht. Aber Scherereien bringt es ganz sicher. Daher meine eindringliche Bitte, über die Defaulteinstellung dieser beiden Optionen bitte doch noch mal nachzudenken!

    Aber nochmal: Man kann den Leuten gar nicht genug in den Hintern treten, dass sie Authentifizierung einschalten und ordentliche Kennwörter verwenden müssen. Den Teil finde ich gut!
  • Lieber dhwz, ich hab wirklich einen heiden Respekt und bewundere Deine unermüdliche Arbeit am dreamboxEDIT, ohne das man die meisten Enigma2 Boxen nicht sinnvoll nutzen könnte. Und es fällt mir schwer, Dir zu widersprechen!

    Aber bei iOS verhält es sich halt etwas anders. Wenn ich mit dem aktuellen xCode Toolset eine neue Version bauen und im Appstore freigeben will, dann muss ich die für iOS 10 anpassen. Und allein DAS ist schon mal ein heiden Aufwand. Gleichzeitig bin ich gezwungen, den Support für ältere iOS Versionen aufzugeben, also werden alle User, die noch iOS 7 oder 8 haben, diese Erweiterung sowieso nie bekommen können.

    Außerdem funktioniert die App momentan halt auch unheimlich stabil. Und das hinzukriegen war nicht einfach. Jetzt die Kommunikation aufzubohren birgt auch immer das Risiko, das nachher wieder irgendwo anders was nicht geht wie zuvor. Denke nur daran, dass alte Webinterface Versionen gar keine POST Requests vertragen. Wer weiß schon wo die noch überall rumfliegen und was sonst noch so lauert.

    Das Problem ist, ich seh überhaupt keinen Nutzen in der Aktion.
  • Ich kann dich da beruhigen, auch die alten Webinterfaces funktionieren alle einwandfrei mit einem POST, dreamboxEDIT setzt gar keine anderen Befehle mehr ab für Enigma2 Boxen und ich hab noch nie Beschwerden gehört dass es würde nicht funktionieren würde :)

    Aber ja das mit iOS ist ärgerlich und kann ich verstehn, aber das ist ja nicht DMMs Schuld ;)

    Über Sinn und Zweck kann man sich streiten, aber ich bezweifle dass sich die Defaults nochmal ändern.