Beveiligingsonderzoekers vinden negen lekken in Lightify-systeem van Osram

Onderzoekers van beveiligingsbedrijf van Rapid7 hebben negen lekken in 'slimme' Lightify-lampen van Osram gevonden. Het bedrijf heeft inmiddels vijf daarvan weten te dichten. De bijbehorende app sloeg onder andere het wifi-wachtwoord zonder versleuteling op.

Dit lek, met kenmerk cve-2016-5051, maakte het voor een aanvaller mogelijk om het wifi-wachtwoord te achterhalen als hij bijvoorbeeld het apparaat met de geïnstalleerde app in bezit wist te krijgen. Deze kwetsbaarheid in de Home-versie van het product is inmiddels opgelost. Daarnaast kwamen de onderzoekers erachter dat de standaard wpa2-wifiwachtwoorden die door het systeem gebruikt worden zeer zwak zijn, omdat zij alleen bestaan uit de cijfers nul tot en met negen en de letters a tot en met f. Daardoor waren deze in minder dan zes uur te kraken. Dit lek met kenmerk cve-2016-5056 , aanwezig in de Pro-versie, is eveneens opgelost.

De nog niet opgeloste problemen hebben te maken met een gebrek aan ssl pinning en het opnieuw kunnen versturen van commando's via het ZigBee-protocol. Daardoor kan een aanvaller een man-in-the-middle-aanval uitvoeren en verkeer onderscheppen. Ook kan een kwaadwillende zonder authenticatie commando's aan het systeem versturen en daarmee de verlichting verstoren of onderbreken. Andere, wel opgeloste kwetsbaarheden lieten een gebruiker verbinding maken met een kwaadaardig wifi-netwerk en stelden een kwaadwillende in staat om een aanval via de browser uit te voeren via injectie van javascript.

Rapid7 legde midden mei contact met Osram, dat op 21 juli met een update over de voortgang van het ontwikkelen van patches kwam.

Reacties (34)

[SED]

Het feit dat bedrijven security als basis van een ontwerp blijven onderschatten wekt niet veel vertrouwen in IOT toepassingen.
Zelfs de basis, zoals het opslaan van een wachtwoord gaat al fout. Het lijkt erop dat ook hier weer goede afspraken de basis moeten vormen voordat een product op de markt komt. Net zoals electronica aan regels moet voldoen voor een keurmerk zou iets dergelijke voor IOT snel ingevoerd moeten worden.
edit, deze gedachte is verre van nieuw, maar concrete stappen ontbreken.
http://www.zdnet.com/arti...ed-to-secure-iot-devices/

[Reactie gewijzigd door SED op 23 juli 2024 20:56]

[Verwijderd]

Project managers die niets, hélemaal niets, snappen van wat ze managen. Die zien een kost in het uitwerken van een goede architectuur. Liever trekken ze een blik junior developers die van het goedkoopste consultancy bureau komen open. En hij geeft die sakkers dan de opdracht om zo quick en dirty mogelijk zo snel mogelijk de grootste rommel bij elkaar te harken in hun texteditor.

Zodat dat IoT device de deur uit kan met zo weinig mogelijk kosten.

Kwaliteit? Neen. Niets. De meeste van die IoT toepassingen worden zelfs niet deftig getest op normale use-cases. Laat staan op security.

De enige manier om dat op te lossen is zéér zware boetes op te leggen aan bedrijven die niet volgens bepaalde normering hun toestellen beveiligen. Dit kan trouwens perfect. Het is een fabel van de software-development industrie dat dit niet kan.

[TheGhostInc]

Project managers die niets, hélemaal niets, snappen van wat ze managen.

Ik heb nog niet meegemaakt dat een project manager toegang had tot de source repository, dus de code is gewoon geschreven door een programmeur.
Als een (externe) HBO+ professional meer interesse toont in het te vriend houden van een PM dan fatsoenlijk werk leveren, dan zegt dat IMHO meer over de developers dan over de PM.
Maar ik denk dat de verantwoordelijke PM inderdaad nog nooit heeft gehoord van dit probleem, wat heel raar is als daar een team van professionals aan het werk was. Ik zou toch op z'n minst een mailtje verwachten met dit risico erin (en afgetekend door de PM).

Maar het is uiteindelijk hetzelfde als klagen over het voedsel bij McDonalds. Ik heb altijd voor bedrijven/PM's gewerkt die een goede balans tussen kwaliteit en output wilden. Geen 3 sterren restaurant, maar ook geen snelle vette hap.
Maar blijkbaar zijn er in de IT nog teveel mensen die het eigenlijk niks kan interesseren en waarbij 'uurtje factuurtje' of de maandelijkse loonstrook belangrijker is, dan daadwerkelijk iets opleveren (of weglopen!). Dus als je boetes gaat uitdelen, dan verwacht ik ook gewoon boetes voor de ontwikkelaar die het geschreven heeft. Of op z'n minst 'naming and shaming'. Een hartchirurg die in de bezemkast een operatie uitvoert zal ook gewoon voor de tuchtraad komen... ook al was het de taak van de directie om een operatiekamer te regelen.

Dus denk niet dat het allemaal PM's zijn, want voor elke 'klote' PM, heb je een team van ontwikkelaars nodig die daar mee akkoord gaan!

[Verwijderd]

Klinkt allemaal erg utopisch. Maar in de werkelijkheid mag het dan wel zo zijn dat de PM zelden zelf aan de code komt, hij of zij beslist wel vaak of iets belangrijk is of niet (of een Jira ticket wel of niet moet afgehandeld worden, of iets wel of niet moet getest worden, of er wel of niet een code reviews moeten gebeuren, en zo verder). Al genoeg keer meegemaakt dat een security fout zulk lage prioriteit krijgt dat het nooit zal gefixed worden. Heb ik al meegemaakt bij zelfs een fabrikant van routers.

Klopt zeker dat er voor elke 'klote' PM of PO een team van ontwikkelaars nodig is om er mee akkoord te gaan. Maar gelijkgestemden trekken elkaar aan?

De groep ontwikkelaars die nu aan IoT bezig zijn zijn heus niet allemaal erg gemotiveerde mensen. Eerder van die jonge gasten die graag alles in het nieuwste hipster web framework doen. En dan maar coden. Tot en met SQL insert zinnen die ik met de sniffer zag voorbij komen in JSON berichten die van het toestel komen.

Probeerde ik het eens: zelfs SQL injection moest ik niet op testen. Ik kon het berichtje gewoon aanpassen met een DROP TABLE er in. Werkte gewoon om tabelletjes op de server te droppen. Tegenargument dat ik kreeg: "jamaar, niet iedereen kan JSON over plain-text http sniffen he. Jij bent zo'n gevaarlijke hacker. Gewone mensen zien dat niet."

jahallo.

Dat soort volk bouwt dus uw IoT toepassingen.

[TheGhostInc]

of iets wel of niet moet getest worden, of er wel of niet een code reviews moeten gebeuren

NEE! Een PM heeft NIKS te zeggen over code reviews of test protocols.
Je levert namelijk nooit iets op dat niet gereviewed of niet getest is. De lompste fouten worden namelijk gemaakt zodra iemand 'even' nog 'snel' een aanpassing doet.
Het is als die hartchirurg die haast heeft en maar 'EVEN' overslaat om zijn handen te wassen. Dan ben je een amateur en gewoon ongeschikt.

Ik snap prima dat de werkelijkheid soms net iets flexibeler is, bij 3 features testen we soms ook na de oplevering van alle 3, in plaats van 3x afzonderlijk. En een mini aanpassing wordt ook niet altijd gereviewed. Maar als we de 80/20 regel nemen, dan zitten we daar echt wel boven. Meer dan 80% van onze code voldoet aan basale standaarden, is gereviewed, bevat unit tests en is getest op werking. Het aantal brandjes dat wij moeten blussen is dan ook zeer gering.

[Verwijderd]

Ben het daar helemaal mee eens hoor TheGhostInc. Ik beweer enkel dat de werkelijkheid vaak niet zo Utopisch is. Maar wees gelukkig dat je huidige opdrachtgever je toe laat correct te werken.

Mijn huidige valt in die zin ook goed mee. Maar ik heb zeker al extreme waanzin meegemaakt.

[SuperDre]

Uhhh, het lijkt er op dat jij nog nooit echt in veel verschillende teams hebt gewerkt. Vaak is het dat jij als developer goed werk wilt afleveren, maar zegt de manager 'ik wil het gister afhebben, dus laat bv documentatie maar achterwege en begin maar meteen met ontwikkelen.'. Dan kun je de gevolgen nog zo hard uitleggen, ze luisteren toch niet.

[TheGhostInc]

Ik heb in een redelijke collectie teams gewerkt, wel echter allemaal grootzakelijk, dus niet in de technische automatisering. Die jongens lopen wel een jaartje of 10 achter normaal gesproken.

Maar al mijn teams/projecten waren volledig Agile, minimaal CI, maar vaak richting CD. Compleet met automatische code coverage en stijl checks etc.
Daar een 'dirty' fix doorheen rammen om tijd te winnen kost vaak 3x meer tijd met allerlei alarmbellen die afgaan. Gewoon netjes het proces volgen is veel makkelijker en sneller.

Geen haar op mijn hoofd die denkt aan een opdracht/team waarbij 'ze maar wat doen', omdat je dan inderdaad een PM hebt die dictator kan gaan spelen en dat waarschijnlijk ook doet.
Agile en andere 'hulpmiddelen' zijn als de valbeveiliging voor iemand die op hoogte werkt... het zorgt ervoor dat je werk leuk blijft en geen 'dead trap'.

[catfish]

Je geeft het probleem zelf al aan: er is helemaal geen "bepaalde normering".
Ik vind ook niet dat je alles in de schoenen van de project manager mag duwen. Er zijn gewoon geen managers die op de hoogte zijn van "alles".

De IT bedrijven waar ik mee te maken heb leveren vaak rommel software af (bugs, bugs, bugs) en stellen daar zelf geen vragen over. Soms denk ik zelf dat ze het expres doen: dat houdt hun service contract levendig (wat je zit toch vast).

[Verwijderd]

Zelfde ervaring. Maar het zijn wel ook die bedrijven (en project managers) die de IoT toestelletjes van morgen zullen maken. Wij die er ons wel iets van zouden aantrekken, niet.

Wij zijn met (veel) te weinig en we hebben het in onze vrije tijd al veel te druk met opensource dingen te bouwen en die op github te publiceren. Dingen die dan over tien jaar door de industrie massaal gekopieerd zullen worden, net zoals dat wat we tien jaar geleden maakten.

Ik wil wel de schuld in iemand anders dan de project manager duwen. Maar wie dan wel? De aandeelhouder? De CTO? De CEO? De programmeurs toch niet?

Dat zijn meestal juniors van 20 jaar die nog maar net geleerd hebben hello world te programmeren. Logisch dat die de éne fout na de andere maken. En zelfs met zéér veel ervaring maken veel programmeurs nog steeds behoorlijk veel security fouten. Goede en vooral strenge code reviews, goede bug tracking, een open geest naar de security community (die je toestel ook helemaal zullen uitproberen), snel en eerlijk reageren op security fouten, updates uitbrengen en uw programmeurs continue wijzen op en blijven opleiden in de typische security fouten. En dan zal je er nog massa's hebben.

Maar dat is totaal niet wat ik zie (ben freelancer, heb al meerdere IoT-achtige projecten gedaan). Eerder het volledige tegendeel. Dat ligt bijna altijd aan de project manager die de druk van het management niet aan kan en dan maar overal shortcuts neemt.

[Verwijderd]

Altijd dat roepen naar keurmerken. De beste marktregulering is de consument. Geef het een paar jaar en er komen vanzelf partijen die dit gaan controleren en de consumenten gaan voorlichten. De consument zal de prutsers keihard afstraffen.

The consumers patronize those shops in which they can buy what they want at the cheapest price. Their buying and their abstention from buying decides who should own and run the plants and the farms. They make poor people rich and rich people poor. They determine precisely what should be produced, in what quality, and in what quantities. They are merciless bosses, full of whims and fancies, changeable and unpredictable. For them nothing counts other than their own satisfaction. They do not care a whit for past merit and vested interests. If something is offered to them that they like better or that is cheaper, they desert their old purveyors. In their capacity as buyers and consumers they are hard-hearted and callous, without consideration for other people.

Dit is overigens precies de reden dat ik al die ‘slimme’ zaken niet in mijn huis wil. Zeker niet omdat er weinig mogelijkheden zijn tot updates en als zo’n leverancier bijvoorbeeldl gebruik maakte van OpenSSL (wat vrij logisch is), dan zat je toch ineens met een onveilig ‘slim’ apparaat.

[Verwijderd]

De consument snapt niets van security. Hoe kan die dan een intelligente keuze maken? Zelfs een consumentenorganisatie zoals bv. Test Aankoop slaat de bal volledig mis. Security betekent er "mooie plaatjes op de Web UI".

Ga eens lost met de UNIX tool strings op de binaries van bijna alle consumentenrouters. Je zal nogal verschieten wat je aan hardcoded passwords tegenkomt. De meeste consumentenrouters zijn dan ook rommel. Nochtans bestaan consumentenrouters al meer dan tien jaar. De consument straft de prutsers dus niet af.

[Verwijderd]

Eens, maar blijkbaar is het geen probleem voor de consument. Consumenten kopen ook goedkope Android telefoons, die nooit een update zullen krijgen. Ik vind dat ook dom, maar blijkbaar is het geen probleem omdat ze er geen last van hebben. En om dit te gaan verbieden lijkt mij geen goede optie. Consumenten kochten ook een Windows XP PC die zonder SP2 al binnen een minuut nadat ie online kwam besmet was met een virus. Maar door de hoeveelheid klachten heeft MS er alles aangedaan om dit zo goed mogelijk op te lossen.

Op het moment dat er een x aantal mensen met hun onveilige Android een keer tegen een lege bankrekening aan zitten te kijken, reken maar dat dat afgestraft wordt. Tot die tijd, who cares of zijn contacten worden uitgelezen.

En zo is het ook met dit soort dingen. IoT koelkast onveilig? Ze hebben bij me ingebroken, ze wisten dat ik niet thuis was, want mijn koelkast was al drie dagen niet opengeweest. Na een goed krantenartikel zet iedereen die onzin uit.

[dj__jg]

Het probleem is dat het niet altijd alleen de consument is die er last van heeft dat zijn iot device onbeveiligd is. Als een rus een flinke lading koelkasten heeft gehackt en ze vervolgens gebruikt in een ddos aanval hebben daar veel mensen last van, maar niet de gebruiker van de koelkast. Die merkt alleen dat z'n netflix wat trager wordt.

Daar komt nog bij dat de gemiddelde consument niet het overzicht en de merkenkennis heeft om bepaalde bedrijven met slechte beveiliging te ontwijken. Als je daar bij ieder koffiezetapparaat en CV ketel onderzoek over moet doen haakt de gemiddelde consument al snel af. Dan zou een goed keurmerk dus een uitkomst kunnen bieden.

[Verwijderd]

Probleem is vooral dat heel wat IoT toepassingen levensgevaarlijk gaan zijn.

Het electrisch kookfornuis kan brand veroorzaken. Je wil niet dat een nigeriaanse prins duizenden kilometers verder er mee kan spelen. Zeker niet als je kinderen in de kamer er boven aan het slapen zijn.

Uw auto kan een aanrijding veroorzaken. Er zijn al heel wat publicaties over auto's die waarop via de wifi van de autoradio op ingebroken is en de inbreker de CAN bus kan schrijven. Dat wil zeggen sturen, remmen en gas geven. Zonder dat je als bestuurder al te veel kan ingrijpen op een veilige manier. Je wil niet dat een nigeriaanse prins dat kan. Zeker niet als je kinderen op de achterbank aan het slapen zijn.

ps. Een koelkast kan eten doen bederven. Dat kan dus ook gevaarlijk worden.

[mxcreep]

Blijkbaar is het geen probleem voor de consument ? Gelukkig geef je zelf ook al aan dat dat vanzelf verandert...

De consument lijkt het idd allemaal prima te vinden... Maar die laat zich dag in dag uit meer en meer verleiden door marketing die ze allerlei onnodige rommel aansmeren. Meer en meer dingen in je leven beginnen gevoelig te worden voor security issues en op een gegeven moment ben je gewoon de bok, dan is er toch een issue wat meer impact heeft dan je ooit had gedacht en je zag het als domme consument niet aankomen.

IOT is heel mooi voor sommige dingen maar bepaalde voorbeelden slaan voor mijn gevoel gewoon volledig door... Mijn koelkast hoeft niet aan internet, mijn huidige is niet hackbaar behalve door inbreken in huis en de koelkast deur open te trekken, probeer je dat dan wordt je door mijn hond waarschijnlijk opgegeten. Persoonlijk vind ik ook de appjes om je auto remote te bedienen daar onder vallen, je maakt jezelf zo gewoon kwetsbaar voor problemen. Verder is het zo dat hoe groter de hype is des te meer mensen er aan gaan werken, dus ook meer pruts software gaan produceren. Dat bij elkaar gaat ervoor zorgen dat je heel kwetsbaar wordt, kwaadwillenden met een beetje technische kennis kunnen straks je leven beinvloeden, om overheden nog maar niet uit te vlakken.

Dus wat mij betreft hebben deze technieken altijd twee kanten, heel mooi dat het kan en voor bepaalde situaties een geweldige aanvulling, maar zoals alles wordt het gebruikt door marketing gedreven bedrijven die niks nuttigs maken maar je alleen rommel willen verkopen en hun zakken vullen.

[Reactie gewijzigd door mxcreep op 23 juli 2024 20:56]

[Verwijderd]

De consument snapt niets van security.

En dan nog... moet ik elke week checken of er een software update is voor mijn smart koelkast? Vrijwel niemand update zijn router nadat ie in de meterkast is gehangen terwijl we allemaal weten (!) dat daar zeer veel mee mis kan gaan. Miljoenen mensen lopen met een Android telefoon rond waarbij de software verouderd en onveilig is (en niet geupodate kan worden)

Van beveiliging en IoT moeten we ons allemaal niet teveel voorstellen. Het is bijna een contradictie. In de toekomst denk ik dat we er vanuit gaan dat onze persoonlijke netwerken gecompromitteerd zijn en dat we onze meest kwetsbare data alleen op een encrypte wijze daarop opslaan.

[Verwijderd]

Ik verwacht een beetje het model dat bv. een Telenet in België gebruikt: die digitale TV setup box zit gewoon in een VLAN op je Telenet router zo ver ik weet.

Die Telenet router zet dat die digicorder blijkbaar automatisch in een VLAN. Uw andere toestellen op je Telenet thuis netwerkje kunnen er standaard niet aan. Al valt dat vermoedelijk te omzeilen met wat MAC adres spoofing (nog niet geprobeerd). Je kan die digicorder bv. ook niet zelf een IP adres uitdelen met dhcp op een eigen routertje. Ik geloof dat het systeem van Soft@Home ook zo werkt.

Ik verwacht van mijn IoT garagepoort (als ik het ooit zou kopen, wat een grote als is) dat het ook in een VLAN gezet wordt. Dus zou het niet slecht zijn dat routers dat standaard ook gaan doen.

En als een toestel dan wil praten met een ander toestel, dan zou die router het de consument gemakkelijk moeten maken om die twee dingen in eenzelfde VLAN te zetten. Liefst zonder dat ze een Cisco cursus eerst moeten volgen. Iets met pijltjes, icoontjes en plaatjes en zo veel mogelijk detecteren. Dat de TV zoekt naar de Playstation kunnen we vaak op de router detecteren. Laat aan de gebruiker zien dat de TV dat geprobeerd heeft en vraag of dat toegelaten is of niet. Zo ja: TV en Playstation in dezelfde VLAN. Anders niet.

Ma goed. Eerst al eens al die mottige consumentenrouters veilig krijgen. Iedereen die dit leest: vervang alvast al maar uw consumentenrouter z'n firmware met DD-WRT. Want standaard is het vrijwel bij iedere fabrikant dikke rotzooi die stampe vol security fouten zit.

[mxcreep]

De reden dat mensen er weinig van merken is meer omdat ze geen interessant target zijn dan omdat het niet mogelijk is. Hoe meer er van dit soort toepassingen komen des te meer informatie is er te verzamelen waardoor het wel interessant kan worden. Tevens zal de vorm van criminaliteit waar we het hier over hebben ook steeds meer doordruppelen naar personen die al met minder buit blij zijn. En vergeet niet dat door de hoeveelheid informatie stromen en devices enorm te vergroten het ook moeilijker gaat worden om mensen die kwaad doen op te pakken.

Dat is nu al een issue... Zelfs gevallen van online fraude waarbij men een ideal account heeft, waarvan je zou denken dat het herleidbaar moet zijn naar personen, lukt het oom agent niet om er een zaak van te maken.

Je kunt je straks helemaal suf hacken zolang je van bepaalde targets afblijft, de grotere jongens die ook banden hebben met politiek etc. De rest zal amper tot geen tijd in gestoken worden door justitie. Beter kun je dus als consument aka potentieel slachtoffer maar zorgen dat je niet teveel onzin in huis haalt waar je kwetsbaar van wordt.

[SED]

Altijd dat roepen naar keurmerken.

Kijk, je begint het probleem te begrijpen. Helaas inderdaad dat men om keurmerken of beter normering weergegeven in een keurmerk moet vragen.
Eigenlijk zouden zaken vooraf geregeld moeten worden. Als je kijkt naar de wijze waarop fabrikanten omgaan met hun security ( je haalde XP aan, maar kijk eens naar de voorgangers van Apple's OSX, brrrr eng gewoon zo onveilig) vraagt om regulering. Minimum eisen die iedereen dient te onderschrijven.

[skatebiker]

Daarnaast kwamen de onderzoekers erachter dat de standaard wpa2-wifiwachtwoorden die door het systeem gebruikt worden zeer zwak zijn, omdat zij alleen bestaan uit de cijfers nul tot en met negen en de letters a tot en met f.

Hangt ervan af hoeveel hex cijfers het zijn. Als het er 6 zijn is het zeer onveilig maar niet als het er twintig zijn.
Een 8 tekens wachtwoord met willekeurige (leesbare) tekens heeft 128^8 mogelijkheden en een hexstring van 20 tekens 16^20 mogelijkheden.
En 16^14 == 128^8 dus meer dan 14 hex cijfers is veiliger dan de vaak aanbevolen 'minimum 8 tekens met cijfers, letters en leestekens'.

Maar een veel ernstiger punt is dat dit soort apparaten aan internet hangt wat voor gebruik binnen helemaal niet nodig is.
De trend om alles maar klakkeloos aan internet te hangen (IOT) is geheel in strijd met het streven apparaten veiliger te maken.

[Verwijderd]

Er zit een gat in de markt voor iemand die een eenvoudige router installatie UI of web-ui maakt voor deze ondersteuning in DD-WRT. Is er nergens geen Linux User Group die daar een projectje van kan maken?

Een (web-)UI die een nieuw IoT toestel automatisch detecteert en de gebruiker voorstelt om een nieuwe VLAN aan te maken op z'n router er voor.

Zo kan dat nieuwe IoT toestel alvast niet aan de garagepoort. Want die garagepoort zit in z'n eigen VLAN.

[Eric Oud Ammerveld]

Mogelijk ken je Domoticz nog niet; https://www.domoticz.com/wiki/Synology
Niet de router in dit geval maar de NAS biedt je hier een web interface.
Mogelijk ook te installeren op een DD-WRT installatie.

Overigens heb ik de indruk dat DD-WRT de afgelopen 2 jaar weinig "innovatief" is geweest, maar dat nogmaals; dat is mijn eigen ervaring.

In de regel is alles dat "zend" op de 443 Mhz band met "één richtingsverkeer" redelijk "lek". Zo ook mijn "Klik-Aan Klik-Uit"
De hack is gelukkig enkel op beperkte afstand "inzetbaar" en tegen te gaan door met een honkbalknuppel iedere lolbroek met een 443 Mhz ontvanger in de buurt neer te knuppelen.

[Reactie gewijzigd door Eric Oud Ammerveld op 23 juli 2024 20:56]

[Pepsichoco]

Ik lees dat zo dikwijls over 'lekken' in de beveiliging. Ik ken zelf helemaal niks van programmeren, maar ligt het niet aan de programmeertaal zelf dat daar zoveel fouten in kunnen gebeuren ? Ik herinner me dat toen wij vroeger in basic wat programmeerden (+30j geleden) en je een paswoord moest ingeven, je niet eens de mogelijkheid kreeg om tientallen, honderden of duizenden paswoorden per seconde in te geven. Had je twee keer een fout paswoord, dan werd je er gewoon uitgesmeten, althans, dat deden we zo. Wat we soms deden met die paswoorden, is de tijd die je kreeg om een ander paswoord in te geven telkens verdubbelde als het fout was. Waarom kan dat nu niet meer ? Ik zeg er hier even bij dat ik helemaal niet met mijn tijd mee ben dus als er iemand een antwoord heeft, hou het simpel aub.

[Verwijderd]

Er zijn dingen die aan de programmeertaal liggen. Bv. buffer overflows kunnen veelal vermeden worden door de programmeurs geen APIs aan te bieden die geen boundary checks doen. Maar C en C++ zijn nu éénmaal erg populair en hoewel die talen APIs hebben die wel boundary checks doen, hebben ze ook APIs die dat niet doen. Als je de statistiek bekijkt van meest gebruikte programmeertalen dan zitten C en C++ al tientallen jaren helemaal bovenaan. Vooral in embedded. Dat is dus ook IoT.

Er bestaat onder de programmeurs, vooral de juniors, het (vreemde) idee dat ze iedere lijn code zo performant mogelijk moeten maken en ze vergeten de echte use-case van wat ze maken. Zolang die éne lijn maar extreem performant is. Boundary checks maakt uw code een hééééél klein beetje minder performant. Dus wat zie je? Stoere junior code zonder die checks, maar vol met security fouten. Ligt aan het manneke, en niet aan de programmeertaal.

Ik zag bv. strtok gebruikt worden op een buffer die een functie binnenkomt, zonder dat de programmeur door had dat strtok naar die buffer schrijft. Dus als caller van die functie de buffer verder gebruikt, dan geeft dat onverwachte resultaten die tot een security fout kunnen leiden. Eerst een kopie maken van de buffer en op de kopie strtok doen zou slimmer zijn. Maar ja. Dat is niet zo performant he (dus dwaas, maar ja).

Hogere talen zoals Java, C#, Ruby, Python en zo verder hebben meestal wel uitsluitend APIs met zulke boundary checks (en geen of beperkte toegang tot pointers, bv. met unsafe{} in C#).

De overgrote meerderheid van de security fouten zijn echter luiheid van het manneke en/of gewoon incompetentie. Je hebt er bv. ook altijd die denken dat ze zelf een encryptiealgoritme moeten uitvinden en die zijn er vrijwel altijd de oorzaak van dat dat als eerste gekraakt wordt. Maarja. het Not Invented Here syndroom is zeer belangrijk voor jobzekerheid he.

[Pepsichoco]

Enkel de laatste alinea heb ik begrepen, maar toch bedankt voor je uitleg.

[Verwijderd]

Ik vind het wel knap van Osram dat ze de fouten herstellen. De meeste IoT bouwers trekken het zich nl. letterlijk totaal niet aan dat de rommel die ze enkele maanden eerder in de nek van de consumenten hebben gedraaid zo lek zijn als een zeef.

Vooral niet wanneer dat IoT device op de titel van de doos "secure" heeft. Bv. van die electronische deursloten die erg nuttig zijn voor inbrekers om mee in te breken, of beveiligingscamera's, zijn raar maar waar meestal nu net de IoT producten die écht belachelijk slecht beveiligd zijn.

Langs de andere kant wordt het eens tijd dat er normering van uit Europa komt die kwaliteitseisen opleggen. Bv. zou het verplicht moeten worden dat die IoT rommel geupdate wordt en kan worden en zou het verplicht moeten worden dat fabrikanten binnen de x dagen een gevonden lek herstellen in een update. Zo niet: zware EU boetes, tot de CEO en alle aandeelhouders al hun geld kwijt zijn.

Doen we dat niet: verwacht een totale security-chaos wanneer die IoT gekte uitbreekt. Één waar uiteindelijk de nu al onderbemande politiediensten en dus de belastingbetaler voor moet opdraaien. Start al maar een extra politiekantoor enkel en alleen om de massa's gedupeerden op te vangen die malware op hun dure IoT toestelletjes hebben staan. Want de kwaliteit van de code die ik zie: oh mijn god. oh wow. oh mijn god mijn god. Slecht slecht slecht.

[Verwijderd]

Ik vind het wel knap van Osram dat ze de fouten herstellen.

Hoe vaak per week check jij of je LED lampen een software update nodig hebben?

[Verwijderd]

Moesten die IoT fabrikanten nu gewoon netjes RPM of DEB gebruiken, en dan in een crontabje "apt-get update && apt-get upgrade" en dan uiteraard enkel hun eigen repositories instellen in de sources file, zodat fouten bij upstream Debian of RedHat niet leiden tot defecte toestellen. Of gebruik anders deze officiele handleiding van Debian om precies dat te doen met standaard apt infrastructuur.

Of ook goed: de public key van het account van de fabrikant op de toestelletjes hun authorized_keys registreren en dan doet de fabrikant voor ieder toestel in the field: ssh [e-mail] "apt-get update && apt-get upgrade"

Zo heb ik het in ieder geval opgezet bij een bedrijf dat signalling en display schermen bouwt voor een aantal ziekenhuizen en andere plaatsen. Dat kastje er achter update gewoon zichzelf. Verder worden die toestelletjes volledig unattended geïnstalleerd en als je iets bepaald doet met de MBR dan installeren ze zich over het netwerk helemaal volautomatisch opnieuw a.d.h.v hoe de server van de fabrikant het wil.

Oh en met DebDelta packages doen we dat ook over low-bandwidth zoals 3G connecties. Dat zijn namelijk binaire diff packages.

Dus is zo'n toestelletje gehacked: dan moeten ze die en die buttons tien seconden inhouden en even later is alles opnieuw geïnstalleerd en upgrade het zichzelf terug.

Was echt niet moeilijk om dat op te zetten met standaard Debian (in dit geval) zaken. Ongeveer weekje werk voor één developer.

Maarja. Het Not Invented Here syndroom lurkt ook hier weer. Ik wed er op dat iedere developer bij iedere IoT fabrikant vindt dat hij of zij dat helemaal zelf moet heruitvinden. En dan zal die unattended-installatie en upgrade infrastructuur inderdaad zelf vol security fouten zitten.

[SavageX]

Bij de phillips HUE app krijg je b.v een notificatie

[Neo_TGP]

Het boek "The industries of the future" (https://www.bol.com/nl/p/...-future/9200000052006346/ )gaat ook een stuk in op de toepassing van het IOT gebeuren, alleen dan dus vanuit de optiek van een (voorheen) hooggeplaatste Amerikaanse politicus. Het is wel grappig om te lezen dat het bewustzijn over veiligheid er eigenlijk wel is, maar niet heel veel partijen zich echt geroepen voelen om daar wat mee te doen.. Het boek heeft overigens ook een aantal andere interessante toekomstvisies over oa. bitcoin.

Ook in dat boek wordt aangehaald dat er vooral gedacht wordt in functionaliteiten en dat beveiliging vaak op de laatste plaats komt. De mogelijke impact daarvan is enorm en toch lijkt niemand er bewust meer bezig te zijn.

Het is dus in ieder geval een stap in de goede richting dat direct een aantal lekken worden aangepakt door Osram, maar eigenlijk hadden ze al niet eens voor mogen komen.. Ik vraag me dan ook echt af of de eindeloos versnellende product lifecycle wel zo'n goede zaak is. Zeker gezien de focus ligt op zaken zo snel mogelijk in productie nemen, ook als het risico bestaat dat er mogelijk nog fouten in het systeem kunnen zitten. Natuurlijk kan je dit risico beperken door goed te testen en goede security scans uit te voeren, maar voor het pushen van een product worden deze stappen nogal snel geschrapt als veiligheid geen absolute core business is..

Liever een product dat een half jaartje langer ontwikkeld is maar dan wel af en veilig dan iets wat gehaast op de markt gebracht is om de concurrentie bij te blijven.

[mutley69]

Osram patcht tenminste - er zijn bedrijven die gewoon doorgaan in de boosheid en niks fixen. U als consument is dan dik gezien.

[SavageX]

Hoe zit het met Phillips HUE lampen? Die gebruiken ook het zigbee protocol toch?
Aangezien Phillips al niet zo lekker gaat qua software maak ik me nu wel zorgen...