Das Problem mit eigenen Ersetzungen für hostapd/wpa_supplicant ist es, daß AVM da in den Quellen "herumgespielt" hat und es die Quellen für diese Änderungen natürlich nicht im OSS-Paket gibt, denn das entsprechende Paket von
http://w1.fi steht unter BSD-Lizenz und die verpflichtet nicht zur Herausgabe von geänderten Quellen. In der Folge kann man die AVM-Komponenten "/sbin/hostapd" und "/sbin/wpa_supplicant" nicht ohne weiteres gegen eigene, neuere Versionen austauschen.
Jedenfalls verwendet AVM offenbar als Basis auch diese Software, denn in der "license.txt" steht ausdrücklich auch:
Code:
Dieses Produkt enthält Software entwickelt vom hostapd Project
© 2002-2007, Jouni Malinen <[email protected]> and contributors
All Rights Reserved.
Was mich daran aber am meisten irritiert, ist die Feststellung, daß AVM beim 310B in der Version 143.06.92 noch genauso Binaries einsetzt, die ihrerseits die Versionskennzeichnung "2.0-devel" enthalten:
Code:
# strings sbin/{hostapd,wpa_supplicant} | grep "2\..\(-devel\)"
hostapd v2.0-devel
2.0-devel
2.0-devel
wpa_supplicant v2.0-devel
, wie das schon seit Jahren der Fall ist.
Angesichts des doch erheblichen Alters dieser Version und der vom (originalen) Autoren nur für 2.5- und 2.6-basierte Versionen veröffentlichten Patches (siehe
http://w1.fi/security/2017-1/wpa-packet-number-reuse-with-replayed-messages.txt) stellt sich mir die Frage, ob AVM die tatsächlich alle auf die alte Version zurückportiert hat oder ob die "Versionsangabe" in den Binaries schlicht falsch ist, weil AVM zwar alles mögliche patcht, nur diese Versionsangabe nicht.
Andererseits ist z.B. im 1260E, der zeitgleich mit dem 1750E aktualisiert wurde auf 06.92 (
https://avm.de/aktuelles/kurz-notie...-repeater-und-wlanpowerline-produkte-von-avm/) wieder die Version "2.5-devel" enthalten.
Aber egal, welche der beiden Versionen man jetzt auch betrachtet (gilt auch für DVB-C und 310-B) ... entweder AVM hat da ganz eigene Patches entwickelt (was ohne Review auch wieder recht unklug wäre, allzu schnell hat sich da ein Fehler beim "Umschreiben" eingeschlichen) oder irgendetwas ist doch faul im Staate Dänemark.
Das geht schon damit los, daß in der Version des "hostapd" für die Repeater und auch für die exemplarisch von mir geprüfte 06.90 für die 7490 nun offenbar doch 802.11r aktiviert wurde beim Build, wenn man sich die folgenden Zeilen (schon in der Version 2.0) mal genauer anschaut:
Code:
int wpa_auth_sta_associated(struct wpa_authenticator *wpa_auth,
struct wpa_state_machine *sm)
{
if (wpa_auth == NULL || !wpa_auth->conf.wpa || sm == NULL)
return -1;
#ifdef CONFIG_IEEE80211R
if (sm->ft_completed) {
wpa_auth_logger(wpa_auth, sm->addr, LOGGER_DEBUG,
"FT authentication already completed - do not "
"start 4-way handshake");
return 0;
}
#endif /* CONFIG_IEEE80211R */
if (sm->started) {
os_memset(&sm->key_replay, 0, sizeof(sm->key_replay));
sm->ReAuthenticationRequest = TRUE;
return wpa_sm_step(sm);
}
wpa_auth_logger(wpa_auth, sm->addr, LOGGER_DEBUG,
"start authentication");
sm->started = 1;
sm->Init = TRUE;
if (wpa_sm_step(sm) == 1)
return 1; /* should not really happen */
sm->Init = FALSE;
sm->AuthenticationRequest = TRUE;
return wpa_sm_step(sm);
}
Die Nachricht "FT authentication already completed - do not start 4-way handshake" ist nämlich hier sehr wohl jeweils im Binary enthalten:
Code:
$ strings sbin/hostapd | grep "FT auth"
FT authentication already completed - do not start 4-way handshake
Zwar hat AVM nur davon geschrieben, daß die FRITZ!
Boxen am Breitbandanschluß sicher sind (in
https://avm.de/aktuelles/kurz-notiert/2017/wpa2-luecke-fritzbox-am-breitbandanschluss-ist-sicher/):
Eine FRITZ!Box am Breitbandanschluss ist nach aktuellem Stand nicht von der "Krack" genannten WLAN-Sicherheitslücke betroffen, da sie als Access Point die betroffene Norm 802.11r nicht verwendet.
und es ist ja auch tatsächlich nicht gesagt, daß AVM hier FT nach 802.11r tatsächlich
verwendet (das sind die "fast BSS transitions" zum schnellen Wechsel des AP) - aber (wie formuliert man das jetzt am besten?) es erscheint nicht unwahrscheinlich, daß AVM den "hostapd" zumindest jeweils mit "CONFIG_IEEE802111R" übersetzt. Damit
könnte man es zumindest verwenden, ohne erst noch eine neue Firmware ausliefern zu müssen.
Spannend ist auch noch die folgende Stelle in "hostapd" (ebenfalls noch in "src/ap/wpa_auth.c"):
Code:
SM_STATE(WPA_PTK, AUTHENTICATION2)
{
SM_ENTRY_MA(WPA_PTK, AUTHENTICATION2, wpa_ptk);
wpa_group_ensure_init(sm->wpa_auth, sm->group);
/*
* Definition of ANonce selection in IEEE Std 802.11i-2004 is somewhat
* ambiguous. The Authenticator state machine uses a counter that is
* incremented by one for each 4-way handshake. However, the security
* analysis of 4-way handshake points out that unpredictable nonces
* help in preventing precomputation attacks. Instead of the state
* machine definition, use an unpredictable nonce value here to provide
* stronger protection against potential precomputation attacks.
*/
if (random_get_bytes(sm->ANonce, WPA_NONCE_LEN)) {
wpa_printf(MSG_ERROR, "WPA: Failed to get random data for "
"ANonce.");
wpa_sta_disconnect(sm->wpa_auth, sm->addr);
return;
}
wpa_hexdump(MSG_DEBUG, "WPA: Assign ANonce", sm->ANonce,
WPA_NONCE_LEN);
sm->ReAuthenticationRequest = FALSE;
/* IEEE 802.11i does not clear TimeoutCtr here, but this is more
* logical place than INITIALIZE since AUTHENTICATION2 can be
* re-entered on ReAuthenticationRequest without going through
* INITIALIZE. */
sm->TimeoutCtr = 0;
}
Hier soll ja für den Fall, daß es nicht genug "Zufall" gibt, die Fehlernachricht "WPA: Failed to get random data for ANonce." ausgegeben werden. Diese findet sich aber im ganzen Binary nicht (genauer, es gibt gar keine (EDIT: passende) Fehlernachricht mit "random" im Text) und nun kann man ja mal raten, was AVM hier wohl gemacht haben wird.
Spannend wird das dann wieder dadurch, daß an dieser Stelle ein weiteres Problem ansetzt (die mehrmalige Verwendung eines "ANonce"-Wertes), gegen das auch durchaus ein Patch existiert:
http://w1.fi/security/2017-1/0005-Fix-PTK-rekeying-to-generate-a-new-ANonce.patch - aber auch die von diesem Patch nochmals "eingeführte" Fehlermeldung findet sich im "hostapd" von AVM nicht.
Auch eine andere Meldung, die normalerweise vorhanden sein sollte ("Not enough entropy in random pool" aus "wpa_group_init()") im "hostapd", legt die Vermutung nahe, daß AVM hier irgendetwas "Eigenes" veranstaltet und man kann/darf nur hoffen, daß AVM hier irgendwie tatsächlich sicherstellt, daß die mit diesen Meldungen normalerweise ausgewiesenen Fehlerbedingungen gar nicht erst auftreten. Ich bin allerdings nicht allzu optimistisch ... Entropy "zu sammeln" ist auf diesen Geräten ja immer ein besonderes Thema. Hoffentlich hat da nicht nur jemand kurzerhand den Test und die Fehlermeldungen beim Scheitern deaktiviert, weil das "nicht gut aussah".
Jedenfalls setzt auch hier ja eine mögliche Replay-Attacke an und das wäre auch die einzige Stelle gewesen, wo man beim 1:1-Anwenden der Patches erwarten müßte, daß eine entsprechende Fehlermeldung im Binary landet.
Die anderen Patches enthalten zwar auch noch einige zusätzliche Nachrichten, die könnten aber mit passenden Einstellungen bei der Übersetzung ausgeblendet werden - mit einer Ausnahme und das wäre die Nachricht "WPA: Invalid IGTK KeyID %d".
Allerdings landet die nur im Binary (EDIT: in diesem Falle in "wpa_supplicant"), wenn man 802.11w (das ist der Schutz der "management frames", der dann wieder verhindert, daß einfach Clients von anderen vom AP abgemeldet werden - "deauthentication attack") bei der Übersetzung aktiviert hat (über CONFIG_IEEE80211W).
Das scheint aber nur für die Version 2.5-devel bei AVM der Fall zu sein ... es ist schon alles etwas "undurchsichtig", wenn man da versucht mal durchzusteigen.
Jedenfalls kann man (bzw. ich) die Idee wohl vergessen, einfach den "hostapd" und "wpa_supplicant" für einen 300E auszutauschen gegen Dateien, die aus den "vanilla sources" erstellt wurden - da hat AVM kräftig drin geändert, wobei es bei der 2.5-devel deutlich weniger Stellen gibt, wo "AVM" (egal in welcher Schreibweise, groß/klein/mixed) zu finden wäre.
Vielleicht will AVM ja deutlich näher an die originalen Quellen heranrücken und wirklich nur noch das Logging nach eigenen Vorstellungen umsetzen (das sieht bei der 2.5-devel ein wenig danach aus).
