[Info] The Walking Dead ... oder das lange Leben der /var/flash/calllog

[PeterPawn]

Ich weiß auch nicht genau, seit wann die im Titel erwähnte Datei von AVM wieder berücksichtigt wird ... aber entweder wir haben in 2014 alle vollkommen falsch getestet oder AVM hat genau dieser Datei dann doch wieder neues Leben eingehaucht.

Jedenfalls wird diese Datei in "normaler Firmware" tatsächlich nicht mehr berücksichtigt (alles immer unter dem Vorbehalt, daß ich mich nicht doch irgendwo "vertestet" habe) ... aber sowie es sich um eine "private"- oder "beta"-Version handelt, wird sie sehr wohl noch ausgeführt.

Das Ermitteln des "Typs" der Firmware erfolgt bei AVM ja anhand folgenden Codes (hier am Beispiel der "config.lua", die für die Entscheidungen im GUI zuständig wäre):

root@FB7490:~ $ grep -A 11 "function get_gu_type" /usr/lua/config.lua | luabeautify
local function get_gu_type()
    if config.RELEASE == 0 then
        return 'private'
    end

    if config.RELEASE == 1 then
        if config.BETA_RELEASE == 1 then
            return "beta"
        else
            return 'release'
        end

    end

    if config.RELEASE == 2 then
        return "labor"
    end

    return "release"
end

Nach meinen Tests wird die Datei jedenfalls sowohl bei "CONFIG_RELEASE=0" als auch bei "CONFIG_BETA_RELEASE=1" nach wie vor ausgeführt, wobei der Aufruf wohl in folgender Form erfolgt:

/bin/sh /var/flash/calllog <calling_number> <called_number> <first_ringing_client> <phonebook_name_of_caller>

Es kann gut sein, daß die Entscheidung für oder gegen den Aufruf dieser Datei eine einmalige Entscheidung beim Start des "telefon"-Daemons ist (dieser ist auch gleichzeitig der "parent process" für den Shell-Aufruf) und es nach der Änderung der CONFIG-Variablen bzw. nach dem Befüllen der "calllog"-Datei mit Inhalt einen Neustart (zumindest des Daemons) braucht - bei den Variablen versteht sich das von selbst (weil ja nur Kindsprozesse das geänderte Environment erben), aber beim Inhalt der "calllog" kann das überraschend sein.

Wobei ansonsten auch jede weitere Änderung am Inhalt der "calllog" direkt beim nächsten Anruf wirksam wird - nur muß (zumindest nach meinen bisherigen Ergebnissen) eben beim Start von "telefon" die Datei (bzw. der Stream im entsprechenden TFFS-Node 141) nicht leer sein.

Warum ist das nun überhaupt einen (neuen) Thread wert, wenn das Thema "calllog" doch eigentlich von AVM schon zur 06.20 hin beerdigt wurde?

Durch dieses Relikt aus längst vergangener Zeit ergibt sich tatsächlich wieder eine - zumindest theoretisch vorhandene - Sicherheitslücke, welche sowohl von einem Angreifer (unter zugegebenermaßen seltenen Umständen, aber es gab auch schon unwahrscheinlichere Angriffe) als auch dem Besitzer wieder den Zugriff auf eine Shell eröffnen kann ... und zwar ohne jegliche Modifikation der originalen AVM-Firmware.

Was braucht es dazu? Nun ... zunächst muß man die Box erst einmal davon überzeugen, daß jede weitere installierte Firmware entweder eine "beta"- oder eine "private"-Version ist.

Das kann man aber recht einfach über eine "featovl.cfg" realisieren - da AVM sich hier ja gegen eine Whitelist mit verwendbaren Settings und für einen regulären Ausdruck zur Selektion gültiger Einstellungen (in der "rc.conf") entschieden hat ... und die Zeilen mit "CONFIG_RELEASE=0" oder "CONFIG_BETA_RELEASE=1" passieren diesen "Filter" problemlos.

Welche Version man jetzt genau wählt, hängt vom eigenen Geschmack und ggf. noch davon ab, welche der "internen Funktionen" man ansonsten noch verwenden möchte, denn an dieser Entscheidung für "private", "beta", "labor" oder "release" hängen ja noch einige weitere Möglichkeiten der Firmware, wie man mit einem passenden "grep" über die ausgepackte Firmware leicht verifizieren kann,

So eine "featovl.cfg" kriegt man natürlich nur auf eher ungewöhnlichem Weg in eine Box ... aber die bekannten Wege dazu reichen vom Hinzufügen so einer Datei zu einem TFFS-Image (aus den erweiterten Support-Daten) und dessen Flashen in eine (oder "die" bei NAND-TFFS) TFFS-Partition bis zur Verwendung eines gesonderten Images zum Starten der Box (das funktioniert nebenbei bemerkt auch bei NOR-Modellen, nur daß sich bei diesen die AVM-Firmware eben nicht selbst in den Flash schreibt), welches nur den Payload dieses Streams im TFFS entsprechend setzt.

Im zweiten Schritt muß man dann noch für den passenden Inhalt der "calllog" sorgen ... oder man macht das gleich auf genau demselben Weg wie bei der "featovl.cfg" oben.

Damit muß man nicht ein einziges Byte an der originalen AVM-Firmware ändern (und das auch nicht bei jedem Update wiederholen) ... man hat rein durch das Verändern von Einstellungen der Box (im TFFS) wieder eine Möglichkeit zur Ausführung eigener Kommandos geschaffen (auch wenn diese nur dann erfolgt, wenn ein Anruf eingeht).

Das wirklich Fiese daran ist es dann, daß man diese Änderungen auf genau demselben Weg auch wieder (nahezu spurlos) verschwinden lassen kann ... sorgt man für passende TFFS-Updates (inkl. Konsolidierung), bringt nicht einmal ein (nachträglicher) Dump des TFFS noch irgendwelche Artefakte ans Licht.

Die "calllog" hat auch noch ein weiteres Problem ... sie ist nämlich in einer Sicherungsdatei der Einstellungen ebenfalls enthalten und zwar auch noch in hexadezimaler Form, bei welcher der normale FRITZ!Box-Besitzer gar nicht erkennen kann, was in dieser Datei steht - und sie wird tatsächlich auch importiert (zumindest bei "alle Einstellungen wiederherstellen", bei partiellem Import habe ich es nicht getestet).

Aber das ist ja alles kein Problem, denn so eine Export-Datei kann ja nicht einfach so von einem Fremden geändert werden. Oder geht das etwa doch?

Ja, das ist tatsächlich kein Problem, wie jeder FRITZ!Box-Besitzer weiß, der schon mal mit anderen Mitteln (z.B. dem FBEditor o.ä.) irgendwelche Einstellungen ändern wollte. Diese ganze Export-Datei ist nämlich nur über eine CRC32-Prüfsumme gesichert ... und die kann man (wenn man will) einfach ändern oder man kann auch einfach mit passender Änderung am Inhalt der "summierten Daten" dafür sorgen, daß die alte Prüfsumme weiterhin stimmt (das ist nämlich keinesfalls eine kryptographische Hash-Funktion, was sich hinter diesem CRC32-Polynom verbirgt).

Aber immerhin wird ja niemals ein Unbefugter Zugriff auf so eine gesicherte Konfigurationsdatei erhalten und damit auch nie in der Lage sein, dem Besitzer der Box da irgendwelchen Code in der "calllog" unterzujubeln - den würden ja nur die wenigsten FRITZ!Box-Besitzer überhaupt suchen und erkennen können.

Hmm ... stimmt das eigentlich wirklich? Ich weiß ja nicht, wie es bei anderen FRITZ!Box-Besitzern so aussieht ... aber ich kenne meinerseits genügend Exemplare dieser Spezies, die brav den Versand der gesicherten Einstellungen per Push-Mail konfiguriert haben und wo zwar die Übertragung auf dem SMTP-Weg inzwischen fast überall verschlüsselt erfolgt - aber der Inhalt der Datei an sich ist nicht weiter verschlüsselt (mit wenigen Ausnahmen bei den "credentials" bzw. bei den Daten, die AVM als schützenswert ansieht) und auch die gesamte Nachricht wird im Klartext gesendet und damit normalerweise auch beim Mail-Anbieter entsprechend im Klartext gespeichert.

Macht sich jetzt jemand an dem Dateianhang so einer "Gesicherte Einstellungen"-Mail zu schaffen und ändert den Inhalt so, daß da eine "calllog" enthalten ist, braucht dieser "Jemand" nur noch einen Weg finden, den Besitzer der Box davon zu überzeugen, doch einfach mal eine "spezielle Version" der Firmware einzusetzen ... denn die angesprochenen CONFIG-Variablen sind natürlich in den entsprechenden AVM-Versionen auch passend gesetzt und müssen nicht zwingend erst über eine "featovl.cfg" passend "verbogen" werden.

Da diese "Sonderversionen" von AVM, wo eben "CONFIG_BETA_RELEASE=1" oder auch "CONFIG_RELEASE=0" (z.B. bei den Inhouse-Versionen) passend gesetzt sind, durchaus von AVM selbst signiert wurden (und diese Signatur den Dateinamen gar nicht einschließt, den kann man also beliebig ändern, wenn einem das im "social engineering" angeraten erscheint), kann der solchermaßen Angegriffene das auch gar nicht wirklich erkennen ... er freut sich ggf. noch über den exzellenten Support und das Engagement, mit dem AVM sich seines Problems annimmt.

Aber was soll AVM dagegen machen? Nun auch das ist eigentlich recht simpel ... entweder man entschließt sich zum generellen Verschlüsseln der Push-Mail mit dem Dateianhang oder man sorgt zumindest dafür, daß die Manipulation an der Export-Datei nicht mehr so ohne weiteres möglich ist. Den passenden "Dateityp" hat man mit "CRYPTEDBINFILE" ja bereits in der Firmware ... nun muß man halt nur noch dafür sorgen, daß einfach alle hexadezimal gesicherten Daten (wo der normale Benutzer halt so seine Probleme hat, einen "unerwarteten Inhalt" zu erkennen) nicht länger als "BINFILE" gesichert werden, sondern als "CRYPTEDBINFILE". Wenn dabei dann gleich noch das ECB-Problem für diese "CRYTPEDBINFILE"-Sektionen angegangen wird, hat man zwei Fliegen mit einer Klappe geschlagen. Dann kann ein Angreider ohne Kenntnis des Export-Kennworts keine Änderungen mehr an den hexadezimalen Daten vornehmen ... alles das, was darüber hinausgeht (z.B. Angriffe auf das Export-Kennwort), liegt dann schon nicht mehr im Verantwortungsbereich von AVM.