Lek in server Duitse corona-app maakte remote code execution mogelijk
Een beveiligingslek in de server van de Duitse corona-app maakte het mogelijk voor aanvallers om op afstand en zonder authenticatie willekeurige code uit te voeren en bijvoorbeeld databasewachtwoorden te stelen. Dat ontdekten onderzoekers van GitHub Security Lab.
Net als de Nederlandse CoronaMelder kunnen gebruikers van de Duitse Corona-Warn-App, wanneer bevestigd is dat ze met corona zijn besmet, een code invoeren wanneer hun codes naar een centrale server worden gestuurd. Deze server controleert of de diagnosesleutels van de gebruiker wel geldig zijn. Bij het valideren van deze data ging de server de fout in en was het voor een aanvaller mogelijk om willekeurige Java-code of systeemcommando's op de Corona-Warn-App-server uit te voeren. Op deze manier was het bijvoorbeeld mogelijk om databasewachtwoorden te stelen.
Het onderliggende probleem heeft met Java Bean Validation te maken en zorgt ervoor dat de invoer van een aanvaller zo wordt verwerkt dat het uitvoeren van willekeurige Java-code mogelijk maakt. Een probleem waar GitHub in juli van dit jaar voor waarschuwde. Onderzoekers besloten naar projecten op GitHub te kijken die met dit probleem te maken hebben. Recentelijk werd deze scan herhaald, waarbij bleek dat de Corona-Warn-App kwetsbaar was.
"De kwetsbaarheid had de potentie om de integriteit van de Duitse coronareactie te beïnvloeden en rechtvaardigde een directe respons van ons team", zegt Alvaro Muñoz van GitHub Security Lab. Het beveiligingslek werd op 21 oktober aan SAP gerapporteerd, de ontwikkelaar van de Duitse corona-app. Op 27 oktober werd een beveiligingsupdate uitgerold, gevolgd door een meer robuuste fix op 1 november.
Maar er is niks gebeurd. De privacy is gewaarborgd. Dus gewoon doorgaan met gebruiken, mensen!
Ik heb een hekel aan het woord "lek" (maar ook datalek en beveiligingslek). Bij een RCE kan er data weg"lekken", maar er zouden ook uitsluitend gegevens kunnen worden gemanipuleerd en/of er zou een backdoor kunnen worden toegevoegd.
Het woord "kwetsbaarheid" is wat lang voor titels, waarom voegen we niet "vuln" of een ander veelzeggend kort woord of afko toe aan het Groene Boekje?
[/off topic]
Ik heb een hekel aan het woord "lek" (maar ook datalek en beveiligingslek). Bij een RCE kan er data weg"lekken", maar er zouden ook uitsluitend gegevens kunnen worden gemanipuleerd en/of er zou een backdoor kunnen worden toegevoegd.
Het woord "kwetsbaarheid" is wat lang voor titels, waarom voegen we niet "vuln" of een ander veelzeggend kort woord of afko toe aan het Groene Boekje?
[/off topic]
Iedereen snapt wat er met lek bedoeld wordt en het is zo kort dat we er geen afko voor nodig hebben.
Zullen we het dan maar zo laten of gaan we 16.999.999[1] mensen[2] uitleggen dat we er een nieuw woord voor hebben omdat Erik er een hekel aan heeft. ;-)
[1] Ik ga even uit van 17.000.000 Nederlanders.
[2] Dementen, analfabeten, digibeten en baby's even gewoon meegeteld.
Ik heb een hekel aan het woord "lek" (maar ook datalek en beveiligingslek). Bij een RCE kan er data weg"lekken", maar er zouden ook uitsluitend gegevens kunnen worden gemanipuleerd en/of er zou een backdoor kunnen worden toegevoegd.
Het woord "kwetsbaarheid" is wat lang voor titels, waarom voegen we niet "vuln" of een ander veelzeggend kort woord of afko toe aan het Groene Boekje?
[/off topic]
Een "gat", in plaats van een "lek"? Beide woorden zijn drie letters lang :-)
Het is namelijk geen 'lek' maar gewoon een fout in de software of de configuratie die het mogelijk maakt dat er informatie lekt. Het security vakgebied wordt toch al overstelpt met allerlei buzztermen, die het ook moeilijker maken om het te begrijpen. Maar goed veel mensen proberen met allerlei moeilijke termen hun eigen onkunde te verbergen of hun eigen status te verhogen.
Gaan we vervolgens verder filosoferen, dan krijg je nogal wat.
Hoe noem je dat? Een lek. Neen, want dat ontstaat als een gevolg ervan.
Een kwetsbaarheid? Ook niet, want die had bekend moeten zijn, anders was er geen mogelijk lek ontstaan.
Het is nog verrekte moeilijk zoiets eenduidig te benoemen. In ieder geval gaat er dan iets zoals niet voorzien.
Dat is alleen een probleem, als er een probleem door ontstaat. Dus een fout is het ook niet, het is een nieuw iets,
want er bestaan al genoeg fouten zonder gevolgen. Ra, ra, wat is het dan wel?
In ieder geval iets dat ongewenst is of juist gewenst. Afhankelijk van wie het kan gebruiken of misbruiken.
#sockpuppet
Een "gat", in plaats van een "lek"? Beide woorden zijn drie letters lang :-)
Het is namelijk geen 'lek' maar gewoon een fout in de software of de configuratie die het mogelijk maakt dat er informatie lekt.
Met het risico dat ook ik te veel bezig ben met mijn eigen onkunde te verbergen of mijn eigen status te verhogen:
"Lek", "beveiligingslek" en vooral "datalek" dekken de lading vaak onvoldoende en/of worden verkeerd geïnterpreteerd (ongeautoriseerde wijziging of vernietiging, of wijziging/verlies door falende techniek, van persoonsgegevens, noemen we gemakshalve ook een datalek). Als mensen woorden niet (goed) begrijpen, kan dat tot misverstanden leiden - en die komen beveiliging zelden ten goede.
Bijvoorbeeld dat door ransomware vernietigde persoonsgegevens, ook als je zeker weet (ongeacht hoe) dat de betrokken cybercriminelen deze niet hebben gekopieerd voordat zij die gegevens in jouw systemen versleutelden, ook een "datalek" is volgens de AVG.
En in het onderhavige geval: in principe had een aanvaller hiermee TEK's (en aanvullende gegevens) kunnen uploaden van één of meer niet positief geteste personen, of bestaande uploads kunnen wijzigen (risicofactoren, datums en/of TEK's), of (maar dat was waarschijnlijk opgevallen) uploads kunnen verwijderen. Ongeautoriseerde wijzigingen dus - zonder dat er iets "gelekt" wordt.
Het gaat dus om een kwetsbaarheid die -voor zover bekend- nog niet was uitgebuit door kwaadwillenden; als dat klopt is er niks "gelekt" - maar bestond er wel degelijk een beveiligingsrisico.
In het Engels is het vulnerability ook een lang woord en wordt daarom wel VUL afgekort. Dat zouden we bij het Nederlandse kwetsbaarheid ook prima kunnen doen met KWE.
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Security Officer
36 - 40 uur
Als Security Officer zorg je dat het infrastructuur platform, de -broncode en de VECOZO werkplek van VECOZO zo min mogelijk kwetsbaarheden kennen. Dit doe je door kwetsbaarheden inzichtelijk te maken en op te lossen. Zo speel jij een cruciale rol in de beveiliging van al onze gegevens en bedrijfsmiddelen.
Certified Secure LIVE Online
Certified Secure is LIVE. Cross Site Scripting vinden en voorkomen? Met z'n allen een volledige kubernetes cluster compromitteren? Of gewoon voorkomen dat een collega op een phishing mail klikt? Ontwikkel ook terwijl je thuiswerkt je Hacker Mindset!
Zoals altijd zijn ook onze LIVE trainingen hands-on en met persoonlijke begeleiding van ervaren Certified Secure instructeurs. Direct vanuit je browser en dus zonder nasty extra software!
Neem contact met ons op voor de mogelijkheden voor jouw team.