Samsung bevestigt dat 'Galaxy-broncode' is gestolen bij hack

Samsung bevestigt dat het slachtoffer is van datadiefstal en zegt dat er bedrijfsgegevens zijn gestolen, waaronder 'broncode voor de werking van Galaxy-smartphones'. Vermoedelijk zit Lapsus$ achter de hack, een ransomwarebende die eerder data van Nvidia stal.

Samsung Electronics heeft maandag toegegeven dat er data is buitgemaakt bij een cyberaanval, schrijft Bloomberg. Volgens een statement van de Zuid-Koreaanse elektronicafabrikant is daarbij ook 'broncode voor de werking van Galaxy-smartphones' buitgemaakt. Verdere inhoudelijke details geeft het bedrijf daar niet over.

Eind vorige week beweerde ransomwarebende Lapsus$ ingebroken te hebben op servers van Samsung en daar data buitgemaakt te hebben. De groep toonde screenshots en heeft 190GB aan bestanden uitgelekt. Volgens de groep zit daar onder andere de broncode van 'alle Trusted Applets geïnstalleerd in Samsungs TrustZone-omgeving' bij, net als de algoritmes die Samsung gebruikt voor biometrische ontgrendeling.

Ook zouden de uitgelekte bestanden de broncode van de bootloaders van Samsung-apparaten bevatten, net als de broncode van alle diensten die Samsung gebruikt voor online accounts van gebruikers. Samsung zegt niets over de eventuele gevolgen van het uitlekken van die informatie. Een woordvoerder zegt tegen Bloomberg dat er geen persoonsgegevens zijn buitgemaakt.

Lapsus$ zegt niet waarom het de bestanden heeft gestolen. Voor zover bekend zijn de servers van Samsung niet geïnfecteerd met ransomware en stellen de criminelen geen eisen. De groep probeerde Nvidia te dwingen tot het verwijderen van de Lite Hash Rate-beperking van gpu's en biedt de vermeende broncode waarmee dat zou kunnen inmiddels ook te koop aan voor een miljoen dollar.

Screenshot van Lapsus$ van Samsung-hack

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (89)

Als daar ook de broncode van Knox bij zit dan zie ik de bui al hangen. Dat is echt killing voor ze, omdat Knox nu bekend staat als een zeer veilige omgeving voor de apps die je bedrijfsgegevens kunnen raadplegen en editen.

Dat er nu geen persoonsgegevens buit zijn gemaakt, wil niets zeggen. Als de broncode van al die diensten bekend is kan men er nu veel makkelijker doorheen spitten op zoek naar een kwetsbaarheid waardoor ze wel bij die persoonsgegevens kunnen komen.

Ik heb even gekeken en de leak bevat de volgende parts / onderdelen:

Part 1: contains a dump of source code and related data about Security/Defense/Knox/Bootloader/TrustedApps and various other items
Part 2: contains a dump of source code and related data about device security and encryption
Part 3: contains various repositories from Samsung Github: mobile defense engineering, Samsung account backend, Samsung pass backend/frontend, and SES (Bixby, Smartthings, store)

Knox, bootloader informatie, security / encryptie, Bixby, samsung account backend, mobiled defense engineering.. alles hiervan klinkt cruciaal om verborgen te houden. Dit kan potentieel wel eens slecht gaan uitpakken voor Samsung en haar gebruikers. Ben benieuwd.

Het is nu dus afwachten of Knox zélf ook secure is en dat alle signing keys niet buit zijn gemaakt.

[Reactie gewijzigd door stin00 op 7 maart 2022 15:13]

Als het echt veilig geschreven is dan maakt het uitlekken van de sourcecode niet echt uit. Security through obscurity is bad practice

Klopt natuurlijk. van de andere kant is het vinden van kwetsbaarheden door bugs wel veel makkelijker te vinden.

Klopt natuurlijk. van de andere kant is het vinden van kwetsbaarheden door bugs wel veel makkelijker te vinden.

Het klopt, maar relatief gezien valt dat probleem wel mee. Ook zonder source lukt het prima om gaten te vinden. Maar om die gaten te dichten is de source wel extreem waardevol en haast onmisbaar, zeker op lange termijn.

Als je de motorkap van een auto helemaal dicht last verklein je de kans dat er vuil in de motor komt waardoor er iets stuk gaat. Maar als er iets stuk gaat kun je het niet reparen als de motorkap niet open kan. En alles gaat ooit een keer stuk, je kan er dus maar beter voor zorgen dat het gerepareerd kan worden.

Je hebt dus gelijk dat geheim van broncode op zich de kans verkleint dat iemand iets vindt, maar de kans dat iemand vindt zonder de broncode is nog steeds vrij groot. De meerwaarde van bugs zelf kunnen (laten) oplossen (of op z'n minst begrijpen) weegt daar ruimschots tegenop.

(IT-)beveiliging is altijd een ongelijke strijd. De aanvallers kunnen 9999 mislukken en 1 keer slagen en dan zijn ze binnen. De verdedigers mogen nooit mislukken. Niemand is perfect, vroeg of laat komt er iets door. Zorg er dus voor dat je problemen kan oplossen.

[Reactie gewijzigd door CAPSLOCK2000 op 7 maart 2022 21:22]

En als ze binnen zijn is het spel omgekeerd, mits je goede logging, alerting en monitoring hebt waar ook iets mee wordt gedaan. En dan ingrijpen. Maar het is inderdaad een ongelijke strijd voor verdedigers om aanvallers buiten te houden. Je kunt niet iets repareren als je niet weet dat het stuk is.

Dat is juist de kracht van OpenSource normaal. Als de software goed in elkaar zit dan moet het niets uitmaken zoals Ignition hierboven aangeeft. Ik zou bijna zeggen dat het een verplicht iets zou moeten zijn.

Issues als Heartbleed en recenter Log4j2 bewijzen dat je wat betreft security niet persé een waarde moet plakken aan "publieke" code.

Bij log4j2 ging er iets anders heel erg fout. Om de een of andere reden heeft jarenlang niemand de 1+1=2 optelsom weten te maken daar. Het daadwerkelijke onderliggende probleem was jaren eerder al uit de doeken gedaan. Mijn persoonlijke mening is dat het komt omdat het "maar" een logging API was, niemand voelde zich echt gekieteld om dat onder de loep te nemen omdat het als te klein bestempeld werd.

Dat is zijn punt, ondanks dat de code totaal voor iedereen beschikbaar was, is niemand het opgevallen dat 1+1, 2 blijkt te zijn

Waarde of niet. Het gebeurt overal. Maar bij opensource is het wel direct zichtbaar. En ze zijn vaker bij niet opensource in het nieuws dan wel opensource.

OK bij opensource direct zichtbaar maar het belangrijkste vind ik nog dat niemand het in zijn hoofd zal halen om voor een bug in opensource software een virus of andere malware te gaan scrhijven die die bug uitbuit. Eerder zal men de bug patchen en zijn credits krijgen.
Een virus schrijven is compleet verloren tijd: zodra die te actief wordt dan wordt de bug wel door anderen gepatched en is dat virus zijn levensdoel kwijt.

Dat geef ik toch ook al aan. Nu design zou het niet moeten uitmaken maar de praktijk is vaak niet gelijk aan de theorie/design.

Een bugje is zo gemaakt.

Open source kan helpen maar log4j heeft wel bewezen dat dit ook best lang niet gedetecteerd kan worden ook al is het open.

Het nu opensourcen zou kunnen helpen om sneller bugs te vinden en te lachen voordat kwaadwillenden dat doen gezien het wel al op straat ligt

Ja en nee. Ik wil best geloven dat 'Security through obscurity' bij deze software niet aan de orde is. Desondanks kan het zijn dat er ergens een klein bugje zit. In de tijd van jailbreak.me kon je een iPhone ook jailbreaken met een PDF. En dat was echt niet omdat ze iets probeerde te verstoppen, maar door een bug.

Als je de broncode hebt, dan is het zoeken van bugs wel wat makkelijker dan het zoeken naar bugs in een black box. Volgens mij is er ook een e-fuse onderdeel van de beveiliging wat het zoeken naar bugs op een echt apparaat natuurlijk ook bemoeilijkt. Met de broncode kun je bijvoorbeeld lezen wanneer die e-fuse er aan gaat.

Als je de broncode hebt, dan is het zoeken van bugs wel wat makkelijker dan het zoeken naar bugs in een black box. Volgens mij is er ook een e-fuse onderdeel van de beveiliging wat het zoeken naar bugs op een echt apparaat natuurlijk ook bemoeilijkt. Met de broncode kun je bijvoorbeeld lezen wanneer die e-fuse er aan gaat.

Dat klopt, maar zonder die broncode kun je het ook uitlezen. Het kost wat meer moeite maar meestal is het nog steeds niet heel lastig voor een handige aanvaller. De applicatie moet immers al die informatie bevatten om te werken. Het zit er in en je computer kan die data uitlezen, ook al is het misschien minder handig terug te lezen voor een mens.

De echte waarde van de broncode zit niet in het vinden van problemen maar in het oplossen.
Problemen vinden kan ook zonder broncode is maar een klein beetje moeilijker dan met. Sterker nog, de meeste aanvallers proberen niet eens om de broncode te gebruiken want hun automatische tools vinden de bugs toch wel voor ze.
Problemen oplossen zonder de broncode is echter enorm veel moelijker. In veel gevallen is dat eigenlijk niet te doen zonder de broncode.

Omdat alles een keer stuk gaat kun je er maar beter rekening mee houden. Je kan er niet voor kiezen om nooit problemen te hebben. Je kan er wel voor kiezen of je die problemen kan oplossen of niet.

maar je encryptie sleutels moet je toch echt ergens opslaan.. en kunnen gebruiken. Liefst niet in een sourcecode-repository natuurlijk. Maar het moet ergens.

[Reactie gewijzigd door Zezura op 7 maart 2022 15:42]

Nee hoor, die kan je genereren op het moment dat je het project gaat bouwen (meenemen als aparte taak bij het compileren).

Ja, maar compileer 2x een nieuwe build en je encryptie sleutel is anders waardoor je niet meer bij gegevens kan komen want die zijn opgeslagen met een andere encryptie sleutel. opslaan in broncode is sms een no-go maar voor sommige dingen kan je niet gewoon elke keer een unieke encryptie code laten genereren.

Ook dat kan je opvangen in je CI/CD straat met een conversie stap. Dan test je eerst je build met de nieuwe keys, en uitrol naar productie gaat dan met een conversie van oude cijfertekst naar nieuwe. De stap laat je vervolgens afronden met het weggooien van je oude keys.

Ja Jenkins is er niet voor niks.. of ATLASSIAN Bamboo geef mij maar Bamboo 😙

maar je encryptie sleutels moet je toch echt ergens opslaan.. en kunnen gebruiken.

Bijvoorbeeld in een HSM.

Security through obscurity is bad practice

Waarom is dat bad practice? STO mag nooit je enige beveiligingsmethode zijn, maar het kan een prima onderdeel zijn van je beleid.

[Reactie gewijzigd door dafallrapper op 7 maart 2022 20:10]

Samsung was natuurlijk al eerder op de hoogte van de datadiefstal. Ik weet niet wat de eis van Lapsus$ is geweest, maar men heeft wel de gok durven nemen om niet op die eis in te gaan. Ik ga overigens maar vanuit dat Lapsus$ (net als andere hackers groepen) probeert flink geld te verdienen en Samsung probeert af te persen. Bij eerdere hacks, bij oa Impresa (media conglomeratie Portugal), Ministerie of Health (Brazilië), Claro en Embratel (beide Zuid-Afrikaanse telecom providers) heeft Lapsus$ ook geen eisen bekend gemaakt, maar wel data (email adressen) gepubliceerd. Het kan dus zijn dat Lapsus$ geen eisen stelt (NVIDA uitgezonderd), maar direct de data publiceert.

De gestolen data schijnt van een backup te komen die niet heel recent is en volgens een persbericht naar de Koreaanse pers zijn de singing keys die in de code voorkomen alleen developer keys en niet de keys die in de uiteindelijke producten voorkomen. Of dit ook werkelijk zo is, of dat het een poging van Samsung is om een geruststellend geluid te laten horen die niet volledig de waarheid is mag iedereen zelf bepalen.

Samsung, nog Lapsus$, heeft iets naar de pers (of personeel) door laten schemeren over eventuele eisen.

Knox is ook gedeeltelijk hardware (ARM Trustzone), waarmee je zeker bent dat alles wat je draait gesigned is. De werking daarvan is niet geheim.

De grote vraag is nu of de signing keys zijn buitgemaakt. Lijkt mij overigens niet dat die gewoon ergens op een random server met source code staan.

vind sowieso elk systeem waarbij je de signing keys in centraal beheer houd onveilig, not your keys not your data

Daar gaat het nu niet om, het zijn code signing keys. Die moeten altijd centraal zijn want anders kan men hun eigen code niet signen, en laat dat nou net het doel zijn van die keys.

De private keys staan natuurlijk op een smart card die aan de signing server hangt en het is de smart card zelf die het signing algorithme uitvoert. Keymaterial kan niet uitgelezen worden door de server en is dus perfect beschermd (houdens fysieke toegang, en dan nog...)

Het zou zelfs na het uitlekken een veilige omgeving moeten zijn. Anders zouden open-source applicaties ook nooit veilig kunnen zijn.

Deze broncode lijkt niet bedoeld te zijn als opensource, dus kan je niet zomaar stellen dat als deze code niet veilig is dat iets over opensourcecode zou stellen. Er valt uiteraard wel te stellen dat ontwikkelaars er maar beter rekening mee kunnen houden dat hun code door anderen op beveiligings-lekken doorzocht kan worden, ongeacht of het open of closed source is.

Je mist het punt. Het gaat erom dat de werking van trusted computing niet afhangt van het verborgen houden van de source code. @MoonRaven maakt het punt dat als dat wel zo was, dat open source software dan nooit veilig zou kunnen zijn.

Hmmm... Een hardcoded private key zou er wel in kunnen zitten, niet? Natuurlijk is het dan slechte code, maar ja, iedereen wil wel eens een makkelijke oplossing en misschien is het erdoorheen gekomen.

Er is geen noodzaak voor een private key in de code. Typisch sign je de firmware met een private key. De hardware verifieert de firmware aan de hand van de public key.

Het kan natuurlijk wel dat de firmware bugs bevat, die met beschikbaarheid van de source code natuurlijk makkelijker gevonden zouden kunnen worden.

Klopt.. ik had het een beetje fout in mijn hoofd. Is ook niet zo makkelijk en het is al laat hier

Hmmm... Een hardcoded private key zou er wel in kunnen zitten, niet? Natuurlijk is het dan slechte code, maar ja, iedereen wil wel eens een makkelijke oplossing en misschien is het erdoorheen gekomen.

Het klopt dat iedereen wel eens de makkelijke oplossing kiest. Mensen denken altijd dat ze er wel mee wegkomen. Risico's op lange termijn inschatten is nu eenmaal niet ons sterkste punt.
Als de programmeur weet dat de code open is dan zal er minder snel gedacht worden "ach, dat ziet toch niemand".

Als het toch gebeurt wil je het dan eigenlijk ook zo snel mogelijk weten. Hoe langer zo iets er in blijft zitten hoe groter de kans op misbruik en hoe lastiger het wordt om er nog iets aan te doen.

@MoonRaven legt een verband tussen deze code en opensource in het algemeen. Dat verband kan niet gemaakt worden op deze code, en dus de conclussie niet. Daar op wijzen doet niets af aan de stelling dat men maar beter veilig kan programmeren.

Opensource betekend niet 100% veiligheid. Elk stuk code kan potentieel een fout bevatten, of deze nu open of gesloten is.

Wat nog veel erger is voor Samsung, is dat ze momenteel een lek ergens lijken te hebben. Ze moeten nu gaan uitzoeken hoe de gegevens zijn gelekt en dat het mogelijk nog altijd open staat.

Je kunt nu alles als een gek intrekken, maar daarmee leg je allemaal processen stil. Voor Samsung (of elk ander bedrijf), is ransomware nog niet eens het grote probleem, maar alles opnieuw installeren/opzetten, processen nalopen, etc. Dat kost ontzettend veel tijd en geld. Dan heb je nog ook de kans dat het iemand binnen je bedrijf is die mogelijk dit lek veroorzaakt.

Ben voorstander dat broncode gewoon beschikbaar moet zijn, maar dit kan (is) ook voor miljoenen schade veroorzaken op deze manier.

open-source applicaties zijn ook nooit veilig, net als alle andere software is die namelijk onderhevig aan bugs. Dat heeft Log4J wel laten zien en OpenSSL een tijd terug ook.

Dat de code nu vrij beschikbaar komt houdt echter wel in dat er meer mensen naar gaan kijken (net als op het moment dat er ergens een bugje in opensource gevonden wordt er ineens mensen bovenop duiken). Resultaat is dat er waarschijnlijk meer bugs gevonden worden, die weer leiden naar meer kwetsbaarheden en uiteindelijk exploits die weer door malware kunnen worden uitgebuit.
Bugs waar je zonder sourcecode misschien nooit tegenaan loopt.

[Reactie gewijzigd door SunnieNL op 7 maart 2022 16:53]

Dan moet Knox zich nu echt gaan bewijzen, als het goed geschreven is zou het ondanks dat de bron code gelekt is nog steeds veilig moeten zijn.

En dan nog als iets van Knox te exploiten is wil het niet zeggen dat er direct persoonsgegevens op straat liggen. Je moet dan nog steeds de data van een telefoon afhalen.

[Reactie gewijzigd door codeneos op 7 maart 2022 15:13]

Daarnaast kan Samsung ook updates pushen lijkt me.

Eindelijk is controle door onafhankelijke partijen mogelijk. Hoe meer ogen de broncode zien hoe beter ...

Als Knox veilig is, maakt het niet uit of dieven wel of niet de broncode hebben. Security through obscurity maakt het voor aanvallers lastiger, maar mag nooit de reden zijn dat een product veilig is.

Zelfs als bijvoorbeeld signing keys en ander spul gelekt is, had Samsung daar al veel eerder hardwaremodules voor moeten gebruiken.

Als de veiligheid van Knox nu in het geding komt, was deze altijd al slecht. Als ik Samsung's beloftes mag geloven, is dit hooguit een probleem voor de intellectuele eigendommen van Samsung en zullen landen waar copyright minder goed wordt nageleefd (China, om er één te noemen) mogelijk met telefoons komen die hun eigen Knox hebben.

Dat is onzin wat je zegt. Het probleem is dat er nu veel meer ogen op gericht zijn.
je zegt ook niet dat linux nooit veilig was omdat er een fout in log4j zat of en openssl.

Dat de source code op straat ligt maakt het veel makkelijker om een bug te vinden in die code en te misbruiken. Zowel door kwaadwillenden als door 3de partijen die data van telefoons willen plukken (overheden etc).
Het is net zoiets als gewoon de blauwdruk van je beveiligingsinstallatie inclusief alle code geven. Ondanks dat je die beveiligingsinstallatie hebt en je die veilig acht, is het gewoon niet verstandig om die hele blauwdruk op straat te gooien omdat er altijd wel iemand iets in kan vinden wat niet afgedicht is, maar waar je zonder blauwdruk wel heel goed voor moet gaan zoeken.
Het maakt het voor kwaadwillenden gewoon zoveel makkelijker.

Het maakt het wel makkelijker, maar security through obscurity maakt iets niet veilig. Het enige wat het doet, is de lat wat hoger leggen. Samsung is groot genoeg om door overheden aangevallen te worden, dus aanvallers met de nodige vaardigheden, bronnen en motieven waren er al.

In tegenstelling tot Linux of Windows of Darwin is dit geen normale kernelcode, maar kernelcode gespecialiseerd in security. Ik mag toch hopen dat hier genoeg pentests en audits overheen zijn gegaan dat Samsung geen triviale lekken in de broncode heeft achtergelaten.

Ja, dit maakt het makkelijker om kwetsbaarheden te vinden, maar ik geloof niet dat het ontbreken van de broncode aanvallers als de NSO-groep in de weg zit voor het hacken van deze apparaten. Sterker nog, drie onderzoekers van een universiteit zonder miljoenen aan subsidie hebben de API al weten te reverse-engineeren en hebben de versleuteling gebroken voor de S8 tot de S21.

Dit soort kwetsbaarheden kunnen nu een stuk sneller worden gevonden door whitehat (of greyhat) hackers. Ik denk dat de NSA/GRU/NSO zich nu bijzonder ergeren omdat de exploits die ze in hun kluis hadden gevonden nu een stuk sneller zullen worden opgelost.

Ik denk dat onder de streep Samsung niet zo snel last zal hebben van de extra kwetsbaarheden die door het lek gevonden worden. Waar men wel last van zou kunnen krijgen, is dat de DRM-code ook gelekt is. Iedere certificaatsleutel die gelekt is, is een hele productlijn die opeens geen HD-content meer kan streamen. Dat kost ze een stuk meer goodwill en vertrouwen dan dat de TrustZone nu ietsje makkelijker te onderzoeken is.

Als knox goed in elkaar zit zou het niets uit moeten maken dat de code is uitgelekt.

Dit gaat vermoed ik zo ontzettend veel implicaties hebben voor Samsung en vooral de gebruikers. Nu kwaadwillende de documentatie en tools hebben die de complete werking van a tot z bloot leggen van de software en hardware kan er dus ook gericht gewerkt worden aan aanvallen.

De politiediensten zullen er alvast enorm blij mee zijn.
Zover ik weet is het meest secure op dit moment dus nog de Apple iPhone, mits je het altijd up to date houdt.

PS ben zelf Samsung 'fan', ben hier alles behalve happy mee...

Dus eigenlijk heb je geen vertrouwen in hun kunnen?

Laat er maar flink naar backdoors en fouten gezocht worden. Daar wordt het uiteindelijk alleen maar beter van en bovendien wordt duidelijk of jouw vertrouwen terecht is geweest of niet. Ook ben ik wel benieuwd naar hoe bepaalde security geïmplementeerd is, ik heb bij behoorlijk wat maatregelen in verschillende software/producten op voorhand een soort utopisch gevoel over de werking ervan (hoe ik het zou doen) voordat ik weet hoe de implementatie is, en dat is in de praktijk wel eens anders gebleken.

> Dus eigenlijk heb je geen vertrouwen in hun kunnen?

Bij elk lek daalt wel mijn vertrouwen. FB had 'gewoon' alles openstaan en nu lijkt Samsung toch wel ergens een serieus datalek te hebben gehad. 160GB aan repo-data en met de serieuze zaken die erin staan zoals @stin00 al meld, dan kan ik mij wel voorstellen dat je vertrouwen daalt.

Ik vraag mij serieus af of dit Samsung/de gebruiker iets oplevert. Zover ik weet mag je code onder bepaalde voorwaarden niet zomaar inzien en gebruiken. Dus ik kan wel zeggen dat Samsung op lijn 5 een foutje heeft, maar als ik de broncode uit een illegale bron heb gedownload, dan kan Samsung daar nog vrij weinig mee.

Het lijkt me op meerdere manieren niet verstandig voor ze om iemand die een probleem meldt juridisch aan te gaan pakken. Je kan dat soort dingen prima zeggen, helemaal nu bekend is dat deze code uitgelekt is en je er op verschillende manieren aan zou kunnen komen. Het "inzien en gebruiken" van code uit illegale bron waar jij het over hebt is vooral een probleem in de context van productontwikkeling, dus als jij inzage hebt gehad in de code en een telefoon ontwikkelt, zou je een probleem kunnen hebben als dat uitkomt. Als je deze kennis gebruikt om ze op de hoogte te brengen van een exploit kan ik me niet voorstellen dat ze daar moeilijk over doen. Bovendien: je brengt verder niks uit.

Je kunt het ook anders zien.

De politiediensten zijn hier niet blij mee. Nu kan jan en alleman gaan zoeken naar bugs die actief gebruikt werden door de politiediensten. Zoeken naar bugs vanuit de code kan het leven makkelijk maken(ook moeilijk). Waardoor Samsung/Knox er op gewezen kunnen worden.

De software is zo goed als die gereleased is. Of de code nu open closed of mixed is maakt niet uit.

Ook in Knox zullen fouten zitten, bijna onmogelijk om zo'n complex systeem te hebben zonder bugs.

De politie gebruikt zelf ook Samsungs, in elk geval voor de dienders op straat.

Dat is al jaren zo met open broncode. Ik zie het probleem niet zo. Nu kunnen de software specialisten eindlijk controleren of er achterdeurtjes in zitten t.b.v. de Koreaanse geheime dienst .

Nee, dat mag je niet zomaar.

Je kunt moeilijk zeggen tegen Samsung, ik heb een torrent met jullie repo's en op regel Y in repo X staat een fout.

Denk dat de enige oplossing is voor Samsung hun verliesnemen en/of de gelekte data dan maar opensource maken. Samsung maakt wel delen openbaar, maar lang niet alles, hun bootloader deelt bijvoorbeeld ook (closed) code van Qualcomm, dus dat kan opnieuw niet zomaar beschikbaar worden gemaakt.

[Reactie gewijzigd door foxgamer2019 op 7 maart 2022 16:20]

Je hoeft niet te vermelden dat je de broncode gepakt hebt, natuurlijk. Voorheen hebben onderzoekers met reverse engineering al kwetsbaarheden gevonden in de recente firmware, dus je kunt niet zeggen dat iedereen die een fout vindt ook per se de broncode te pakken heeft. Misschien dat bug bounty's nu lastiger zijn omdat Samsung iedereen kan beschuldigen van het lekken van broncode, maar als ze dat doen dan worden de bugs wel verkocht aan bedrijven die exploits verkopen. Net zo lucratief en minder last van advocaten van Samsung.

Dat gezegd hebbende, als je via een anonieme mailingservice over Tor tegen Samsung zegt "er zit hier en hier een fout" dan zullen ze die alsnog gaan oplossen. Ze zullen er niet blij mee zijn dat je hun code hebt, maar ze zullen ook al te moeilijk gaan doen.

Eerlijk gezegd denk ik dat dit wel meevalt.

Van Windows is ook wel eens de broncode gestolen: nieuws: Twee jaar cel voor verkoop broncode Windows NT/2000

Het is een extreme hoop code. Daar kun je eigenlijk alleen maar geautomatiseerd doorheen zoeken naar kwetsbaarheden. En geautomatiseerd zoeken... dat doet Samsung hopelijk zelf ook al.

Kwetsbaarheden vind je uiteindelijk vooral in gedrag, dat is niet heel makkelijk zoeken in de broncode zelf (het kan wel helpen om hem bij de hand te hebben, maar om de broncode te snappen is niet makkelijk, gewoon omdat het heel veel is).

Het is vooral marktgevoelig, als er bijvoorbeeld code in staat voor producten of samenwerkingen die nog niet aangekondigd zijn. Of dat er gejatte code in zou staan...

Tja, daarvoor gebruikt men al lang decompilers etc. Je hebt daar de originele broncode echt niet voor nodig. Zelfs met broncode ben je ook lang bezig naar zoeken van lekken.

Mooi, dan kan de dief de bloatware er voor ze uithalen

Dat zou naar het publiek inderdaad een mooie actie kunnen zijn: De bloatware er vanaf kunnen halen...

Voor de beveiligingssoftware is het nu zaak voor samsung om de issues er eerder uit te halen dan dat deze dames en heren de issues in de source hebben gevonden. Zolang ze niets vinden is het wel een aardige audit zou ik zo zeggen.

Is dat niet altijd de zaak? Dat Samsung(of white hat hackers) eerder issues vindt en fixt dan wie dan ook?

De bloatware is er ver uit te slopen met enkel root. Niet alle "bloatware" is slecht tho.

Daar heb je al genoeg mogelijkheden voor.

tegenover staat dat je OS dan helemaal geen updates krijgt.. Als de signing keys aanwezig zijn dan gewoon de bootloader aanpassen, flashen (zonder OEM unlock ), en kan men via root toegang onnodige apps verwijderen etc.. en anders neemt men een andere ROM. (Helaas?) zullen respectabele roms niet aan deze bestanden gaan zitten, kan veel negatieve consequenties met zich mee brengen, dus ik betwijfel of dit een positieve impact gaat hebben op de compatibiliteit van externe ROMs met Galaxy telefoons.

Ik weet niet wat ik hiervan moet vinden. Ergens zou het voor de veiligheid van de eindgebruikers niet uit moeten maken, mits er geen security through obscurity toegepast is.

Toch denk ik dat er wel een aantal partijen redelijk geïnteresseerd is in deze source code.

Zijn hier misschien ook signing keys buitgemaakt en kunnen partijen nu met malafide firmwares aan de haal?

Het probleem is dat samsung groter is dan deze belangrijke broncode. Van deze broncode is nu bekend dat het gelekt is, maar was ondertussen was dit duidelijk wel heel belangrijk om te beschermen. Dat is ze zelfs niet gelukt. Dat zet te denken wat er nog meer onvoldoende beveiligd is, en hoe dat hun miljoenen klanten treft. Van Samsung mag dus wel meer openheid verwacht worden waarom klanten zich geen zorgen hoeven te maken.

Ik denk dat er maar weinig grote bedrijven echt veilig zijn als grote groepen hackers ze als doel hebben.

En dat is een van de redenen om als Samsung duidelijker te laten zien wat de gevolgen voor de gebruiker zijn en wat de gebruikers in de praktijk mogen verwachten.

Hoezo 'toegegeven'? Alsof Samsung iets gedaan heeft wat niet door de beugel kan. Waarom niet het woord 'medegedeeld' of zo gebruikt?

In dit geval is er speculatie aan vooraf gegaan. En daar heeft Samsung aan toegegeven. Samsung was gehacked, maar dat wil niet altijd zeggen dat er data ontfutseld is. Dat word gespeculeerd.

Dus in zekere zin hebben ze dit wel toegegeven. Maar niet als of ze iets verkeerds gedaan hebben.

Zo vatte ik dat op.

Gaat lekker de laatste tijd, ik vraag me dan af hebben deze bedrijven hun security dan niet op orde of is er iets anders aan de hand?

Ik bedoel Nvidia en Samsung zijn nou niet de bedrijven die ieder dubbeltje moeten omdraaien.

Nee maar het zijn wel bedrijven met gigantisch veel personeel en vestigingen, Des te groter je netwerk des te groter de kans dat ergens een ongepatched systeem staat of een ITer die iets vergeten is dicht te zetten.

Je hoeft maar 1 rus ( die Putin helemaal top vind ) te hebben op je software afdeling,dan is het zo gedaan.
Ik ben niet zo van het discrimineren maar eigenlijk is de wereld nu in oorlog met Putin , en daar kunnen ook dit soort dingen uit komen.

Samsung is een goede doelgroep voor hackers. Zo ongeveer het grootste en duurste Android merk.

Duur ? de goedkoopste in pricewatch met Android 10 is 126 euro.

Samsung heeft een hele brede lijn waarin ze opereren waardoor deze vergelijking eigenlijk niet helemaal eerlijk is (en @lordawesome wel een beetje gelijk heeft). Als je je filter aanpast naar Android toestellen in de prijsklasse 900-1500 euro dan zul je daar voornamelijk Samsung toestellen gaan vinden (zoals de S20 / S21 / S22 (Plus/Ultra), Flip, Fold). Die toestellen zijn toch echt wel behoorlijk populair/gewild.

Uitzonderingen daar gelaten maar er zijn maar weinig producenten die in dat segment opereren én net zo'n marktaandeel hebben.

Nou een, Mercedes verkoopt ook een hele lijn auto's van budget naar onbetaalbaar.

Je hoeft het niet te kopen.

Daar gaat het toch niet om? Het gaat erom dat "rijke" mensen interessanter zijn voor hackers dan "arme" mensen. En rijke mensen zijn sneller geneigd om met een dure telefoon rond te lopen - typisch dus een Samsung flagship - en geen budgetphone. Dat Samsung óók in het lage segment verkoopt doet daar verder niets aan af.

Grootste risico is dat er een lek gevonden wordt dat ze kunnen misbruiken om een immens botnet op te zetten. De software is niet alleen op telefoons en smartwatches in gebruik, maar Samsung levert nog veel meer "smart" spullen. Denk aan wasmachines, koelkasten, televisies, noem maar op.
Als je die weet te updaten met een besmette versie, heb je heel veel apparaten onder je controle om narigheid mee uit te halen, en toegang tot enorm veel netwerken waar die apparaten inhangen.

Normaal gesproken hangen dat soort apparaten aan het internet maar kunnen ze enkel naar buiten toe praten en zelf een request doen. Dus als er b.v. een firmware update gedaan moet worden dan checked het IOT ding of er een update beschikbaar is bij een homeserver die Samsung host, en download die daarvan.

Het is niet zo dat Samsung zelf massaal kan communiceren naar de IOT's. Dus als je via de broncode een lek vind, dan kun je het niet perse gebruiken. Je moet dan ook nog een man in the middle attack uitvoeren door b.v. te doen alsof je Samsung's servers bent. Dat laatste is behoorlijk lastig. Stel je bemachtigd b.v. een domeinnaam updateserver.samsungblaat.com dan zou het wel kunnen als je daarachter een malafide update host, of als je DNS servers infecteert die dat domein omzetten naar een malafide server.

Klopt, je moet er meer voor doen, maar je kunt wel de controles op deze manier onderkennen die in de software gebouwd zitten en daarmee omzeilen of spoofen. Er zal meer achter zitten dan omdat het kan.

Hopen dat deze leaks ook bij de xda devs komen.

Eindelijk mss toegang tot het OneUI-Framework en Camera-blobs zodat andere toepassingen ook volledig gebruik kunnen maken van de camera's van de Galaxy reeks (handig voor de Custom roms)

Ja dat zou inderdaad wel fijn zijn.

Is het nou echt zo moeilijk om een stel van die kneuzen te pakken dan als landen/multinationals hun krachten bundelen?

Ja, vooral de 'als'... Dat samenwerken van de multinationals zie ik niet gebeuren, tot ze elkaar opkopen of zo. Misschien dat google er tegenaan schopt maar dat zie ik niet gebeuren.

Van de landen waarvan ik denk dat ze hier actief aan mee zouden willen doen, ga ik er van uit dat ze eerder in het andere kamp zitten.