Qualche tempo fa mi è stato chiesto di realizzare un sistema di controllo remoto delle centraline di allarme di una famosa marca che aggirasse le serie limitazioni imposte dal software originale.
Dopo un certo sforzo per eseguire il reverse engineering del protocollo e altrettanto per realizzare il software di gestione, tutto sembrava procedere per il meglio, il cliente era soddisfatto e io anche di più.
Dopo qualche mese tuttavia, il produttore di dette centraline ebbe un’idea magnifica: approfittare di un update per proteggere qualunque connessione alla centralina con una bella password. Risultato: una flotta di centraline alle quali non si poteva applicare il nuovo firmware pena la perdita della comunicazione da remoto.
Fu così che mi ritrovai ad analizzare l’immagine del nuovo firmware: l’archivio gzip+tar conteneva una piccola installazione di Busybox, lievemente personalizzata. Il file /etc/passwd rivelava un unico utente interessante, root, la cui password era hashata anche se priva di salt.
root:$1$$Gy6TZqlzlpB33bh6FLu9T0:0:0:root:/:/bin/sh nobody:*:254:254:nobody:/var/empty:/bin/sh logout:gfr8cijmRSDck:498:506:logout:/:
Dopo un veloce test con le rainbow tables risoltosi con un buco nell’acqua, la prospettiva non proprio allettante era ricorrere alla forza bruta.
Salvando l’hash per poterci lavorare con comodo, però, mi venne in mente una cosa: come faceva il software di update a sovrascrivere il firmware della centralina utilizzando la sola porta di rete? Doveva necessariamente connettersi e loggarsi!
Un nmap aggressive eseguito contro la scheda rivelò diverse porta in ascolto, tra cui un demone FTP e un accesso telnet. Un login via FTP utilizzando l’user “nobody” diede esito positivo e, anche se non era possibile leggere ne scrivere alcunché, ormai la strada era tracciata: l’update doveva avvenire tramite FTP, quindi il software di aggiornamento del firmware doveva in qualche modo contenere la password di root.
E indovinate un po’ come era stato realizzato tale software? In java.
Dopo aver spacchettato il file jar, spendo 10 minuti in compagnia di DJ Java Decompiler. Procedendo a tentoni tra i sorgenti, trovo il file di bytecode NewJFrame$PutFile.class, contenente questa routine:
if (default_user == true) {
try {
NewJFrame.client.disconnect(true);
NewJFrame.client.connect(NewJFrame.jIP.getText(), 21);
NewJFrame.client.login("root", "**************");
}
catch (Exception ex) {
System.out.println(ex.toString());
NewJFrame.jBtnVer.setEnabled(true);
NewJFrame.jVer.setBackground(Color.red);
NewJFrame.jVer.setText("Not verified");
return false;
}
}
La password, perfettamente in chiaro e che qui ovviamente sostituisco con degli asterischi, si rivela essere perfettamente valida sia per l’accesso root via FTP che per telnet e ovviamente è impossibile sostituirla come invece ci si aspetterebbe.
Questo però significa anche che tutte le centraline di questa marca, se affacciate su internet, possono essere disabilitate o manomesse da chiunque, in qualunque momento. Tra l’altro hanno una fingerprint di rete anche abbastanza singolare e riconoscibile…
Diciamo che per essere il cuore di un sistema di allarme per sistemi sia domestici che industriali sono forse un po’ debolucce e il sistema di autenticazione andrebbe senz’altro ripensato.
PS. non pubblico la marca ne il modello della centralina per ovvie ragioni e scrivo a più di un anno dalla segnalazione, nella speranza che il problema nel frattempo sia stato risolto (non ho modo di verificare purtroppo).