Lampehack understreger hvorfor du skal dele dit netværk op

7. februar 2020 kl. 05:0937
Lampehack understreger hvorfor du skal dele dit netværk op
Illustration: Philips.
Hackeren, der opdagede sikkerhedshul i smart-pære understreger, at Philips investerer tungt i sikkerhed. Alligevel var firmaets IoT-lampe kritisk sårbar.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

It-sikkerhedsfirmaet Check Point har netop offentliggjort, at Philips´populære smart-pærer - stadig - kan overtages og deres software bruges til at kompromittere de netværk, pærerne er tilsluttet.

Log ind og læs videre
Du kan læse indholdet og deltage i debatten ved at logge ind eller oprette dig som ny bruger, helt gratis.
37 kommentarer.  Hop til debatten
Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
37
21. februar 2020 kl. 12:28

Ydermere er problemet at mange nye cloud devices kræver at være på samme netværk som fx. den telefon som man bruger til at tilgå devicen fra. Fx. har vi en Bosch tørretumbler med Wifi - den insisterer på at være på samme netværk under opsætningen.

Men til gengæld er det kun 2-3 klik på mobilen at skifte netværk.

Men høre mobilen til på det "sikre" hjemmenetværk eller det knap så sikre gæste/gaming/iot netværk - Og skal det også deles op.

Så problematikken består. Det bliver hurtigt meget komplekst at segmentere netværket i et privat hjem og endnu værre i en virksomhed.

36
12. februar 2020 kl. 08:37

Har selv en ASUS router med Merlin firmware, men vil jeg sætte VLANs op skal jeg ssh ind og konfigurere firewall med scripts. Ikke noget jeg tror andre i min familie vil kunne gøre eller noget min familie nogensinde vil kunne tilrette hvis jeg blev ramt af en bus.

Så burde du måske købe en bedre router, når du har valgt at købe udstyr der ikke kan forbindes til dit wifi ? Selvom producenterne forbedrer deres produkter, så det bliver nemmere at opdele sit netværk - så kræver det stadigvæk at man køber de nye routere og ikke holder fast i de gamle.

Men som alle skriver - det er ikke nødvendigvis super nemt idag - det afhænger af ens udstyr om det "lige er nemt at lave et gæste wifi" - og det afhænger selvfølgelig igen af at ens udstyr kan køre på wifi, eller at man har købt en ordentlig router, som den jeg nævnte til 400 kr. - hvor det også nemt kan gøres med kablet udstyr.

mht. Hue - så kan jeg se at nogen har slået wifi til (ved at roote hue'en) - da den faktisk har en wifi chip - men softwaren er hardkodet til at bruge kabelforbindelsen, så det vil kræve lidt mere "tinkering" at få det til at du. Mit gæt er at der nok begynder at komme alternative firmware's og andre hacks, der vil enable den slags.. Men jeg ville klart maile phillips - hvis nok gør det og beder om wifi, kunne det jo være de lavede en nyere bridge udgave, hvor wifi var slået til :)

34
11. februar 2020 kl. 15:37

Jeg har ikke nogen hue.

hvorfra ved du så af "Phillips hue bridge kan da forbindes til et wifi hvis man vil.." ? ?

32
8. februar 2020 kl. 12:58

Det er meget fint at man kan alle de ting. Jeg har selv en pfsense router med en stak managed switche og opdelt vores hjemmenetværk i mange segmenter. Det er et stort arbejde som kun nørder gider. Og det er kun nørder der har en router der tillader at rode med VLANs og routning imellem. De fleste har blot den som ISP'en kom med. Nogle få har en Netgear/ASUS/whatever som har lidt flere features og bedre wifi, men ingen af dem tillader VLANs (ellers var jeg ikke gået igang med pfsense).</p>
<p>Vi ved godt hvordan man gør rent teknisk. Det her handler om at finde løsninger for almindelige mennesker.

Det kunne man altså kræve af producenter / leverandører i hver fald her i EU: Fobrugerenheder (type routere, wifi-routere) skal leveres konfigureret med en defaultkonfiguration som minimum omfatter:

  • en sikker port / VLAN / WLAN (WPA2 Enterprise)
  • en børne port / VLAN / WLAN
  • en gæste port / VLAN / WLAN
  • en IOT port / VLAN / WLAN
  • en TV port / VLAN / WLAN
  • en VOIP port / VLAN / WLAN
  • en WAN-port / internet port (tilslutning til internettet)
  • en management VLAN (til service - kan have fysisk port)
  • indbygget firewall
  • DHCP server / DNS server på samtlige segmenter
  • NTP server (som tager tiden fra NTP-pool)
  • RADIUS server (WPA2 enterprise)
  • Der skal være prekonfigurerede regler på firewallen som passer en rimeligt alm. opsætning baseret på kendte porte
  • Reset af routeren nulstiller alle indstillinger til den vedtagne EU-norm og ikke til en helt tom opsætning
  • Det skal være muligt at ændre alle indstillinger efter forgodtbefindende men ikke som en reset til nul
  • fornuftig manual på CD eller SD
  • et "setup SSID" som nedlægges automatisk efter init og kommer igen ved reset

Hvis dette kom fra EU og gjaldt hele EU så ville en stor del af problemet forsvinde - dette skulle gælde alle routere som leveres til alm. forbrugere uanset om de følger med fra ISP eller om de købes privat.

Jeg er klar over at det ser voldsomt ud men det er ikke så stort når det først er indarbejdet - så skal man kun angive et navn og resten kommer som følger: SSID-Sikker: navn-secure - IP-adr. 10.X.Y+1.0/24 - VLAN ID Y+1 SSID-Børn: navn-child - IP-adr. 10.X.Y+2.0/24 - VLAN ID Y+2 SSID-Gæst: navn-guest - IP-adr. 10.X.Y+3.0/24 - VLAN ID Y+3 SSID-IOT: navn-iot - IP-adr. 10.X.Y+4.0/24 - VLAN ID Y+4 SSID-TV: navn-tv - IP-adr. 10.X.Y+5.0/24 - VLAN ID Y+5 SSID-VOIP: navn-voip - IP-adr. 10.X.Y+6/24 VLAN ID Y+6 X og Y vælges random af systemet ved installation Firewallen får disse oplysninger ind som aliaser som så kan bruges af de foruddefinerede regler.

Når setup er færdig får brugeren en PDF med opsætningen, den er relevant hvis noget skal have fast ip-adr.

NB. Det er ikke meget anderledes en detaljeforeskrifter for motorkøretøjer.

31
8. februar 2020 kl. 12:36

Jeg ved ikke hvilken LK IHC kontroller udgave du har men min virker fint på eget net, jeg kan både nå den fra andre segmenter og fra VPN både med App (på iPhone) og med browser.

Min er en version 3 (HW 7.1). På min kan man kun tilgå admin modulet når man er på samme net. Dvs. man skal have en IP på samme subnet ...

De andre funktioner kan fint tilgås andre steder fra (selvom jeg mener det vil være dybt uansvarligt at give adgang til controlleren direkte fra internettet (pga. den gamle java version).

30
8. februar 2020 kl. 11:49

Det er rigtigt at mange "skod producenter" - laver vendor lockin produkter, som kører over deres servere - så de er Man-In-The-Middle.. Men det er ikke et krav for at høre under IOT begrebet - <a href="https://en.wikipedia.org/wiki/Internet_of_things">https://en.wikipedia…;

Det er jo lidt "problematisk" at kalde dem skod-producenter for det er jo det som sælger de her varer til den brede masse: du køber en dims og får en App til den og serverne tager producenten sig af, så kan kunden nå sin dims fra Canada. Alternativet er at dimserne står frit på Internettet hvilket giver om muligt endnu flere sikkerhedsproblemer. Jeg er helt enig med dig i at det er en skod løsning på problemet.

29
8. februar 2020 kl. 11:38

LK's IHC controller tillader kun tilgang til visse funktioner hvis man er på samme netværk (på trods af at den indeholder en embedded Java engine der er tussegammel og som ejeren kun kan opdatere ifbm. firmware updates fra LK)

Jeg ved ikke hvilken LK IHC kontroller udgave du har men min virker fint på eget net, jeg kan både nå den fra andre segmenter og fra VPN både med App (på iPhone) og med browser. Programmering klarer jeg fra en VM som sidder på samme segment som kontrolleren og kun bruges til det. Jeg må nok lige tilføje at jeg kun bruger min LK IHC til lys.

28
8. februar 2020 kl. 11:25

Den bliver ikke hacket.. Men mikrofoner kan "snakkes til" - vha. laser - hvilket vil sige at f.ex. Alexa mm. - kan "snakkes til" via laser - hvis lys kan nå mikrofonen i en direkte linie udefra.

Jeg er ikke helt enig, ikke på den tekniske plan men i den logiske slutning: Det er en hack fordi producenten antager at kun de personer som har "lov" til at tale til enheden som taler til enheden og det antager ejeren også. Dermed er der opbygget en tillid og det er den tillid som kompromitteres - det kan sammenlignes med når man "hackede" telefoner med nummersendere eller ved at banke med gaflen i 1970'erne og 1980'erne, det var også en antagelse om at man ville brugte telefonen som telefonselskabet havde tænkt sig.

Den der danskudviklede hat til Alexa burde i øvrigt forhindre denne fremgangsmåde.

27
8. februar 2020 kl. 10:08

Så du HAR din hue tilsluttet via kabel idag? Hvis du så har en firewall som jeg nævnte (til 400 kr.) - så kan du opdele selvom den er på kabel. Jeg har ikke nogen hue.

26
8. februar 2020 kl. 10:07

Bruger du de faciliteter?

Ja - men som jeg startede med at sige - så tror jeg ikke på at producenterne laver det ikke brugervenligt og tilgængeligt for alle FØR EU indfører noget lovgivning der kræver det.

25
8. februar 2020 kl. 09:15

Det er meget fint med de mange kloge ord om, hvordan man kan/bør opsætte VLANs, segmenter, IP-ranges, MAC-filtre, tunneller, bridges, osv, Men hvordan skal det ske i praksis? Det er da en meget lille minoritet af befolkningen, som har viden og evner til at gøre det. Der er vist behov for en grundlæggende anden tilgang til hele sikkerhedsområdet, hvis det skal nytte noget. Jeg kan ikke lige sige hvordan, men standardisering og simplificering er nok væsentlige elementer heri.

24
7. februar 2020 kl. 23:07

Den bliver ikke hacket.. Men mikrofoner kan "snakkes til"

Er det ikke dybest set blot semantik?

Du påvirker en enhed med et signal, hvad enten det er lyd, lys eller elektrisk.

Når enheden opfører sig på en uhensigtsmæssig måde, som f.eks. ved at få Alexa / Google assistenten / Siri til at låse op før døren for fremmede, kan man så ikke kalde det for et hack?

Du kan også bruge indgangsvinklen til mere traditionelt hacking.

Som f.eks.: Hvad nytter det at du låser dit netværk ned kryptering, VPN og jeg skal gi' dig, hvis man alt hvad der kræves er at du:

Først skyder du med laser fra en bygning i nærheden af dit offer.

Dette trigger Google assistenten / Siri / Alexa til at besøge en ondsindet hjemmeside, som laver en tunnel til offerets netværk.

Du har nu adgang til offerets netværk via tunnelen og kan derefter begynde at lave ravage.

23
7. februar 2020 kl. 20:52

Klaus, kan du ikke lige finde en guide til hvor der står hue bridge har WiFi support? For det er der rigtigt mange der gerne vil vide.https://www.reddit.com/r/Hue/comments/4uezvd/can_i_connect_the_hue_bridge_to_router_wirelessly/

Og hvis ikke du kan finde den guide til mig, så har jeg svært ved at se hvordan almindelige forbrugere skal inddæmme det aktuelle problem med Hue.

Har selv en ASUS router med Merlin firmware, men vil jeg sætte VLANs op skal jeg ssh ind og konfigurere firewall med scripts. Ikke noget jeg tror andre i min familie vil kunne gøre eller noget min familie nogensinde vil kunne tilrette hvis jeg blev ramt af en bus.

Citat: »Det er den åbenlyse, lavthængende frugt. Alle forbruger-routere kan oprette gæste-netværk, og det vil jeg klart anbefale alle, der vil have en hurtig løsning på et problem, vi ikke har set det sidste til,« siger Yaniv Balmas til Version2

22
7. februar 2020 kl. 19:59

Jeg har selv en ubuiquity edgerouter X, og der kan man sætte hver port på sit eget vlan/netværk hvis man vil.

Bruger du de faciliteter?

Det er meget fint at man kan alle de ting. Jeg har selv en pfsense router med en stak managed switche og opdelt vores hjemmenetværk i mange segmenter. Det er et stort arbejde som kun nørder gider. Og det er kun nørder der har en router der tillader at rode med VLANs og routning imellem. De fleste har blot den som ISP'en kom med. Nogle få har en Netgear/ASUS/whatever som har lidt flere features og bedre wifi, men ingen af dem tillader VLANs (ellers var jeg ikke gået igang med pfsense).

Vi ved godt hvordan man gør rent teknisk. Det her handler om at finde løsninger for almindelige mennesker.

21
7. februar 2020 kl. 17:34

Phillips hue bridge kan da forbindes til et wifi hvis man vil.. hvis man laver ethernet opdeling, så har man også flere wifi's (1 SSID per netværk) - og forbinder så til den rette.

hvis den du har kun kan bruge kabel - så skal du jo have en switch - netværksopdeling eller ej - de har da ingen relevans for sagen her?

Jeg har selv en ubuiquity edgerouter X, og der kan man sætte hver port på sit eget vlan/netværk hvis man vil.

20
7. februar 2020 kl. 17:12

Det er rigtigt at de fleste routere kan lave WiFi gæste netværk, men hvad hjælper det når Hue Bridge kræver ethernet kabler forbindelse? Mange IoT enheder kræver kablet forbindelse..

Så skal fru Jensen til at købe en switch og sætte vlan og firewall regler op.

Så alt det artiklen siger man bør gøre kan ikke umiddelbart let lade sig gøre med Hue, så vidt jeg kan gennemskue.

19
7. februar 2020 kl. 16:36

Den bliver ikke hacket.. Men mikrofoner kan "snakkes til" - vha. laser - hvilket vil sige at f.ex. Alexa mm. - kan "snakkes til" via laser - hvis lys kan nå mikrofonen i en direkte linie udefra.

16
7. februar 2020 kl. 14:38

Bortset fra det er en stor del af disse IOT løsninger baseret på servere hos producenten så du kommunikerer med serveren og pæren kommunikerer med serveren. Det er derfor det hedder IOT.

Det er rigtigt at mange "skod producenter" - laver vendor lockin produkter, som kører over deres servere - så de er Man-In-The-Middle.. Men det er ikke et krav for at høre under IOT begrebet - https://en.wikipedia.org/wiki/Internet_of_things

15
7. februar 2020 kl. 14:11

Det handler om at åbne for det som behøves i den retning det behøves.

Jeg tvilver på af flertallet af Philps Hue kunder kan lave advanceret firewall regler

Bortset fra det er en stor del af disse IOT løsninger baseret på servere hos producenten så du kommunikerer med serveren og pæren kommunikerer med serveren. Det er derfor det hedder IOT.

Det tror jeg der er mange producenter det ikke ved, eftersom deres app kræver af kunne se enheden på netværket for af tillade af du kontrollerer den.

12
7. februar 2020 kl. 12:17

De bruger udp broadcasts som alle andre - så kopierer man dem rundt (setting i router/fw) - så burde det du. tcpdump to the rescue.. Jeg har ikke prøvet det :)

Så vidt jeg husker er det mDNS broadcast og jeg rendte ind i nogle mystiske ting med at Android telefoner broadcastede med TTL > 1 mens chromebrowseren på Windows broadcastede med TTL=1. Og så er der en række porte man skal åbne for ud over broadcast.

Chromecast i guest mode er en ganske anden oplevelse end chromecast "native". Pointen er at selv hvis man sidder med tcpdump så er der ting der ikke fungerer fint. Chromecast var bare et eksempel. Vi er langt fra en fornuftig situation på dette område.

11
7. februar 2020 kl. 12:15

mon ikke de fleste er bedre afklaret på at sætte alle devices til autoupdate.

Hvilket er den situation vi er i idag - hvor vi skal stole på at ALLE IOT producenter vi har på vores netværk - rent faktisk vedligeholder deres software.. (og det er ikke situationen idag - heller ikke med noget så udbredt som Android) - der er mange producenter som sælger et produkt og aldrig laver opdateringer til det.

Den situation bliver nok ikke bedre, før vi får nogle produktansvarslove der gælder for IOT produkter - a la https://queue.acm.org/detail.cfm?id=2030258

10
7. februar 2020 kl. 12:12

mon ikke de fleste er bedre afklaret på at sætte alle devices til autoupdate.

9
7. februar 2020 kl. 11:51

Ved du hvad der skal til for at tilgå Chromecast på et andet net? Hvilke porte og hvilken trafik skal der åbnes for?

De bruger udp broadcasts som alle andre - så kopierer man dem rundt (setting i router/fw) - så burde det du. tcpdump to the rescue.. Jeg har ikke prøvet det :)

Men som jeg siger indtil det bliver et krav fra EU - gider udviklere af diverse (chromecast mm.) - ikke lave det nemt/brugervenligt/muligt..

Lige præcis Chromecast KAN køre i Guest mode - og så udstiller chromecast'en sine egne bluetooth klient og wifi Adhoc accesspunkt.. Men så dukker den ikke "bare op" i listen af chromecasts som de gør på samme net.

8
7. februar 2020 kl. 11:40

Der er intet af det, der er særlig brugervenligt - og så medmindre det bliver lovkrav i EU at wifi net skal sikres vha. fornuftig default opsætning i routeren, f.ex. så de enkelte enheder IKKE kan snakke direkte sammen, så sker det ikke og udviklerne vil stadig udnytte broadcasts og kun teste på single-network situationer..

Man kunne "rimelig nemt" udvikle en router - så den var den eneste der modtog broadcasts - og laveden en liste af "services".. (tænker UPNP sikkert kunne bruges ellers må de jo finde på en standard :) - og så lade brugeren vælge nemt hvem der må snakke med hvem..

Uden det - vil vi være afhængige af sikkerheden i den enkelte producenters udstyr, desværre :(

6
7. februar 2020 kl. 11:18

Du kan i f.ex. ubiquity's routere ihvertfald - bridge netværk - hvis der er problemer med at opdele dem i hvert sit net (med hver sin iprange) - på den måde vil udp broadcasts nå frem.. Alternativt kan man i flere produkter lave ip-forward opsætning af specifikke broadcasts (ved ikke hvor generel man kan lave dem). Ubiquty ser ud til at have nogle options, så man kan tilvælge at tillade broadcasts imellem AP'ere (forskellige wifi net): https://help.ubnt.com/hc/en-us/articles/115000166827

Alternativt kan "managed switche" - sættes op til IKKE at tillade at enheder på samme net (VLAN) - kan snakke direkte sammen.. (dvs. dine "service udbydere - printere etc. skal så ligge på et andet netværk så de kan nås igennem firewallen - som du har specificeret at det skal tillades).

Jeg havde faktisk allerede for ~20 år siden - gjort det samme - og så sat min firewall op til at blokere for enheder der forsøgte at tilgå en hvilken som helst port på min firewall - det betød at de enheder der fik virus (og som derfor oftest portscannede alt på nettet inkl. firewallen) - blev blokeret og brugeren kom til supporten og de vidste så hvad der var galt (og i loggen på firewall'en kunne man også se hvem der røg i fælden :)

5
7. februar 2020 kl. 11:07

i skriver i artiklen

It-sikkerhedsfirmaet Check Point har netop offentliggjort, at Philips´populære smart-pærer - stadig - kan overtages og deres software bruges til at kompromittere de netværk, pærerne er tilsluttet.

Men Check Points egen blog som i linker videre til skriver at hullet er lukket

The research was disclosed to Philips and Signify (owner of the Philips Hue brand) in November 2019. Signify confirmed the existence of the vulnerability in their product, and issued a patched firmware version (Firmware 1935144040) which is now available on their site. We recommend users to make sure that their product received the automatic update of this firmware version.

Så hvad mener i helt præcist med - stadig -? - mener i at Firmware 1935144040 der blev frigivet midt i januar ikke lukker hullet alligevel - eller ?

Jeg er dog helt enig i at iot ting skal på eget netværk med begrænset adgang.

4
7. februar 2020 kl. 10:17

Jeg smed knægtens gaming PC på et separat netværk inden han fik lov at installere alle mulige Minecraft mods. Det var en god ide for i løbet af et par uger opdagede jeg at der var forsøg på at probe vores netværk udefra. Eller nærmere: Der var forsøg på at probe lige præcist det netværk gaming PC'en sad på.

Det er således ikke nok blot at have et guest netværk ... der er endnu flere klasser af devices. Ydermere er problemet at mange nye cloud devices kræver at være på samme netværk som fx. den telefon som man bruger til at tilgå devicen fra. Fx. har vi en Bosch tørretumbler med Wifi - den insisterer på at være på samme netværk under opsætningen.

Ikea's trådløse gateway til stikkontakter, el-persienner og el-pærer er også gladest for at være på samme netværk. LK's IHC controller tillader kun tilgang til visse funktioner hvis man er på samme netværk (på trods af at den indeholder en embedded Java engine der er tussegammel og som ejeren kun kan opdatere ifbm. firmware updates fra LK). Listen fortsætter ... det er ikke nemt.

Vi har brug for at standardisere dette område sådan at folk ikke selv skal finde på firewall regler og mystisk mDNS og NAT regler. Jeg tror også vi har brug for at kunne afgrænse hvilke dele af internettet IoT devices har adgang til. Det må være muligt for en producent af IoT devices i samarbejde med en cloud-provider at levere en liste af "IP'er" som dimsen tilgår. Så kunne router-firewallen passende blokere alle andre for netop dette device. På den måde bliver IoT'er meget mindre farlige på det store plan.

Læg oveni at man sjældent vil have mulighed for at identificere en IoT som er inficeret. Sådan en dims kan sidde i årevis og sprede malware. Med en klog implementation af malware vil offeret ikke opdage at malwaren på hans computer, TV, printer ikke kommer direkte fra internettet men fra den El-pærer, Blu-ray afspiller, tørretumbler, etc. han ikke har skænket en tanke i årevis.

[Ja, jeg ved godt man ikke har brug for at tørretumbleren er på Wifi]

3
7. februar 2020 kl. 10:13

Det er vigtigt at nævne at hullet i ZigBee bruges til at udnytte et hul i basestationens software, og derved installere malware på denne.

Det kunne så være interresant at se om andre basestationer, IKEA Trådfri, Phoscon osv også er følsomme over for denne sårbarhed.

For at citere en ven; S'et i IOT står for sikkerhed.

(Og nu skal jeg hjem og oprette VLANs)

1
7. februar 2020 kl. 09:58

Men hvis min mobil er på en netværksdel, hvordan kan den så skifte farve på en pærer der er på en anden netværksdel ?