Home Assistant - CVE-2023-27482

September 20, 2023

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. – Fizcere Tamás, senior kollégánk beszámolója.

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:

 core update --version 2022.12.1

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:

login

docker container ls
docker stop hassio_supervisor
docker rm -f hassio_supervisor

docker images
docker rmi --force <image ID>

docker image pull ghcr.io/home-assistant/amd64-hassio-supervisor:2022.12.1
docker tag ghcr.io/home-assistant/amd64-hassio-supervisor:2022.12.1 ghcr.io/home-assistant/amd64-hassio-supervisor:latest
docker images

#vegyük el a VM-től az internetet, kacsoljuk ki a háló kártyát VirtualBox-ból!!!

docker run -d --name=hassio_supervisor -v /run/dbus:/run/dbus:ro -v /run/udev:/run/udev:ro -v /run/supervisor:/run/os:rw -v /etc/machine-id:/etc/machine-id:ro -v /mnt/data/supervisor:/data:rw -v /run/docker.sock:/run/docker.sock:rw -v /run/docker/containerd/containerd.sock:/run/docker/containerd/containerd.sock:rw -v /run/systemd-journal-gatewayd.sock:/run/systemd-journal-gatewayd.sock:rw -e SUPERVISOR_NAME=hassio_supervisor -e SUPERVISOR_API=http://localhost -e SUPERVISOR_SHARE=/mnt/data/supervisor --security-opt seccomp=unconfined --security-opt apparmor=hassio-supervisor --privileged --restart always ghcr.io/home-assistant/amd64-hassio-supervisor:2022.12.1

docker start --attach hassio_supervisor

reboot
ha supervisor options --auto-update=false

#most már visszaadhatjuk az internetet/háló kártyát a VM-nek

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.

supervisor options --auto-update=false

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.

http://vulnerable-HA-IP:8123/api/hassio/app/.%252e/supervisor/info

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:

http://vulnerable-HA-IP:8123/api/hassio/app/.%252e/backups

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.

http://vulnerable-HA-IP:8123/api/hassio/app/.%252e/backups

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:

http://vulnerable-HA-IP:8123/api/hassio/app/.%252e/backups/slug/download

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:

http://vulnerable-HA-IP:8123/api/hassio/app/.%252e/backups/slug/restore/full

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.

A WinRAR Zero Day Sebezhetőség (CVE-2023-38831)

September 15, 2023

A WinRAR adatainak tömörítésére és archiválására használt eszköz, amely az évek során elengedhetetlen eszközzé vált sok ember számára. Azonban a technológiai előrelépésekkel együtt a kiberbiztonsági kockázatok is növekednek.

 

A sebezhetőségről

 

A CVE-2023-38831 kódú sebezhetőség nem csak egy egyszerű hibát jelent. Ez a kód a kiberbiztonsági világban egy vészharangot jelent, amely arra figyelmeztet, hogy a megszokott eszközeink nem mindig olyan biztonságosak, mint gondolnánk. A WinRAR ezen verziójában a támadók képesek arra, hogy egy ártalmatlannak tűnő ZIP archívumban kártékony kódot rejtsenek el. Mi a legrosszabb az egészben? Hogy a felhasználóknak ez fel sem tűnik. A kártékony kódok beépítése és elrejtése ugyanis olyan módszerekkel történik, amelyek gyakran még a legtapasztaltabb IT szakembereket is megtévesztik.

 

Hogyan használják ki a hackerek a sebezhetőséget?

 

Digitális korban élünk, ahol minden információ egy kattintásra található. De mi van, ha ez az egy kattintás nem csak egy kép vagy dokumentum megnyitását jelenti, hanem egy kártékony kód futtatását is? A Reddit Cybersecurity oldalán megjelent cikk szerint a támadók ezt a sebezhetőséget használják ki, hogy pénzt lopjanak bróker számlákról. Gondoljunk csak bele: egy egyszerű fájl letöltése és megnyitása pénzveszteséghez vezethet. A digitális bűnözés ezen formája egyre növekvő aggodalomra ad okot, különösen azok számára, akik aktívan részt vesznek online tranzakciókban vagy befektetésekben.

Nézzünk meg egy esetet

 

Péter pénzügyi tanácsadóként dolgozik, gyakran kap különféle dokumentumokat klienseitől és kollégáitól.

 

Egy napon e-mailt kap egy ismeretlen feladótól, amely egy ZIP archívumot tartalmaz, a melléklet neve "BefektetésiJavaslat2023.zip". Péter azt gondolja, hogy ez egy új ügyfél lehet, aki befektetési tanácsot kér, ezért letölti és megnyitja a fájlt.

 

Amikor megnyitja a ZIP fájlt, semmi sem tűnik szokatlannak. Egy JPG képfájl van benne, amin egy diagram található. De amit nem tud, hogy miközben megnyitotta a képet, a háttérben egy kártékony kód futott le, amit a támadók a WinRAR sebezhetőségének kihasználásával helyeztek el a fájlban.

 

Péter az egészből nem vesz észre semmit, mivel a kártékony kód feltűnés nélkül fut le a háttérben, így hozzáférést szerezve a számítógépéhez. A támadók ezután képesek elérni Péter pénzügyi adatait, beleértve a banki információikat és a kliensek adatait.

 

Néhány órával később Péter értesítést kap a bankjától, mely szerint nagy összegű tranzakciókat hajtanak végre a számlájáról.

 

Az Exploitációs eszköz a GitHubon

 

A kiberbiztonsági közösség mindig gyorsan reagál az ilyen fenyegetésekre. A GitHubon közzétett Python script egy példa erre. Ez az eszköz lehetővé teszi a felhasználók számára, hogy megértsék és teszteljék a sebezhetőséget, hogy jobban felkészülhessenek rá és így megvédhessék magukat. A közösség által létrehozott eszközök és források, mint az említett script, elengedhetetlenek a kiberbiztonsági tudatosság növelésében és a közösség védelmében.

 

A kiberbiztonsági tudatosság és a frissítések fontossága

 

A technológia fejlődésével a kiberbiztonsági kihívások is növekednek. A WinRAR sebezhetősége egyértelműen rámutat arra, hogy milyen fontos a rendszeres szoftverfrissítések telepítése és a kiberbiztonsági hírek követése. Csak így maradhatunk lépéselőnyben a támadókkal szemben. A kiberbiztonsági incidensek gyakorisága miatt a proaktivitás és a tájékozottság a legújabb fenyegetésekkel kapcsolatban fontosabb mint valaha.

A WinRAR Zero Day Sebezhetőség egy emlékeztető arra, hogy a digitális világban sosem lehetünk elég óvatosak. A kiberbiztonság nem csak a szakemberek feladata, hanem mindannyiunké. Legyünk elővigyázatosak, frissítsünk rendszeresen és legyünk kritikusak az online tartalmakkal szemben. Csak így őrizhetjük meg digitális biztonságunkat. A technológia állandóan fejlődik, és ezért lépést kell tartanunk vele, hogy megvédjük magunkat és értékes adatainkat. Ha segítségre van szükséged vagy támadás ért, fordulj hozzánk bizalommal. Vedd fel velünk a kapcsolatot az info@superiorpentest.com-on, hogy mihamarabb biztosítsd  adataid védelmét.