Home Assistant - CVE-2023-27482 (kritikus sérülékenység) kihasználása most egy aktuális téma. A sérülékenységet 2023.03.08-án fedezték fel és jelentették a HA fejlesztőinek, de a zero day sérülékenységek útjának szabályait betartva csak 2023.05.10-én került publikálásra a kihasználásához tartozó teljes leírás, miután a fejlesztők javították a sérülékenységet. Ez a verzió pedig a Supervisor 2023.03.1. Akinek ez előtti verziója van és elérhető a rendszere a publikus internet irányából, védtelen.

Többször jeleztem ezt a sérülékenységet, melyet kihasználva a teljes okos otthon központunk felett átvehetik az irányítást a támadók, de meglátásom szerint ez a legkisebb kár, amit okozhatnak nekünk.

Ha belegondolunk, hogy milyen adatokat adunk meg a rendszerünk építése közben, beláthatjuk, hogy aki hozzáférést szerez hozzá, több accountunk adatait is megszerezheti.

De milyen adatok is lehetnek ezek?

• Mail küldés: megadjuk a belépési adatainkat. E-mail cím, jelszó, szerver.
• ESPHome: megadjuk az otthoni WiFi elérésünket, hogy a konfigurált eszközeink fel tudjanak jelentkezni.
• Kamerák: http/rtsp url-be megadjuk a kamerákhoz tartozó login/jelszó párost és a kamerák elérési címét a hálózatunkban
• Samba share: megadjuk a megosztás eléréséhez szükséges login/password párost
• MQTT, zigbee2mqtt, stb.: a brokerhez megadjuk a login/password párost
• Felület elérése: megadjuk a felhasználó nevünket, itt egy kicsit jobb a helyzet, mert a jelszó már elkódolva található, így több időbe telik a feltörése, nem kapjuk meg egyből
• Riasztó rendszer: a PIN kód, amivel élesíthető/kikapcsolható a riasztó
• Otthonunk címe
• Munkahelyünk, egyéb zónáink

Ezt így leírva mindenki tudja, de szeretném bemutatni, milyen egyszerűen megszerezhetőek ezek az adatok a rendszerünkből és akár TE is ki tudd próbálni, hogy a rendszered érintett -e még a sérülékenységben.

Hackelhető rendszer létrehozása

Először is létre kellett hozzak egy megfelelő rendszert, amit szabadon hackelhetek, mert ugyan az interneten rengeteg sérülékeny rendszer található, de azokat nem lenne etikus kompromittálni. A választásom a még sérülékeny 2022.12.1-es verzióra esett és a Home Assistant OS 9.5 verzióra. Első gondolatom az volt, hogy virtual boxban felhúzom és öröm, boldogság, kezdődhet is a játék, de nem, mert a rendszer tervezői okosan lefrissítenek minden komponenst már a bootolás alatt, így mire megkapjuk a belépési felületet, már egy aktuális verzión futó rendszerünk van (az OP rendszer kivéve), ami számomra nem megfelelő, de ha ez van, akkor ezzel kell dolgozni.

Szerencsére a core downgradelhető elég könnyedén, ha konzolon belépünk és kiadjuk az alábbi parancsot:

Ezzel egy lépéssel közelebb kerültünk a célhoz, de a supervisor még mindig a legfrissebb verzió és első googlizásra és dokumentáció olvasásra az az érzésünk lehet, hogy ezen nem is tudunk változtatni.   

Ha mélyebben belenézünk a rendszerbe, akkor nincs itt semmi mágikus dolog csak a most már széles körben alkalmazott docker rendszer. Minden komponens külön docker containerbe kerül, majd okosan konfigurálva a rendszer komponensei (a konténerekben futó szolgáltatások, addonok) kommunikálnak egymással. Ebből egyenesen következik, hogy akkor mégiscsak van mód a supervisor downgrade-elérése :) Nem lesz egyszerű, de leírom, mert más is kedvet kaphat otthon a játékra. Előre is elnézés kérek, hogy ezzel ennek a blog posztnak a hosszát növelem, ha nem érdekel, tekerd át ;)

Hassio-Supervisor downgrade

Először is ki kell lépni a ha konzolból, vagyis inkább be kell lépni az oprendszer szintre, ahonnan elérjük a dockert és konfigurálni tudjuk azt. Ehhez még a Virtual Boxban futó HA rendszerünknek hagyjuk meg az internet elérését, mert a régebbi supervisor imaget a netről fogjuk letölteni. Amint letöltésre kerül a régebbi image, el kell vennünk a VM-től a hálózatot, különben lefrissíti magát ismét az aktuális verzióra, ami most nem célunk. A folyamat során kiadandó parancsok:

Először állítsuk le a futó hassio_supervisor containert, majd távolítsuk el minden fájljával és image-vel együtt. 

Ha eltakarítottuk az aktuális (latest) supervisort, jöhet a régi image beszerzése. Amint letöltődött az image, kapcsoljuk le a VirtualBox-ban a VM hálózati kapcsolatát, nehogy frissítse a supervisor-t, amíg nem végzünk a teljes downgrade folyamattal.

Most jöhet a letöltött image-ünk futtatása. Ezt a parancsot könnyű elgépelni, nekem sem elsőre sikerült :D

A képernyő képről lemaradt az attache command, ne felejtsétek kiadni!

Ha mindennel megvagyunk, akkor jöhet a rendszer újraindítása a reboot paranccsal, de a VM-nek még nincs hálózati elérése, ezért a boot több időt vesz igénybe. Ha betöltött a rendszer, nincs más dolgunk, mint kikapcsolni az auto update-et a supervisor containeren.

Most már visszaadhatjuk a hálózatot a VM-nek és beléphetünk a HA rendszerünk weboldalán. Ha mindent jól csináltunk, akkor a kívánt állapotot értük el, lett egy sérülékeny Home Assistant példányunk.

Itt hívnám fel a figyelmet, hogy egy ilyen tudottan sérülékeny rendszert ne tegyünk elérhetővé a publikus internet irányból, mert bármikor érhet meglepetés bennünket egy hacker személyében, aki szintén megtalálja a rendszerünket.

Persze a rendszer is figyelmeztet minket, hogy ez egy unsupported, elavult verzió:

Többször kérdezték már tőlem, hogy hogyan lehet belebotlani a neten egy sérülékeny Home Assistant rendszer elérésébe. Nem kell más, mint ismerni a shodan-t és egy egyszerű keresést indítani benne.

Most már rendelkezésünkre áll egy frissen telepített, de sérülékeny rendszer, amin kipróbálhatjuk, mit is lehet kihozni ebből a sérülékenységéből, lássunk is hozzá.

Sérülékenység kihasználása

Először is mi is ez a sérülékenység nagy vonalakban?

A probléma a supervisor API-ban keresendő, ugyanis nincs hozzáférés ellenőrzés, így bárki, bejelentkezés nélkül indíthat kéréseket a rendszerünk felé ezen keresztül.

Milyen kéréseket lehet indítani?

Ezt a dokumentáció szépen leírja, nem fejteném ki, de szinte bármit elérhetünk...

Először is lépjünk be a frissen telepített Home Assistant rendszerünkbe, hogy legalább egy felhasználónk legyen a rendszerhez. Nem konfigurálok fel eszközt (bár az okos hangfalamat megtalálta egyből és be is állította), sem plugint, sem addont, nézzük meg így mire lehet jutni. Egy beállított, már régóta futó rendszer könnyebb feladat lenne, hisz azon már gondoskodunk az automata mentésről, esetleg egyből google drive-ra, van futó és beállított mosquitto brokerünk és sorolhatnám még a végtelenségig.

Szóval egy üres rendszerünk van, még backup sincs róla.

Miért is fontos, hogy nincs backup?

Az elképzelt támadási vektorom a rendszerrel szemben:

• full backup megszerzése
• backup tartalmának vizsgálata felhasználónevek és jelszavak szerzése céljából
• ha nincs benne semmi ilyen (és nem lesz), akkor a megszerzett backup módosítása úgy, hogy létrehozok benne egy új felhasználót
• módosított backup visszatöltése a támadott rendszerbe
• módosított backup visszaállítása
• bejelentkezés a web felületen az új felhasználóval
• opcionális, de nem fogom megtenni: backup és módosított, visszatöltött backup törlése

Először ellenőrizzük, hogy tényleg sérülékeny a rendszer. Ezt megtehetjük az alábbi url meghívásával egy böngészőben. Arra figyeljünk oda, hogy privát módba indítsuk a böngészőt vagy lépjünk ki a Home Assistant weboldalról, hogy ne legyen élő sessionunk/bejelentkezésünk.

Ha válaszol a rendszer, akkor sérülékeny, mert authentikáció nélkül kiszolgálja a kérésünket:

A terv szerint a backup megszerzése a célunk a rendszerből, melyre az API dokumentációja szerint az alábbi endpointok állnak rendelkezésünkre:

Következő lépésben kérdezzük le a backup listát a rendszerből:

Számunkra full backupok az érdekesek, mert abban van meg minden infó a rendszer helyreállításához és az érzékeny adatok (felhasználónevek és jelszavak).

A böngészőt most kicsit félreteszem és előveszem a Burp toolt, melyben ugyanez a kérés és válasz így néz ki:

Az látszik, hogy a rendszerünkben nincs egyetlen bakup fájl sem. Az API viszont lehetőséget biztosít számunkra, hogy létrehozzunk egy új, teljes backupot. Ehhez egy POST utasítást kell kiadnunk a megfelelő végpont felé és megfelelő tartalommal. Mivel nem szeretném, hogy a rendszer jelszóval titkosítsa, elegendő a kívánt backup nevét elküldeni. Ha sikeresen végrehajtotta a rendszer a kérésünket, válaszban visszakapjuk a backup ID-ját (slug).

Ahhoz, hogy megbizonyosodjunk róla, sikeresen elkészült a mentésünk, kérjük le újra a backup listát.

Ha a rendszer tulajdonosa ezen a ponton nézi meg a weboldalon a backup fájlok listáját, akkor lebukhatunk, mert szerepelni fog rajta:

Következő lépés az elkészült backup letöltése, melyet az alábbi kéréssel tudunk megszerezni. Ehhez a backup slug-ját kell megadnunk az URL-ben:

Böngészőből meghívva az URL-t, a letöltés megkezdődik.

Most következik a megszerzett backup átvizsgálása. Érzékeny információkat keresünk, felhasználóneveket, jelszavakat, elérési pontokat, stb.

Ehhez vagy linuxot használunk vagy windows alatt a total commander alkalmazást, mert az ki tudja bontani a .tar és .gz tömörített fájlokat.

A megszerzett backup struktúrája megegyezik a rendszerünkön találhatóval, így aki látott már ilyet, tudja mit és hol keressen.

A weboldara való bejelentkezések jelszavait a rendszer titkosítja (hasheli), így azok nem olvashatóak, viszont több tool áll rendelkezésünkre, hogy a megszerzett hash-t jelszó töréssel próbáljuk visszafejteni. Ilyen széles körben ismert és használt toolok a HashCat és a JohnTheRipper. Egy hash kell nekik és egy jelszó lista, bár nem elhanyagolható tényező, hogy egy erős hardware kell alájuk, jó kis videó kártyákkal a hatékonyság növelésére.

A fájlok között megtalálható a támadott rendszer GPS pozíciója is, amiből megismerhetjük, hol található az ingatlan, amit a rendszer felügyel/vezérel. Ebben az adatban viszont nem lehetünk 100%-ig biztosak, hogy valós. Ha találunk automatizációkat vagy különböző tracker beállításokat, akkor már biztosak lehetünk a helyszínben, mert ezek helyes futásához szükséges a pontos beállítás.

Egy frissen telepített rendszerben nem nagyon találunk érzékeny információkat, viszont a cél a rendszerbe való behatolás. Ehhez módosítom a letöltött és kicsomagolt konfig fájlok tartalmát, majd visszatömörítek mindent, hogy feltölthető legyen a támadott rendszerbe.

Létrehozom az új felhasználót:

Hozzáadom a system-admin csoporthoz:

Megadom a hashelt jelszavát (ebben semmi varázslat nincs, mert egy másik virtuális gépen létrehozott rendszerből exportáltam egy teljes mentést és abból szedtem ki a szükséges adatokat és másolgatom át a megfelelő részeket ebbe a backupba, mert számomra ez a leggyorsabb folyamat): 

Az összes módosítandó fájlt nem publikálom, hogy ha valaki utánam szeretné csinálni, legyen egy kis házi feladata.

Ha minden módosítással elkészültünk, nincs más dolgunk, mint újra betömöríteni a backupot, feltölteni a támadott rendszerbe, majd visszaállítani.

 Ha sikeres a feltöltés, következő lépés a restore:

Ha minden sikeresen lefut és jól módosítottuk a backupban található fájlokat, akkor az újonnan létrehozott felhasználónkkal be tudunk jelentkezni a támadott Home Assistant rendszer weboldalára:

Ez szintén egy lebukási pont, ha a rendszer tulajdonosa megnézi a felhasználó listát, akkor észre fogja venni az illetéktelen hozzáférést. Ugyanez igaz az általunk készített vagy a feltöltött, módosított backupra is.

A backupok a kisebb probléma, mert azt akár a felületen (hiszen már van hozzáférésünk hozzá) vagy egy újabb API hívással törölhetjük.

Mit találhatunk egy élő rendszerben?

Kaptam pár backup fájlt élő rendszerekből - köszönet érte - melyeket megvizsgálva elég sok információ és érzékeny adat megszerezhető belőle, álljon itt pár példa ezekből, melyek olvasható (plain text) jelszavakat tartalmaznak. Az érzékeny adatokat szándékosan takartam ki :) 

Belépési API jelszó a felülethez és riasztó rendszer kódja:

Kamerák hozzáférési adatai (felhasználónév, jelszó, belső hálózati elérés):

E-mail küldéshez beállított g-mail fiók (felhasználónév és jelszó): 

MQTT Broker eléréshez tartozó felhasználónév és jelszó:

Szintén MQTT felhasználó és jelszó, zigbee2mqtt irányból:

Végül egy kis ESPHome konfig, mely tartalmazza a WiFi elérési adatokat (SSID és jelszó):

Már ebből a pár konfig fájlból is látható, ha valaki távolról hozzáfér egy jól felszerelt okosotthon központhoz, elég nagy kárt tud okozni nekünk. Ismeri a címünket, ki tudja nyitni a kapunkat, ajtónkat, ismeri a riasztó kódunkat, láthatja a kameráink képét, melyből megismerheti a szokásainkat, mikor vagyunk otthon, mikor dolgozunk. Innentől mindenki fantáziájára bízom, mi mindent tud elérni...

A rendszerünket érintő biztonsági riasztások és frissítések, amiket kapunk, nem véletlenül vannak. Kényelmetlen és benne van a veszély, hogy a rendszerünket módosítani szükséges 1-1 új frissítés telepítésénél, de a frissítés elhanyagolása komoly kockázatot jelenthet, hisz akár anyagi kár is érhet bennünket, míg az okos otthonunk konfigurációjának módosítása "csak" egy kis bosszúsággal és pár ősz hajszállal jár.

Ez a kritikus sérülékenység rádöbbentett, bár naponta, munkaidőben különböző sérülékenységeket keresek a Superior Pentest Kft. seniorjaként, szabadidőmben eszembe sem jutott ránézni arra a rendszerre, mely a házamat vezérli.