Api van Twitter-alternatief Spoutible lekte persoonlijke gegevens gebruikers uit

De api van Twitter-alternatief Spoutible kon gebruikt worden om gegevens van gebruikers te verkrijgen. De api lekte onder meer privégegevens, naast gehashte wachtwoorden, 2fa-secrets en tokens voor het resetten van wachtwoorden. Het lek is inmiddels verholpen.

Details over het datalek werden gepubliceerd door beveiligingsonderzoeker Troy Hunt van Have I Been Pwned. Hij deed dat nadat Spoutible het probleem al had verholpen. Hunt ontdekte vervolgens dat het mogelijk was om via de Spoutible-api namen, gebruikersnamen, e-mailadressen, IP-adressen en telefoonnummers van gebruikers te bemachtigen. Volgens de beveiligingsonderzoeker is dat eerder gebeurd bij soortgelijke ‘scrapingincidenten’ met Trello en Facebook.

De beveiligingsonderzoeker kwam er echter ook achter dat de api gebruikt kon worden om hashes van Spoutible-wachtwoorden te bemachtigen. Deze waren beveiligd met bcrypt, hoewel simpele en korte wachtwoorden daarmee relatief simpel gekraakt kunnen worden.

Daarbij kon Hunt ook de 2fa-secret van een door hem gemaakt testaccount bemachtigen. Dat is de seed die wordt gebruikt om 2fa-codes te genereren. Hackers kunnen die secret toevoegen aan een 2fa-app en zo authenticatiecodes bemachtigen. Daarmee kunnen ze 2fa volledig omzeilen. Hunt probeerde dat succesvol met zijn eigen testaccount, samen met een andere medewerker van Have I Been Pwned.

Het was volgens Hunt ook mogelijk om de 2fa-back-upcodes van gebruikers te bemachtigen. Deze zijn ook versleuteld met bcrypt, maar het betreffen zescijferige codes waarvan de encryptie binnen enkele minuten gekraakt kan worden. Tot slot lekte de api ook volledige tokens uit waarmee het wachtwoord van een account gereset kan worden.

Spoutible bevestigt het lek op zijn website en meldt dat deze inmiddels is verholpen. Volgens het platform werden daarbij ‘e-mailadressen en sommige telefoonnummers’ gescrapet. 'Ontsleutelde wachtwoorden zijn niet buitgemaakt', zo schrijft het socialemediabedrijf. Spoutible raadt gebruikers aan hun wachtwoord aan te passen en 2fa-instellingen te resetten.

Links: gegevens uit de Spoutible-api. Rechts: een medewerker van HIBP wist 2fa-tokens te genereren via uitgelekte secret. Bron: Troy Hunt

Reacties (21)

[Wielink]

Nog nooit van deze sociale media gehoord. Vreemd dat ze wachtwoord überhaupt serializable maken. Dat naast het feit dat ze een endpoint hadden om deze op te kunnen halen. Vraag me af wat het idee daarachter is.

[Blizz]

Spoutible is begonnen als pushback tegen Musk en al zijn negativiteit en alles wat er mis is met Musk-era Twitter van extreem toxic gedrag tot massale bot haatcampagnes. Tienduizenden volgers van Bouzy stemden op zijn poll dat ze inderdaad over zouden stappen en dat heeft een vrij specifieke gebruikersgroep getrokken naar een platform zoals Twitter maar zonder een Trump-kloon aan het roer. Ik zou het een ethisch alternatief noemen, maar als oprichter beweren dat iemand die deelt dat de TOS misschien te streng is aanvallen door te graven op hun Wikipedia en aan te vallen door te zeggen dat ze tijdens MeToo besloot iets gevoeligs te delen 'en dus een agenda heeft' is moreel niet veel beter.

Hij heeft het verder grotendeels zelf in elkaar gezet, in ieder geval in het begin, dus misschien dat niet goed over elk onderdeel is nagedacht. Het lijkt er trouwens op dat het lek een jaar oud is? Of vergelijkbaar als…

[Reactie gewijzigd door Blizz op 26 juli 2024 12:50]

[darknessblade]

Het oude lek stampt af van een open API endpoint van ColibriSM waarop spoutible is gebaseerd.
deze staat standaard open, en laat ook flink veel informatie zien over gebruikers.

https://www.colibrism.ru/...0powered%20by%20ColibriSM

https://www.wired.com/sto...20adequately%20secured%2C

Daarnaast als je in het F12 menu kijkt op de pagina's zie je dat hij veel OUTDATED abandonware gebruikt zoals "owlcarousel".

[SinergyX]

Ontsleutelde wachtwoorden zijn niet buitgemaakt

En dat screenshot dan?

[CodeCaster]

De waarde begint met $2y$, wat aangeeft dat er bcrypt met Blowfish is gebruikt om de hash te genereren.

[Raymond Deen]

Hmmm, dat zijn weer vier posities minder “random” tekens.
Vraag me eigenlijk af waarom je een hash herkenbaar zou willen maken.
Je weet namelijk zelf welke methode(s) je daarvoor gebruikt dus waarom herkenbaar?

[CodeCaster]

De lengte van het wachtwoord of de hash daarvan komt niet in het gedrang door hem te prefixen met het gebruikte algoritme, het aantal iteraties en een eventuele salt.

Het wordt gedaan zodat de webapplicatie bij het inloggen van de gebruiker het wachtwoord op dezelfde manier kan hashen als tijdens het vastleggen van het wachtwoord is gebeurd.

Als je dan je algoritme updatet, kun je daarna een nieuwe hash wegschrijven, geprefixt met (bij wijze van) $3z$42.

Je hebt dezelfde parameters nodig om tot dezelfde hash te komen, maar een hash kan maanden of jaren geleden aangemaakt zijn, op een eerdere versie van het webapplicatieframework (en dus wachtwoordhashalgoritme).

[Raymond Deen]

Die laatste paragraaf, daar had ik zo snel niet aan gedacht. Thnx!

Weet alleen niet of ik daar niet een aparte tabel-kolom aan zou wagen misschien. Security by obscurity is misschien bij achterhaalde hashing algoritmes dan weer wel fijn...
Maar dat is een beetje een academische discussie.

[Xxana]

ziet er een gehasht paswoord uit.

[CodeCaster]

Herhaal na mij: ik zal geen database-entities als API-models gebruiken.

Iedere Todo-app-tutorial ten spijt.

[MartenBE]

Kan je hier wat meer uitleg of wat links over geven? Ik ben zelf bezig met tutorials en daar gebeurt dat inderdaad. Wat zijn de valkuilen?

[Janoz]

De grote valkuil is dat elke kolom uit je database vervolgens ook in het resultaat van je restcall terecht komt. Dat is de reden waarom je voor je API andere objecten gebruikt dan voor je repositories en dat je daartussen een mapping laag bouwt.

[OLED]

Twitter-alternatieven zijn een beetje als cryptos geworden. Het zijn er tegenwoordig bijna teveel om te onthouden en haast geen enkele is betrouwbaar genoeg om in te investeren.

Het is bij deze hack een geluk bij een ongeluk dat bijna niemand Spoutible gebruikt

[darknessblade]

Dit is niet het eerste "Datalek" die ze hadden, beide lekken komen doordat de CEO de API open liet staan

https://www.wired.com/sto...%20thousands%20of%20users.

[Reactie gewijzigd door darknessblade op 26 juli 2024 12:50]

[Raymond Deen]

Na een stukje van dat artikel gelezen te hebben, denk ik echt van “wtf?!?!”

[darknessblade]

IDD, hoe meer onderzoek je doet naar de CEO hoe erger het wordt.

[kuurtjes]

Vergeet niet dat mogelijke aanvallers gewoon password resets konden genereren en de token uit de database halen om dan zelf het wachtwoord aan te passen.

Verder zijn gehashte wachtwoorden alleen goed als ze lang genoeg zijn.

[lDDQD]

Ik heb een account bij hen, ik hoop dat gebruikers die wél getroffen zijn gedwongen worden hun credentials en eventuele back-up codes te resetten.

[lDDQD]

Volgens mij bestaat er een groot verschil tussen het gedwongen resetten van inloggegevens en het advies om dit te doen. Bij het laatste blijft er nog steeds een risico op ongeautoriseerd gebruik.

[CyBeR]

Er staat:

Spoutible raadt gebruikers aan hun wachtwoord aan te passen en 2fa-instellingen te resetten.

Maar bij een lek van deze mate van domheid moet dat gewoon verplicht worden, en moet het advies luiden om je wachtwoord op andere plekken te veranderen als je hetzelfde wachtwoord daar ook gebruikte. (Wat natuurlijk geen goed idee is maar wat veel mensen wel doen.)