KNX este standard mondial de automatizări pentru case și clădiri de afaceri. Creatoarea și proprietara tehnologiei KNX, “KNX Association cvba”, a fost înființată în mai 1999 de către membri următoarelor asociații: EIBA (European Installation Bus Association), EHSA (European Home Systems Association) și BCI (BatiBUS club International) și are sediul în Brussel.
Doresc să împărtășesc în acest post următoarea situație reală. Ceea ce aș vrea să menționez de la început este că suntem oarecum amatori complet când vine vorba de hardware KNX (abilitățile noastre sunt în principal software), așa că unele dintre metodele mele sunt ... în cel mai bun caz la nivel de amator. Oricum, îmi plac circuitele de hacking precum și chestii de inginerie inversă, așa că părea o provocare frumoasă, având în vedere că nu am mai lucrat niciodată cu KNX.
Tip #1 - Vandalismul cibernetic...
Cândva, la sfârșitul lunii decembrie 2021, un atacator a obținut acces la un sistem KNX și a blocat toate dispozitivele cu o parolă BCU și nu a mai existat nicio modalitate de a prelua controlul asupra sistemului afectat după acest incident de vandalism cibernetic.
Când este setată o astfel de parolă BCU , toate dispozitivele KNX din sistem/proiect care acceptă această caracteristică, vor fi blocate în timpul procesului de programare folosind o parolă (8 caractere sau 4 octeți lungime). Odată activate, dispozitivele protejate cu o cheie/parolă BCU nu pot fi modificate ulterior decât dacă parola este cunoscută (majoritatea dispozitivelor nu vor permite resetarea parolei, chiar și cu acces fizic la dispozitiv).
Este ca și cum s-ar sterge complet ssd-ul unui laptop apoi se setează și o parola suplimentară de acces la ssd ca să nu mai poată fi scris blocând utilizarea laptop-ului sau instalarea din nou a sistemului de operare. Adică ori se gasește o cale de aflare a parolei sau se înlocuiește ssd-ul.
Tip #2 - Documentarea și analiza soluțiilor posibile.
După ce am petrecut zile întregi demontând cateva echipamente hardware (butoane Gira 5133/5131/5142, actuatoare Gira cu 8 și 16 canale și chiar și o stație meteo Gira) a devenit clar că, în acest caz, metoda pe care a folosit-o Limes nu putea fi aplicată deoarece aveam doar dispozitivele Gira și, deși toate sunt alimentate de micro-uri Atmel (cu care sunt destul de familiar și confortabil privind sondarea și interogarea lor), toate dispozitivele au siguranțe de blocare setate, astfel încât nu există nicio modalitate de a accesa zonele flash/eeprom și de a obține un spațiu mai limitat pentru un atac bruteforce.
"Într-adevăr, încercarea de a proba prin bruteforce întregul spațiu de 32 de biți pare imposibil la prima vedere și ar dura mai mulți ani pentru a se finaliza pe un singur dispozitiv la viteza scăzută de 9600 bps a magistralei KNX." –
Dar a avea zeci de dispozitive cu aceeași parolă (ceea ce am presupus că s-a intamplat în cazul nostru!), dă o licărire de speranță, cu atât mai mult dacă poate fi găsită o modalitate de a accelera procesul, chiar și puțin.
Când am căutat conținutul flash/eeprom, a devenit evident că butoanele ar putea fi de ajutor în ceea ce privește viteza interogărilor: butoanele (sunt cu mine aici, nu știam nimic despre sistemul KNX la momentul respectiv) nu sunt conectate direct la magistrală, dar utilizează magistrala cu un cuplaj multiplicator 3 și comunicarea aici folosește de fapt un UART de 115200 bps: există un microcontroler în magistrala de cuplare 3 care comunică cu magistrala KNX la viteza limitată de 9600 baud și cu butoanele în sine la mai mult, 115200 baudrate. Suplimentar, microcontrolerul din cuplajul magistralei acționează doar ca o poartă de acces, iar parola reală BCU se află în microcontrolerul din butoane. Astfel sondarea acestei magistrale la 115200 (se face cu ușurință cu orice analizor logic sau, în cazul meu cu un osciloscop Rigol) a arătat că protocolul folosit este asemănător KNX:
"Am ajuns teoretic la un calcul de genul acesta 2^32 încercări / 50 (încercări/secunda) / 86400 (secunde/zi) ... 994 de zile!!!; însă cu cu 32 de device-uri în paralel s-ar reduce la... 31 de zile!
Deci, în acest moment, am cam decis că trimiterea mai multor solicitări de autentificare către mai multe dispozitive în paralel prin acest bus mai rapid ar putea ajuta. Următorul pas ar fi să decidem asupra gazdei (sau gazdelor) care urmează să fie folosite pentru a formata și trimite pachetele către dispozitive. Prima idee (ca de obicei, cea care nu funcționează) a fost să folosesc o grămadă de plăci de dezvoltare esp32, deoarece au 2 (poate chiar 3, dacă pot ocoli jurnalul bootloader-ului pe UART0) UART-uri hardware (la 115200) baudrate, am presupus corect că numai UART-urile hardware sunt utilizabile.
Știam deja că, deși la 115200 baudrate, magistrala are anumite cerințe de sincronizare: gazda nu poate trimite cât mai repede posibil, iar dispozitivul va întârzia destul de mult înainte de a răspunde, așa că poate s-ar putea face o anumită multiplexare în software (unele considerente hardware trebuie luate în considerare atunci când conectați mai multe dispozitive pe un UART, dar până la urmă nu am ajuns niciodată atât de departe cu această idee) pentru a conecta două dispozitive pe port UART esp32. Acest lucru ar necesita aproximativ 10 ESP pentru a conecta 60 de dispozitive (10 ESP x 3 UART x 2 dispozitive) ... și la o viteză de 30 de încercări pe secundă (da, era o iluzie în acest moment), timpul total pentru întreaga Spațiul pe 32 de biți nu va depăși 30 de zile; deși nu este grozav, această perioadă de timp pare ceva care ar putea funcționa, nu-i așa?
Din păcate, acest lucru s-a dovedit că nu funcționeză, deoarece atunci când am sondat magistrala la 115200 baudrate, am ratat complet faptul că magistrala folosea de fapt un format de cadru serial 9E1, ceea ce presupun că este doar o ciudatenie a implementării Atmel, deoarece acest lucru nu este deloc un format de cadru serial standard (9N1 este cel mai apropiat standard pe care l-am putut găsi). Oricum, acest format cu siguranță nu este acceptat de UART-urile hardware esp32. După ce m-am mai jucat câteva zile cu unele biblioteci SoftwareSerial pentru esp32 care acceptau formatul de cadru necesar, am ajuns cu siguranță la concluzia că mă aflu intr-un punct mort (este exact ceea ce v-ați aștepta de la mai multe seriale software care rulează pe un singur micro-controller).
Ceea ce era necesar, era o gazdă bazată pe Atmel pentru formatarea cadrelor, trimiterea și primirea;
Arduino Mega2560 (am anunțat deja că unele soluții sunt pentru amatori, nu-i așa?) are totuși 4 UART-uri hardware frumoase care așteaptă să fie folosite.
O abordare profesională ar fi să folosești unul (sau poate mai multe) FPGA-uri pentru a implementa mai mult de 4 UART-uri pe gazdă, dar nu aveam niciunul dintre acestea la dispoziție, așa că am rămas la Arduino (și am ajuns să am 23! Arduino-uri orechestrate pentru a lucra împreună)...
Am cumparat și destul de multe dintre ele (pe langă unele împrumutate de la prieteni)... din fericire, dacă cumperi fără marcă - traiasca open-hardware! - sunt destul de ieftine la ~10 Euro aici în Romania.
Configurația care a sfârșit prin a funcționa a fost conectarea a 3 dispozitive pe 3 dintre porturile UART ale Arduino (am renunțat și la gunoiul de multiplexare) având al patrulea UART conectat la un esp32 pentru orchestrare. Acest al 4-lea port ar fi putut fi un serial software, deoarece am decis că 9600 bps este suficient pentru a primi sarcinile și a raporta stări, dar știam cu adevărat că serialele software încurcă întreruperile de sincronizare din Arduino și deja eram mai mult decât sătul cu implementarea software-ului, așa că am decis să folosesc doar unul dintre porturile hardware în acest scop. În esp32 am folosit seriale implementate de software, deoarece nu aveam cerințe de sincronizare (dar am ajuns să folosesc sume de control pentru cadrele de sarcină/stare, deoarece nu era oarecum de încredere, dar nu suficient pentru a fi o problemă) pentru că am vrut să conectez patru Arduino-uri la un singur esp32 (aș fi putut conecta mai multe, dar aveam deja ESP-urile de rezervă).
Am ajuns apoi să imprimăm și rafturi mici prin tehnologie 3D pentru a ține dispozitivele și plăcile Arduino împreună; chiar și așa, cablarea a fost o provocare absolută...
Această configurare a reușit să livreze ~18 încercări pe secundă per dispozitiv (unele dispozitive - 5133/5131 au fost de fapt mai rapide cu ~19+ încercări pe secundă, iar unele au fost mai lente - 5142s au răspuns doar suficient de repede pentru 8-9 încercări pe secundă;
Presupun că micro-controlerul a fost încărcat mai mult cu gestionarea ecranului și de aceea răspunsurile lui au fost întârziate mai mult).
Tip #3 - Așteptarea și aflarea parolei
Având acum 6 esp32-uri fiecare având câte 4 rack-uri (al șaselea a ajuns să aibă doar trei, pentru că aveam profituri descrescătoare de la 5142-urile mai lente pe care le aveam la dispoziție), fiecare rack având la rândul său un Arduino și 3 dispozitive, am împărțit întregul domeniu de 32 de biți în 8192 „bucăți” a câte 524288 chei fiecare (2^13 bucăți x 2^19 chei pentru o gestionare ușoară).
Fiecărui dispozitiv i se va atribui apoi o bucată aleatorie (aceasta idee a ajutat foarte mult!) și ar încerca fiecare cheie din bucată (o bucată este un număr de la 0 la 8191: mutați numărul cu 19 biți la stânga și începeți să creșteți 2^ de 19 ori; apoi repetați, și repetați și repetați... o sarcină destul de ușor de implementat în Arduino, după ce mi-am dat seama ce cadre să trimit dispozitivului și cum să analizez răspunsurile).
Cu această configurare, un 5133/5131 și-ar termina porțiunea atribuită în aproximativ 7h30-8h00; unul 5142 s-ar termina în aproximativ dublu timp.
Esp32-urile ar transmite apoi date către și de la Arduino către un script php cu o bază de date sqlite destul de mică pentru a păstra in ea evidența progresului.
Timpul estimat în cel mai rău caz a ajuns să fie mai aproape de 45 de zile, dar în cele din urmă cheia a fost găsită după ~15 zile.
Sistemul a verificat doar ~37% din spațiul complet de 32 de biți iar cheia, dacă era luată în ordine secvențială, de la 0x00000000 la 0xFFFFFFFF se afla la ~73% din spațiu (deci, folosind pachete aleatoare, am primit o accelerare de 2x, deși acest lucru desigur, nu a fost nicio garanție la început...)
În concluzie, securitatea IT poate preveni...
Care a fost motivul și scopul atacatorului nu se știe în acest moment, deoarece deținatorul sistemului nu a primit nicio cerere de răscumpărare. Este posibil să fi fost doar un act avansat de vandalism cibernetic sau poate doar dificultatea practică de a afla pe internet cine este cu adevărat operatorul acelui sistem și unde să se adreseze nota de răscumpărare.
Mulți oameni nu realizează cât de complexe și puternice sunt de fapt unele protocoale ale sistemului de control. În mâna unui atacator informat, această putere poate fi, desigur, îndreptată și împotriva deținătorului, dacă acesta obține acces la un dispozitiv. Aceasta, deoarece multe sisteme de control utilizate astăzi încă nu au funcții de bază de securitate, deoarece au fost concepute într-un moment în care securitatea nu era considerată încă o necesitate. De aceea trebuie să ne asigurăm că acele dispozitive nu sunt ușor accesibile atacatorilor.
Imediat ce am fost solicitați să intervenim in acest caz și s-a constatat tentativa de vandalism cibernetic reușită s-a procedat la securizarea perimetrului de rețea și inchiderea tuturor porturilor deschise din internet catre unele adrese IP din rețeaua LAN.
O sugestie prietenoasă este să externalizați riscurile sistemelor informatice către o firmă specializată în furnizarea de servicii profesionale IT.