Dit heeft er ook wel mee te maken dat veel van die kwetsbaarheden uiterst theoretisch zijn, en dat "onderzoekers" zelf
bepalen of iets "critical" is en er mee gaan lopen wapperen. De maker van de spullen kan zich meestal helemaal niet
verdedigen, en moet dan ook maar het door de onderzoeker vastgestelde tijdschema voor antwoorden en oplossen
gaan volgen, op eigen kosten ook nog.

Ik kan me wel voorstellen dat er partijen zijn die dat soort gezeur gewoon negeren. Als je als low-budget apparatuur
fabrikant ook nog eens door de hoepels moet gaan springen van iedereen die zich "onderzoeker" noemt dan blijft er
natuurlijk geen business case over.

Daar zouden "onderzoekers" wel eens wat meer rekening mee kunnen houden bij hun gedram.

Rekening houden...? Het hele punt van wat ze doen is gedram vanaf hun morele oh-zo-hoogstaande wij-weten-het-beter sokkel. Een beetje rekening houden met de fabrikant, kom nou zeg.

Of tenminste, sommige "onderzoekers" gedragen zich zo.

De waarheid ligt meestal ergens in het midden. De manier waarop "onderzoek" gedaan wordt is pietluttig en vermoeiend. Tegelijkertijd zijn teveel fabrikanten teveel met "it compiles? ship it!" bezig dan met iets neerzetten dat niet bij de eerste zucht tegenwind omvalt.

Als de "business case" zo zwak is dat zelfs het kleinste beetje aandacht aan security al teveel is, nou, dan breng je dus eigenlijk te goedkope rommel op de markt. Als dat niet door de markt zelf opgelost kan worden (mensen die geen zin meer hebben in rommel die voortdurend lek is), dan is regulering mischien een optie.

Begrijp me goed, ik heb het hier niet over echte vulnerabilities zoals systemen die in default configuratie gewoon vanaf
internet kunnen worden aangevallen, maar over het steeds pietluttiger wordend gezeur over "vulnerabilities" die je alleen
maar kunt uitbuiten als je al op het lokale netwerk zit of als je een "man in the middle" kunt zijn tussen een gebruiker van
de apparatuur en de service waar hij gebruik van maakt.
Of over truukjes waarmee je hier of daar een bitje kunt lezen wat dan wellicht onderdeel kan zijn van een of andere beveiliging.

Die "onderzoekers" zouden zich bezig moeten houden met echte problemen, niet met problemen in een steeds verder
verschuivend kader van onwaarschijnlijke aanvallen.

Als je een fiets hebt (laten we niet meteen weer een auto als voorbeeld nemen) waarbij het vaak voorkomt dat de
remkabels breken of de voorvork breekt dan wil je daar wellicht wat aandacht voor van de fabrikant.
Maar zo langzaam aan zijn die "onderzoekers" meer van het kaliber "als je een zak punaises op straat gooit en je
krijgt een fietser zo ver dat die daar door heen rijdt dan kan die wellicht een lekke band oplopen" en gaan dan ook
nog eens zeiken als Gazelle niet meteen reageert op hun mail daarover met een compleet plan van wat ze er op hun
kosten aan gaan doen om alle klanten te verlossen van deze afgrijselijke kwetsbaarheid.

Dat moet maar eens een keer stoppen. En het totaal negeren van die "onderzoekers" in dat soort zaken kan daar een
goede stap voor zijn, want als ze nergens meer gehoor krijgen en overal als zielepoten worden neergezet (wat ook zou
gebeuren met degene die waarschuwt voor punaises) dan zou het wel weer naar een wat redelijker nivo terug zakken.

En daar hebben wij als consumenten een groot belang bij, want als alles op IT gebied voortaan moet voldoen aan de
door de "onderzoekers" gedefinieerde normen dan zal dat ons uiteindelijk op flinke kosten jagen!

Waarom heb ik meer vertrouwen in de kwaliteiten van de security-specialisten van Heise (en o.a. van de gerenommeerde computerbladen c't en iX) dan een anonieme troll op security.nl? Noch jij, noch ik weet precies wat er aan de hand is.

Pure speculatie, maar uit het artikel en https://www.reddit.com/r/sysadmin/comments/f08h2b/big_security_flaw_discovered_in_yealink_voip/ maak ik op dat als de telefoons vanaf een externe/cloud provider geprovisioned worden (download van configuratie en wellicht firmware updates), aanvallen denkbaar zijn. Waar de kwetsbaarbeid precies uit bestaat weet ik niet, maar hardcoded credentials en/of transport via https zonder certificaat-check of transport via http zouden mij niet verbazen). Nogmaals, pure speculatie.

Ga eens met een Windows beheerder van de universiteit Maastricht praten; hun 287 versleutelde servers waren ook niet direct vanaf internet benaderbaar. Of vraag aan de bestuurders van UM wat ze met de verspilde ca. 1 miljoen euro aan zinvoller dingen hadden kunnen doen.

Hun werkstations waren SLECHT GECONFIGUREERD.
Zoals ik al zovaak verteld heb hier, zorg ter toch voor dat je Software Restriction / AppLocker policies op orde zijn!
Zorg dat je gebruikers geen executables kunnen uitvoeren in directories waar ze schrijfrechten hebben!
Of in ieder geval niet in %TEMP% en de Download directory.
Maar nee, daar willen de beheerders niet aan. Nou dan moeten ze maar voelen!

Dit heeft overigens niets met vulnerabilities te maken, want met een dergelijke payload en zonder die policies kunnen ze
al beginnen met schade aan te richten zonder enige vulnerability.

Ben je soms vertegenwoordiger/spokesman van de producent van deze of gene vergelijkbare meuk? Je springt wel erg opzichtig in de bres met je gedram.
Het ligt zeker meer in je straatje, in je business model, dat de fabrikant van notabene kostbare grondstoffen verspillende troep zijn eigen rottend vlees keurt met vlag en wimpel en bij voorkeur het alleenrecht heeft 'ermee gaan lopen wapperen' nietwaar?

Rekening houden met de belangen van de argeloze consument zou gedram van je kant kunnen zijn die wèl waardevol is. Daar zou je de rest van het weekend weleens dieper over mogen nadenken.

Zelfs een paar bitjes kan genoeg zijn om een geheime sleutel voldoende los te weken dat de rest wel per brute force lukt.

Ik heb eigenlijk niet opgelet over wat er hier in detail aangekaart wordt. (En nu ik ook werkelijk de linkjes bekeken heb, heb ik spijt en wil ik m'n tijd terug: Er staat heel weinig concreets in.) Interessanter is de motivatie. Zo'n onderzoeker gaat op zoek naar "problemen", niet naar of ze echt zijn of niet, en als ze wat vinden hangen ze dat aan de grote klok want zo genereer je publiciteit voor jezelf. "Publish or perish" geldt helemaal als je inkomen afhankelijk is van in andermans code mogen wroeten.

Nou, dat er gaten zitten in functionaliteit die niet elke jandoedel zo zal tegenkomen wil niet zeggen dat het geen groot gat is. Als je door een provisiefunctie iemand z'n VoIP-credentials kan ontfutselen en er vervolgens klassieke telefoonfraude met Hele Dure betaalnummers bellen mee kan plegen, gaat dat de afnemers van de VoIP-dienst nog steeds een hoop geld kosten.

Ik ben wel met je eens dat het soms teveel ophemelen van hopeloos gepietlut is. Of gewoon botweg teveel paniekzaaien en herrietrappen en "wolf"-roepen en brandklok luiden, ook al is het een serieus probleem. Tegelijkertijd kun je niet zomaar zeggen "hou op daarmee". Dit is al jaren een serieus probleem in de security-"biz". Het helpt ook niet dat er ook echt veel charlatans rondlopen die "oplossingen" verkopen die helemaal niets oplossen, ook wel genoemd "snake oil".

Dat weet ik niet. Ik denk het niet. Daar komt de opmerking dat de spullen nu te goedkoop zijn vandaan: Security kost geld en als je er niets aan doet dan kost je eindproduct in directe kostprijs mischien minder. Maar in nevenschade wellicht juist heel veel meer.

In je fietsanalogie, stel je koopt bandjes van de action van vijf euro, en terwijl je lekker een heuveltje afkart slijten je nieuwe bandjes zo hard dat ze spontaan vlam vatten. Je schrikt, komt onder een bus terecht, en ligt drie weken in het ziekenhuis met wat botbreuken en wat er zo nog meer misgaat. Had je dan niet liever bandjes van 15 euro van de fietsenmaker gekocht?

Dat zie je met ransomware: De software die toestaat dat de ransomware vat krijgt op je bedrijf kost een zekere hoeveelheid aan licenties, maar wat als ze door security het dubbele zou kosten maar de kans dat je door ransomware getroffen wordt zakt er met 99% van? Dat lijkt me een goede uitruil.

Nu is die *kuch* zekere software *kuch* wat mij betreft volstrekt niet repareerbaar en ben je beter af met software van bijna om het even welke andere leverancier. Want ook al is elke andere software ook niet perfect, dan toch zeker minder imperfect. Maar dit terzijde. Het gaat om het gedachtenexperiment: Stel dat het kan. Stel dat een simpele prijsverhoging een directe verlaging van vatbaarheid voor ransomware oplevert. Hoeveel minder vatbaarheid wil je minimaal terug voor dubbele prijs? 20%? 50%? 80%? Wat is redelijk?

Dan is er nog het probleem dat je niet vantevoren weet hoe hard het mis zal gaan, je moet op reputatie en "gevoel" zulke beslissingen nemen. En zeker in het softwarewereldje hebben de beslissers nogal vaak geen enkel idee over wat ze nou eigenlijk beslissen laat staan wat dat voor secundaire en verdere afgeleide effecten gaat hebben. Dus is het geen recht-toe-recht-aan afweging. Het is duistere materie voor de beslissende hooguit-eenoogjes. Dus worden zulke aspecten gewoon niet meegenomen. Voorzover dat sowieso een optie was. Vaak genoeg speelt politiek een grotere rol dan technische merites, laat staan de security-aspecten.


Daarnaast, we hebben nu al dat sommige fabrikanten liever alle meldingen van problemen negeren. Dat zie je wel terug in het stuk van heise: Dat het weken kostte om ook maar enige reactie los te krijgen. Als je het goed doet heb je een security@ of desnoods abuse@ en daar zit iemand die zorgt dat de relevante poppetjes ernaar kijken en die kunnen dan met een inhoudelijk commentaar komen. In die zin is het terecht dat er aan de bel getrokken wordt.

Je ziet ook regelmatig dat je wel commentaar komt maar dat is vooral bagatelliseren, en ook dat mag aan de kaak gesteld worden. Elke melding behoort inhoudelijk en eerlijk bekeken te worden. Dit is nog steeds verdomde moeilijk voor veel fabrikanten.

Een van de redenen dat "Unix"* enorm populair werd, was de uitgebreide maar vooral no-nonsense eerlijke documentatie. Manpages die eerlijk waren dat de software niet helemaal perfect was, zelfs met een "BUGS" sectie? Onbestaanbaar voor PR en andere corporate idioterie. Zelfs grootbedrijven als microsoft en oracle brengen dan wel patches uit, maar liefst in grote batches tegelijk en met heel veel wollige woorden die je uiteindelijk lekker toch niet vertellen wat er precies mis was en wat ze er aan gedaan hebben. Nog steeds.

Ik ben wel met je eens dat er hier iets scheef zit. Maar ik denk niet dat het probleem puur bij de "onderzoekers" ligt. Ik denk eerder dat de fabrikanten hier steken hebben laten vallen (soms moedwillig, soms uit pure onkunde, of misplaatste PR-zorgen, en zo verder) en dat er opgeschoten knulletjes ingesprongen zijn. Die nooit volwassen zijn geworden en de cottage-industrie die er uit ontstaan is ook niet. Het zijn in feite "s'kidies" (met net genoeg extra vaardigheid om s'kiddie-voer te produceren) en zo gedragen ze zich ook.

Hoe dit op te lossen? Geen idee, anders dan "wordt toch eens volwassen" te roepen tegen zowel fabrikanten als "onderzoekers". Of mischien iets met een grassroots-campagne om security-aspecten verstandig te kunnen afwegen, ook al zie ik zo snel niet hoe zoiets eruitziet zonder een gedegen IT-opleiding, meer gedegen zelfs dan je op de gemiddelde moderne universiteit kan krijgen. Problemen of boodschappers negeren is denk ik toch net een minder verstandige aanpak.


* En ik bedoel niet "linux", die doet dat een stuk slechter, gek genoeg, maar nog steeds beter dan de meeste commerciële softwareleveranciers.

Nou, erg informatief is heise in dezen niet, terwijl informeren toch hun kernzaak is.

Beetje flauw om gelijk "troll" te roepen, Erik, want hij stipt wel zaken aan die aandacht behoeven. Ook al ben ik het met z'n conclusies niet eens, zie andere bijdrage.

Dit hier. Dit. Dit is het probleem. Ze geven geen informatie, je moet speculeren. Ze schreeuwen dat het heel erg is maar wat er dan zo erg is vertellen ze niet. Je moet maar geloven dat wat er is ook erg is. Dat is "onderdeel zijn van het probleem", niet "onderdeel van de oplossing".

Aan de bestuurders vragen? Die hebben geen idee. Terwijl het vrij voor de hand ligt: Zichzelf van de systemen losweken waarvan we ondertussen toch wel weten, en het is de taak van academia om dingen te weten, dat ze een zeer bevattelijke monocultuur van op zichzelf al zeer kwetsbare software (en hardware) vormen.

Het is ondertussen veel minder de vraag of, maar veel meer wanneer, je bezocht gaat worden. Want er zit bruut geld in aanvallen en het kost de aanvallers vrij weinig meer om de aanval in te zetten.

Het kostte ze daar in Mestreech dus een miljoen. Iedere andere Nederlandse universiteit danwel hogeschool of zelfs ROC zou nu dus een miljoen opzij kunnen zetten om zich te wapenen. En als ze samenwerken kost het wellicht per scholierensilo stukken minder.

KPN gebruikte deze rommel toch ook?

AppLocker voorkomt niet dat macro's in gedownloade MS Office documenten (in de door jou genoemde mappen) worden uitgevoerd. Meer info over deze Emmentaler "beveiliging": https://github.com/api0cradle/UltimateAppLockerByPassList/blob/master/README.md (bijv. .hta files). Bovendien leiden dit soort trucs tot enorm veel helpdesk calls; kijk maar eens waar Microsoft het bestand "onedrive.exe" by default installeert - en niet alleen Microsoft doet zo stom.

Ik vermoed dat Heise nog niet alle details heeft gepubliceerd omdat de fabrikant nog geen oplossing heeft geboden. Ik neem aan dat Heise het verstandig vond om na 3 maanden wel iets te publiceren om gebruikers en provisioning providers te waarschuwen dat er een probleem bestaat gerelateerd aan provisioning.

En wellicht deed Heise dit om de druk op Yealink op te voeren - iets dat helaas in veel te veel gevallen noodzakelijk is. Ook in dit geval, want "Yealink hat gegenüber c't geäußert, dass man mit Hochdruck an einer Zwei-Faktor-Authentifizierung arbeite, um die Lücken zu schließen" - al 3 maanden "Hochdruck" dus en nog geen fix of workaround in zicht.

Ik weet (helaas nog) weinig van VoIP, maar als https://www.heise.de/forum/c-t/Kommentare-zu-c-t-Artikeln/VoIP-Telefone-Schwere-Sicherheitsluecke-bei-Yealink-entdeckt/Die-Autoprovisionierung-ist-eine-prinzipbedingte-Schwachstelle-von-VoIP/posting-36076637/show/ klopt en elk toestel elke 24 uur "naar huis belt" voor configuratie en/of updates, dan is dat bepaald geen TOFU. Een beetje googlen lijkt die "1x per dag" te bevestigen. Voor auto-provisioning zie bijv. https://www.yeastar.com/blog/auto-provisioning-yeastar-pbx-phone-system/.

Of kpn.nl deze toestellen zelf gebruikt weet ik niet. Maar als de briljante domeinnaam (NOT [*]) in https://www.kpnwebshop.com/telefoontoestellen/universele-ip-telefoons/yealink/producten daadwerkelijk van kpn.nl is ([**]), dan lijkt kpn.nl deze telefoontoestellen in elk geval wel te verkopen.

[*] Waarom niet webshop.kpn.nl?
[**] Daar lijkt het wel op; het EV certificaat van die site is van "Koninklijke KPN N.V.". Helaas laat Firefox op mijn smartphone niet meer zien dat het om een EV certificaat gaat (met de Firefox extensie "Certainly something" zie ik dat gelukkig wel).

Nee maar het voorkomt wel dat de tweede trap, een .exe die gedownload en uitgevoerd wordt, mogelijk is.
En daarmee strandt de hele aanval.


Klopt in de log van deze feature staan regelmatig pogingen om malware te downloaden en dat blokkeert ie dan.
Als mensen daadwerkelijk dit soort software willen gebruiken kan het gewoon onder Program Files geinstalleerd worden.

Pogingen om aan te geven dat een bepaalde maatregel niet 100.000000% gegarandeerd effectief is vind ik te
ridicuul om er op te reageren.

Ik had al vaker voorgesteld dat er een organisatie moet kopen tussen CERT en bedrijfsleven/semi-overheid die dan admins gaat mailen en actief onderhouden/raadplegen en in spoedgevallen doet afbellen/SMSsen.. Dit is grotendeels te automatiseren.

Je bent dan pro-actief bezig. Het kan ook door de overheid gesubsidieerd worden. Scheelt ellende want de meeste admins zitten niet dag en nacht op Bugtraq, FUD of CERT te kijken en vernemen zaken over Citrix weer via de NOS als de AIVD er gerucht aan geeft. Nou ja... "de meeste" , een grote schare admins.

Zo deze ... is ook weer te vinden op het Internet/ Google. En bij deze even een paar maandjes weg van Security.nl

Ik lees passief mee als er wat leuks in de kolommen staat.


-r

Nou nee. Zoek eens op internet naar fileless malware. Als je verder over dit thema wilt discussiëren, prima, maar maak dan een nieuw topic aan. Jouw argumenten hebben niets meer met de Yealink kwetsbaarheid te maken.

Mag ik er nog even op wijzen dat JIJ ZELF de off-topic content bent begonnen te posten?? Jij begon over "Ga eens met
een Windows beheerder van de universiteit Maastricht praten" terwijl we het hadden over iets heel anders, namelijk het
voortdurend door "onderzoekers" wapperen met vulnerabilities met een onwaarschijnlije scope in dingen als telefoons en
IoT devices. Haal er dan geen dingen bij die niks met dat onderwerp te maken hebben, als je je topic niet wilt laten
afdwalen naar Windows.

Dat was een voorbeeld in reactie op wat jij schreef:
Ik had ook als voorbeeld kunnen noemen dat een een van de vele gehackte Linux computers op het, destijds (ca. 18 jaar geleden) nog niet firewalled netwerk van de TU Delft, ARP-spoofing attacks op een (toen veel te groot) subnet begon uit te voeren. Maar Maastricht leek mij meer bij de tijd.

De issue is dat er steeds meer devices met internetkoppelingen op onze netwerken verschijnen, die ook een risico kunnen vormen. Ook als zij (aanvankelijk) niet direct bereikbaar zijn van buiten, maar wel onveilige verbindingen naar buiten maken (denk hierbij ook aan Teamviewer-achtige software die remote contol door firewalls en/of (P)NAT mogelijk maakt, AKA "NAT traversal"). En helemaal als deze devices ook koppelingen met een of meer andere interne netwerken hebben.

Voorbeeld, uit https://www.reddit.com/r/sysadmin/comments/f08h2b/big_security_flaw_discovered_in_yealink_voip/fgseq6j/
Als je daaronder op "Continue this thread" klikt, zie je de volgende bijdrage (direct bereikbaar via https://www.reddit.com/r/sysadmin/comments/f08h2b/big_security_flaw_discovered_in_yealink_voip/fgshjl0/):

Als je deze Yealink IoT devices strikt gescheiden houdt van de rest van je netwerk blijft de schade "beperkt" tot het mogelijk kunnen stelen van adresboeken, afluisteren van gesprekken, redirecten van nummers etc. Zodra je koppelingen met andere netwerken realiseert, al dan niet gedwongen door management, kan het leed veel groter zijn. Ongeacht om wat voor soort netwerk het gaat en welke besturingssystemen op andere daarop aangesloten devices draaien (denk ook aan printers, beamers, smart screens etc); voor je het weet heb je backdoors in je organisatie gecreëerd.

Dit soort auto-provisioning werkt normaal gesproken door middel van een DHCP optie die de lokale DHCP server verstrekt
aan de telefoons (mogelijk gelimiteerd dmv MAC adres of fabrikant) en waarin een URL staat van een autoprovisioning
server die lokaal of op internet kan zitten.

Het BOEEHOOEEE VULNERABLE beperkt zich meestal tot "een aanvaller kan een valse DHCP server op het lokale
netwerk zetten die de telefoon naar een andere provisioning server stuurt" of "een aanvaller kan een man-in-the-middle
vormen tussen een netwerk en de provisioning server op internet".
En dat moet de telefoonboer dan maar gaan fixen bijvoorbeeld door een TLS verbinding te vereisen waarbij het certificaat
strikt gechecked wordt. Wat vaak niet eens zo simpel is omdat de telefoon geen klok heeft en dus de geldigheid van
een certificaat niet goed kan checken. De NTP server die hij daar voor nodig heeft is onderdeel van de configuratie die
hij nog moet ophalen.

Nou sorry hoor maar ik vind dat soort meldingen onzin. Laat men zich met nuttiger zaken bezighouden dan zo'n
theoretische "aanval" op een telefoon.