Ubiquiti waarschuwt gebruikers voor mogelijke hack bij externe cloudprovider

Ubiquiti waarschuwt gebruikers voor een mogelijke hack. De fabrikant van netwerkapparatuur stelt dat het onlangs op de hoogte is gebracht van 'ongeoorloofde toegang' tot zijn it-systemen, die worden gehost bij een externe cloudprovider.

De e-mail van Ubiquiti

Ubiquiti meldt in een e-mail dat er vooralsnog geen aanwijzingen zijn dat derde partijen toegang tot Ubiquiti-accounts van gebruikers hebben gekregen. Ook is er volgens de fabrikant vooralsnog geen bewijs dat databases met gebruikersgegevens zijn ingezien. Daarbij meldt Ubiquiti dat het bedrijf niet volledig kan garanderen dat er geen gebruikersgegevens als namen en e-mailadressen zijn blootgesteld.

Het bedrijf raadt gebruikers aan om hun wachtwoord te wijzigen. Wanneer gebruikers hun Ubiquiti-wachtwoord ook bij andere diensten gebruiken, is het aan te raden om ook dat wachtwoord aan te passen. Daarnaast benadrukt Ubiquiti dat gebruikers tweefactorauthenticatie op hun Ubiquiti-accounts kunnen instellen. De fabrikant meldt verder geen details over de mogelijke hack. Zo wordt niet duidelijk welke gegevens mogelijk wel zijn ingezien. Tweakers heeft hierover vragen uitstaan bij Ubiquiti.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (95)

Netjes dat ze het melden, maar minder netjes dat ze direct naar hun cloud provider wijzen; wie zegt dat ze hun databases daar zelf voorzien hebben van voldoende sterke wachtwoorden of dat ze niet in een phishing e-mail getrapt zijn?
Persoonlijk ben ik over de tijd een stuk minder enthousiast geworden over ubiquiti door hun zwalkende productbeleid, niet waargemaakte beloftes en rare fratsen in hun software updates. Hiermee scoren ze geen punten...

Wat dacht u van het omlaag brengen van de zendsterkte van accesspoints in een firmware update. Hels kan ik worden als een ander over mijn product beslist in negatieve zin. Dit is aan mijzelf en niet aan een ander.

Tja, en dat gaat nu natuurlijk lastig rijmen worden gezien een aantal Unifi producten sinds de laatste firmware ook een 'phone-home' functie hebben gekregen.
Bron: https://www.reddit.com/r/...n_new_firmware_mandatory/ en https://www.theregister.c...i_data_collection_policy/

[Reactie gewijzigd door Madshark op 11 januari 2021 21:32]

Dit komt iedere keer weer naar voren maar is allang teruggedraaid: https://community.ui.com/...4c-4172-877a-a2303f5d3627

Dat is maar een deel. Als je verder niets doet sturen je devices nog steeds anonymous data naar ubiquiti. Om dat uit te zetten moet je in de controller een config.properties aanmaken:

https://community.ui.com/...c0-4d1d-a09c-5c75ee8e15dc

Je hebt ook met sommige producten zoals de UDM / UDM Pro dat je hier een cloud account moet gebruiken tijdens de installatie (100% lokaal kan niet meer). Ook staat remote (cloud) beheer standaard aan. Gelukkig kan het nog wel uit.

In diat geval is het dus een heel groot probleem als je inloggegevens op straat liggen want dan kan iedereen aan je netwerkinstellingen klooien en je verkeer routeren via hun eigen netwerk.

[Reactie gewijzigd door GekkePrutser op 12 januari 2021 00:41]

Dat geldt nu ook voor alle cloudkeys met UnifiOS, deze upgrade wordt ondertussen uitgerold. Gelukkig uit te zetten maar vind het een stomme stap in de verkeerde richting.

Je kan gewoon een lokaal account aanmaken ipv een cloud account. Toevallig gisteren nog door de first time installatie gelopen van een cloud key v1

De CloudKey (gen 1) draait dan ook geen UniFiOS. De CloudKey Gen 2 krijgt die update ook nu pas met firmware versie 2.

A, wist ik niet. Bedankt voor de verduidelijking

Ugh.... Is dat zo? Ik dacht nu juist aan de Cloud Key Gen2 omdat deze i.t.t. de UDM Pro nog geen cloud login vereiste. Jammer dat ze hun produkten zo enorm onderuit halen.

Ik wou er naartoe om de NVR functies te gaan gebruiken, deze kan je niet gewoon zelf in docker draaien (sowieso al een enorm minpunt). Maar dan ga ik wel naar wat anders kijken voor NVR.

Ik denk dat als ze uiteindelijk dit op de dockers ook verplicht maken, ik helemaal afstap van Unifi. Jammer dat goede bedrijven toch altijd weer omslaan. Zie ook Google ("don't be evil" en nu het totaal omgekeerde).

[Reactie gewijzigd door GekkePrutser op 12 januari 2021 12:01]

Yep, de Gen2+ die ik heb is ook geupdate (nadat ik netjes op update drukte).
Daarna kan je wel de cloud functionaliteit uitschakelen hoor, lokaal account aanmaken en dan het vinkje uit

Ah okee, doet hij dan verder niks met de cloud login? Als hij er verder niet mee communiceert is het goed.

Ik had begrepen dat het op de UDM Pro gewoon helemaal niet uit kon en lokale accounts gewoon totaal niet meer konden (uit een uitgebreide discussie op reddit, heb de URL even niet bij de hand). Maar dit was van een maand of 6 geleden toen de UDM Pro net uitkwam, misschien is daar door de commotie vanaf gezien.

Met de apps van Ubiquiti kan ik de UniFi controller nog gebruiken als ik remote access uitschakel, maar UniFi Protect is via de app dan ook lokaal niet meer bereikbaar ...

Correct, dat ervaar ik ook. Er zijn talloze threads op het ubuquiti forum hierover, deze bv: https://community.ui.com/...-ab97-5c7e384b0a72?page=2

Ook met de Unifi Portal app kom je er niet onderuit je controller aan de cloud gekoppeld te hebben, zwaar k. dus.

Reden waarom ik dat apparaat (nog) niet heb aangeschaft.

En ik begrijp niet waarom ze klanten blijven krijgen hierom. Je introduceert mijns inziens een groot beveiligingslek door deze apparaten in te zetten.

In diat geval is het dus een heel groot probleem als je inloggegevens op straat liggen want dan kan iedereen aan je netwerkinstellingen klooien en je verkeer routeren via hun eigen netwerk.

Want je wachtwoord wijzigen is te moeilijk?

UBNT ondersteunt ook al lang 2FA op accounts. Dit niet hebben aanstaan voor een kritische account (waaronder je netwerk-infrastructuur onder valt) is gewoon niet verstandig.

Nee, dat is niet moeilijk maar hun infrastructuur is gehackt. Dat had sowieso niet moeten gebeuren, en de aanvallers kunnen hiermee al toegang gehad hebben tot configuraties die remote toegankelijk waren. Het wachtwoord veranderen lost dit op maar dan is de schade al gedaan.

En 2FA of niet, het blijft iets dat server-side gecheckt wordt, de server dus waar de hackers op zaten te rommelen.

Wat ik wil is dat mijn lokale spul gewoon helemaal niet te benaderen is via een cloud dienst. Dan ben ik ook niet afhankelijk van hun beveiliging daar.

Slecht dat het op z'n omslachtige manier uitgezet moet worden.

Dit komt iedere keer weer naar voren maar is allang teruggedraaid:

Zover mij bekend, zit het er nog steeds in, alleen niet meer als standaard Opt-Out.
Dus de schaarse Opt-In klanten zullen nu wellicht nog eens extra achter de oren krabben als inderdaad het ea. is buitgemaakt met deze hack.

Waar vind je de optie om dit aan / uit te zetten?

Dat klopt, maar zelfs dan wil je dit niet zien. Ik haal uit de e-mail niet helemaal op welke systemen mogelijk impact hebben. Maar als het gaat om de hosted-controller, dan ben je gewoon F'ed...
Ze zijn er allemaal maar vaag over. Totaal niet professioneel. Maargoed, ik heb al persoonlijk geen goed woord meer over voor deze partij. Dus mijn mening mag je met een korrel zout nemen..

Beetje off-topic, maar... Nadat het eerst gewoon in de software zat en er grote commotie is ontstaan, heeft men de optie toegevoegd.

Wat ik me nu afvraag... Als het fatsoenlijk beveiligd is slaan ze de user wachtwoorden toch hashed op, dus dan kunnen de hackers het ww zelf niet (plain text) achterhalen. Waarom is het advies dan alsnog om je wachtwoord aan te passen (zelfs ook op externe sites)? En als de hackers daadwerkelijk zo diep in de system zijn gekomen dat ze wachtwoorden kunnen achterhalen, dan heeft op dat moment 2 factor authentication toch ook geen nut meer? Want dan hebben ze de ontsleuteling daarvan ook in handen.

Het lijkt erop dat ze de hashes te pakken hebben. Hashes zijn te bruteforcen aan de hand van bekende wachtwoorden.
Met alleen een hash kunnen ze een rainbow table gebruiken; hashes van bekende wachtwoorden gebruiken om deze massaal te vergelijken met hashes van wachtwoorden.
Een salt + hash moeten ze bruteforcen. Hierbij hebben ze een lijst met meest voorkomende wachtwoorden (en variaties) die ze kunnen uitproberen.
Een salt + pepper + hash betekent dat ze naast het bruteforcen, ook nog een 'geheim stukje' code moeten achterhalen. Zo wordt geprobeerd om een bruteforce te voorkomen.

Met salt + hash kunnen nog steeds gerichte aanvallen gebruikt worden. Bijvoorbeeld door te kijken naar gebruikers van specifieke organisaties. En ze kunnen kijken of wachtwoorden hier herbruikt zijn. Met het wachtwoord gebruikt bij ubiquiti, proberen ze ook in te loggen op gmail. Zie hiervoor bijvoorbeeld https://www.digitalmusicn...-hacked-reused-passwords/ ; Veel spotifiy accounts waren gehacked, maar eigenlijk kwam het doordat deze mensen dezelfde wachtwoorden op verschillende sites gebruikten.

Ook is er het probleem dat veel gebruikers korte wachtwoorden gebruiken. Hoe korter een wachtwoord is, hoe groter de kans dat deze bij een bruteforce te achterhalen is.

Als je bijvoorbeeld kijkt naar de meest gebruikte wachtwoorden (https://www.forbes.com/si...rds-is-yours-on-the-list/), zie je dat wachtwoorden vaak voorkomen en mensen niet heel creatief zijn in het bedenken van wachtwoorden (en nee, een e door een 3 vervangen, helpt niet veel).

2fa voorkomt dat een ongeautoriseerde gebruiken kan inloggen met een wachtwoord en gebruikersnaam. Hij heeft dan nog een extra code / validatie nodig.

[Reactie gewijzigd door gorgi_19 op 11 januari 2021 22:42]

Rainbow tables zijn al enkele jaren niet meer rendabel door de snelheid van de moderne GPU. Bijna elk "normaal" hash type kan je relatief snel bruteforcen met zowel woordenlijsten + regels als een rechttoe-rechtaan bruteforce. Voordeel van een woordenlijst + regels is dat je waarschijnlijk sneller hits hebt, maar een bruteforce zonder woordenlijst is dan weer een stuk sneller qua rauwe performance. In any case, geen enkel zelf-respecterende wachtwoord kraker gebruikt nog rainbow tables.

Vind het enigszins kort door de bocht om te stellen dat een "salt" nog wel gekraakt kan worden, maar een "pepper" niet. Beide zijn gewoon willekeurige strings die voor of soms na het hashen toegevoegd worden om kraakpogingen te bemoeilijken. Of heb je het hier over het verschil tussen een per user salt the over een globale salt?

Hoe dan ook, beide technieken zijn redelijk verouderd. Ik ben dan ook vaak verbaasd over mensen die in de comments onder artikelen op Tweakers het gebruik van "salts" en "peppers" aanraden. De meeste programmeertalen bieden tegenwoordig een vorm van Password-based key derivation aan (https://en.m.wikipedia.org/wiki/PBKDF2). Bij PHP is dat bijvoorbeeld de "password_hash" function: https://www.php.net/manual/en/function.password-hash.php.

Daarbij worden niet alleen hashes en salts gebruikt, een hash wordt ook meerdere keren (lees, 10000-en keren) opnieuw gehashed. Daarmee wordt je kraaksnelheid dus ook een factor 10000 lager. Een ontwikkelaar kan bij deze functies vaak ook nog een bepaalde "cost" instellen. Oftewel, hoe lang moet het hashen duren en hoeveel geheugen wordt hiervoor gebruikt. Daarmee kan je tenminste echt zoden aan de dijk zetten in plaats van dat knullige eenmalig hashen met een saltje.

Het een sluit het ander niet uit. Als je bijvoorbeeld kijkt naar hoe dropbox zijn wachtwoorden opslaat, gebruiken ze ook nog steeds salt en pepper. (https://dropbox.tech/secu...ely-stores-your-passwords). En ik zeg ook nergens dat je ZELF een salt moet toevoegen, bcrypt doet dit zelf voor je bijvoorbeeld.

Hoewel het basisprincipe hetzelfde blijft, gaat het wel wat verder dan de simpele 'peper en zout' zoals je nu schetst. Het gaat wat ver om alleen een complete verhandeling over de verschillende best practices van wachtwoordbeveiliging toe te gaan lichten.

Zijn vraag / opmerking ging over "Waarom is het advies dan alsnog om je wachtwoord aan te passen (zelfs ook op externe sites)?". Verkort antwoord: het is nog steeds dan redelijk eenvoudig om, zeker gericht, een wachtwoord proberen te achterhalen, samen met een korte toelichting. Dat je nog veel verder erop in kan gaan klopt.

Alleen hashen is een oude techniek. Maar je zal dan verbaasd zijn hoeveel systemen nog steeds wachtwoorden versleutelen op basis van MD5. Ooit gemaakt, nooit geupdated. Bijvoorbeeld https://twitter.com/havei...tatus/1265857533140320256 ) Veel systemen zijn gemaakt op basis van de best practices van lang geleden, maar niet bijgewerkt naar de eisen van deze tijd.

[Reactie gewijzigd door gorgi_19 op 11 januari 2021 23:24]

Alleen hashen is een oude techniek. Maar je zal dan verbaasd zijn hoeveel systemen nog steeds wachtwoorden versleutelen op basis van MD5. Ooit gemaakt, nooit geupdated.

Nou, hierbij moet je wel in gedachten houden dat de reden dat MD5 niet meer wordt aangeraden, is dat er collisions gevonden kunnen worden. Dit is belangrijk bij data integriteits doeleinden en ondertekening. Een aanvaller kan een collision veroorzaken en dus eigen code toevoegen bij gebruik van dezelfde hash.

Echter in het geval van een paswoord versleuteling is dat niet echt een probleem. Een collision is even moeilijk te vinden als het paswoord zelf als je de MD5 hash hebt. Er zijn langere en betere hashes, maar de belangrijkste reden voor het uitfaseren van MD5 is niet echt van toepassing in dit scenario. Het niet gebruiken van een salt is wel een probleem in bovenstaande tweet, maar dat geldt bij elke hash, zelfs SHA-512. Een andere hash lost ook de brute force problemen niet op, daarvoor zijn dingen als bcrypt en PBKDF2 veel beter.

[Reactie gewijzigd door GekkePrutser op 12 januari 2021 12:08]

Waar maak jij uit op dat ze de hashes te pakken hebben? Er staat letterlijk dat er nog geen bewijs is om aan te nemen dat deze data in handen is van een derde partij, echter kunnen ze daar nog niet van uitgaan op dit moment aangezien het nog onderzocht wordt. Dus het lijkt nog nergens op.

Ze kunnen het niet uitsluiten. Ze raden aan om wachtwoorden te veranderen. Dus houden ze er rekening mee dat dit gebeurd is.
Met de mensen die wachtwoorden gebruiken, is dan ook het advies om het aan te passen.

Dit als antwoord op zijn vraag: "Waarom is het advies dan alsnog om je wachtwoord aan te passen (zelfs ook op externe sites)?"

Alleen hash heeft weinig nut, kom je zo doorheen. Salted hash kan je gericht aanvallen, en daar is hier sprake van.

Nee, 100% bewijs hebben ze niet dat er ingebroken is. Maar wil je in dit soort gevallen 100% bewijs hebben?

[Reactie gewijzigd door gorgi_19 op 11 januari 2021 23:18]

Nee, het staat gewoon letterlijk in de mail van UI:

We cannot be certain that user data has not been exposed. This data may include your name, email address, and the one-way encrypted password to your account (in technical terms, the passwords are hashed and salted).

Dat is letterlijk wat ik zeg, er staat nergens dat ze de hashes waarschijnlijk hebben.

Er zijn genoeg tools beschikbaar om hashes te kraken, het is alleen een stuk moeilijker naarmate het wachtwoord langer en veel willekeuriger tekens bevat. Als je een slecht wachtwoord hebt is deze niet zo moeilijk te kraken door de hashes te vergelijken met andere lijsten uit vorige hacks die al gekraakt zijn.

Het probleem is dat mensen lui zijn en wachtwoorden hergebruiken. Daardoor kun je bijvoorbeeld passwords proberen die in eerdere lekken naar voren zijn gekomen. Daardoor kun je een rainbow tabel gaan maken met wachtwoorden die je gematched hebt en zo kun je eenvoudiger achter bijvoorbeeld een pepper komen.

Een salt wordt toegevoegd aan het wachtwoord, maar deze mag in orincipe publiek bekend zijn en niet uniek. Dit is puur zodat een bruteforce attack lastiger is. Als je een match vind op een hash is dit namelijk niet het wachtwoord, maar het wachtwoord+salt. Dan moet je dus eerst erachter komen wat het salt was voordat je het echte wachtwoord kunt achterhalen.

Als je het goed doet dan insert je het salt op een random positie en is het salt per user uniek.

Het salt moet je echter wel opslaan om het er uit te kunnen halen bij een inlog poging.


Het advies om het wachtwoord aan te passen is om brutforce attacks minder nuttig te maken. De hash is immers oud en zelfs al vind je er een paar in een week, met “pech” heeft de user de boel al gewijzigd en kom je er alsnog niet in.

Dit sluit ook pogingen over X maanden/jaren uit als systemen dusdanig ontwikkelt zijn dat een brute force per password niet meer 10 jaar kost, maar 1 dag. Denk daarbij aan quantum computing wat volgens velen een issue gaat zijn voor cryptografie.

Ik wil best die 2FA inschakelen, maar ik ben wat terughoudend want ik zie dat er geen backup optie is om een andere manier te gebruiken als je bv. je mobiel verloren bent (of moest herinstalleren). Ik heb dat eens moeten doen en heb zo nogal wat problemen gehad. Daarom vind ik het wel zo fijn als er ook nog een backup manier is, zoals bv. via SMS (ook al is dat ondertussen wat gedateerd)...

Is er ook nog een andere manier voor Unifi?

Ik gebruik hiervoor LastPass Authenticator. Deze kan je backuppen naar LastPass. Op een andere / nieuwe telefoon kan je dit heel makkelijk restoren.
Daarnaast heb ik een tweede telefoon, welke altijd thuis lig waar deze Authenticator ook op staat.

Mijn wachtwoorden sla ik niet op in LastPass, die bewaar ik in mijn lokale TeamPasswordManager.

Super tip! Gebruik nl. ook al jaren lastpass, dus dit gebruiken zal niet moeilijk zijn. Ik wist niet dat je de authenticator naar lastpass zelf kon backuppen. Ideaal!

Ik wil best die 2FA inschakelen, maar ik ben wat terughoudend want ik zie dat er geen backup optie is om een andere manier te gebruiken als je bv. je mobiel verloren bent (of moest herinstalleren). Ik heb dat eens moeten doen en heb zo nogal wat problemen gehad. Daarom vind ik het wel zo fijn als er ook nog een backup manier is, zoals bv. via SMS (ook al is dat ondertussen wat gedateerd)...

Is er ook nog een andere manier voor Unifi?

MS Authenticator en Authy geven je de optie om je instellingen in een backup te zetten, zodat je later weer kan herinstalleren.
Handiger dan de Google versie, waar je elke kee al je accounts opnieuw mag aanmaken

Dat kan inmiddels in Google Authenticator ook. Was inderdaad niet handig.

Ik zie dat ik de meest ouderwetse/wantrouwende ben. Ik versleutel die TOTP barcodes met GPG en commit ze naar een git repo.

Als je de code overneemt en in een Keepas zet, kun je die oook weer hergebruiken voor de Google authenticator

Als je de code overneemt en in een Keepas zet, kun je die oook weer hergebruiken voor de Google authenticator

Neemt het handmatig toevoegen niet weg.

Maar kennelijk maakt Google tegenwoordig ook een backup.

bij de pagina waar je MFA kunt aanzetten (https://account.ui.com/security) kan je ook backup codes genereren die je kan gebruiken als je geen toegang hebt tot je gsm

Super, thx!

Ik heb wel backup codes kunnen genereren tijdens het activeren van 2FA. Deze heb ik dan op een veilige plek opgeslagen.

Voor Google is er wel een backup optie, maar die vereist wel dat je de telefoon nog in je bezit hebt of dat je vooraf één van de maatregelen hebt genomen die worden genoemd in dit artikel.

Bij het instellen van de 2FA geeft Unifi je ook een reeks aan herstel codes. Dus als je die veilig opslaat, zit je goed.
En! mocht er bij toeval toch van alles fout gaan. Alle apparaten gewoon instellen op factory reset. En opnieuw instellen met een nieuw account.

Top! Bedankt!

Bij de initiële installatie van mijn ubiquity netwerk heb ik bewust een lokaal account aangemaakt op de cloudkey. Ik vraag me af wat de meerwaarde is van een cloud account. Ik kan alles doen wat ik wil en onafhankelijk van een derde partij

De meerwaarde is van netwerk beheer over meerdere locaties en voor automatiseerders met contract tot klanten voor remote beheer.
Zij kunnen kleine bedrijven op afstand hun netwerk beheren.
Kleine bedrijven met meerdere filialen kunnen hun netwerk beheerder dan ook alle LAN per filiaal beheren.

Ik heb remote acces voor controller gen 2 plus uitstaan. Als home user is er maar 1 lokatie. Cloud beheer niet nodig.

Dat zou ook kunnen met VPN toegang. Voor dit soort beheer heb je als het goed is geen cloud account nodig.

Die Unifi gedachte is dan ook centraal beheer van meerdere locaties. Maar ja via cloud blijkbaar geen “best practice” automatiseerder die werkt met kleine bedrijven en beheer op zich nemen doen dat met VPN.
Ook het aanmelden van nieuwe unifi producten via cloud wordt als risiko gezien.
Gemak dient de mens , maar vaak ook kwaadwillenden.

Je cloudID wordt ook gebruikt om aan te melden in de officiele UI shop of community.

Hier heb ik nog geen bericht over gehad van ubiquiti zelf..

Dat zou dan ook wel fijn zijn.

Edit: 22.35 krijg ik het mailtje ook eindelijk.
Ik gebruik altijd zo veel mogelijk 2fa. Maar moest nu toch een paar wachtwoorden wijzigen. Wat sneu is want ik gebruik lastpass zoveel mogelijk.

[Reactie gewijzigd door furian88 op 11 januari 2021 23:36]

Ik heb de mail ook niet gehad en heb zeker een account daar. Gelukkig via andere kanalen snel gevonden.

Nu nog de mogelijkheid om het wachtwoord aan te passen.... In ui.com zelf zie ik geen mogelijkheid. Bij "wachtwoord vergeten" krijg ik geen mail met de mogelijkheid het wachtwoord aan te passen.
Lastig!

Edit: met dank aan @IxFail NL gelukt!
Edit2: en enkele minuten later ook de mail binnen...

[Reactie gewijzigd door MDXTweaker op 11 januari 2021 22:10]

Ik ontvang ook geen e-mail voor een password reset. Zowel niet via @IxFail NL 's suggestie als via unify.ui.com.

Ze zullen wel overbelast zijn.

Via de suggestie van @IxFail NL log je in en kom je op je accountpagina uit. Daar is het mij gelukt om zowel het wachtwoord te wijzigen als 2FA aan te zetten.

Ah, ik kon niet meer inloggen omdat er iets fout ging bij het opslaan van m’n nieuwe wachtwoord in m’n passwordkluis.

Maar het is inmiddels gelukt! Mail is binnen.

Ik heb mijn wachtwoord hier kunnen wijzigen.

Ik heb wel een bericht gehad, stond bij mij wel in de spam folder...

Ik heb er 2 gehad... Eéntje kwam in de spamfolder terecht. Om 21:06 één ontvangen die wel in mijn Postvak In zat.

+1 in spamfolder

Ik heb ook niets gehad... ook niet in de spam folder.

Edit: Nog geen minuut na het posten van dit bericht was de mail er.

[Reactie gewijzigd door r2504 op 11 januari 2021 22:00]

Ik heb de mail een uurtje geleden aangehad.

Heb gewoon keurig binnen gekregen de email.

Het probleem bij dit soort berichten is dat er niet duidelijk is waarop een bedrijf als Ubiquiti besluit wie ze wanneer gaan informeren en wat je mag verwachten.
Misschien had je al een bericht moeten hebben, misschien nog niet. Het maakt het er voor klanten helaas niet duidelijker op nu ze het eerder in het nieuws moeten lezen dat er iets aan de hand is zonder daar van Ubiquiti of het nieuws antwoord op te krijgen.

Ik heb het bericht gehad, maar ik kan niet vinden op de website hoe ik überhaupt op m'n accountpagina kom, laat staan m'n wachtwoord aan te passen of 2FA aan te zetten..

#handig

https://account.ui.com

Dat hadden ze wel in plaintext in de mail mogen zetten. Nu wijst de change-password button naar een vage list-manage.com link, die weer overal uit kan komen.
Ik gebruik wel overal een uniek mailadres, maar als de userdatabase gelekt is, kan de hacker ook alle gebruikers een mail sturen met een phishing link. Dat zegt dus niet alles </paranoia mode off>

Klopt helemaal hoor, dit komt erg phisherig over. Als je al links gebruikt, doe het dan naar je eigen domein in plaats naar een vage third party. Bij ons op het werk zijn we juist zo druk bezig gebruikers erop te wijzen dat soort dingen te controleren. Dit vind ik ook geen goede zet van Unifi.

Ongetwijfeld komt het doordat ze een derde partij gebruiken om die emails te sturen, die er weer allerlei analytica aanhangt van wie op welke knop drukt. Maar in het geval van zo'n "change my password" functie is dat niet acceptabel. Juist omdat het al gaat om een hack (wat al niet had moeten gebeuren) vind ik het erg onzorgvuldig dat ze de email dan ook nog eens zo afhandelen.

Ook wat @supersnathan94 hieronder zegt: Voor degene die die database heeft bemachtigd is dat natuurlijk het eerste wat ze gaan doen.

En ik heb zelf nog op die knop geklikt ook, doh... Ondanks dat ik zag dat het geen ui.com link was, dacht ik dat het wel goed zat.. Was ook zo, maar had weliswaar ook goed fout kunnen zijn. Ook een leermomentje voor mij

[Reactie gewijzigd door GekkePrutser op 12 januari 2021 12:33]

Morgen nog maar eens veranderen en dan via een vertrouwde url

Dat staat levensgroot in de e-mail

Dear Customer,

We recently became aware of unauthorized access to certain of our information technology systems hosted by a third party cloud provider. We have no indication that there has been unauthorized activity with respect to any user’s account.

We are not currently aware of evidence of access to any databases that host user data, but we cannot be certain that user data has not been exposed. This data may include your name, email address, and the one-way encrypted password to your account (in technical terms, the passwords are hashed and salted). The data may also include your address and phone number if you have provided that to us.

As a precaution, we encourage you to change your password. We recommend that you also change your password on any website where you use the same user ID or password. Finally, we recommend that you enable two-factor authentication on your Ubiquiti accounts if you have not already done so.

(hier stonden 2 knoppen, 1 om MFA in te schakelen en 1 om het wachtwoord te wijzigen.)

We apologize for, and deeply regret, any inconvenience this may cause you. We take the security of your information very seriously and appreciate your continued trust.

Thank you,
Ubiquiti Team

Je snapt toch wel dat mensen na een hack (poging) huiverig zijn om op een wachtwoord reset link via de mail te klikken?

Mocht ik ooit “the dark side” joinen en een dergelijke situatie kunnen misbruiken is dat exact wat ik wil doen. Mensen hebben het idee hun wachtwoord gewijzigd te hebben en jij hebt direct alles plaintext binnen.

Uiteraard wel forwarden naar de daadwerkelijke site zodat het ook echt wijzigt, maar daarna ben je golden. Kost je geen rooie rotcent aan compute om de boel te kraken.

account.ui.com

de links staan normaal in de email zelf
anders: op https://account.ui.com/security kan je je wachtwoord aanpassen en MFA aanzetten

Hmm. Ik ben dan wel benieuwd wie die "externe cloudprovider" is en wat er dan gebeurt is. Bij dergelijke dingen ben je veelal als klant verantwoordelijk voor de beveiliging.

mail wel gehad hier... Ben benieuwd naar de gevolgen...

Mail komt hier ook net binnen...
Wederom weer een wachtwoord aanpassen. Schering en inslag.