image

Lek in server Duitse corona-app maakte remote code execution mogelijk

dinsdag 24 november 2020, 14:44 door Redactie, 9 reacties

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.

Reacties (9)
24-11-2020, 15:31 door Anoniem
Goh... je verwacht het niet van een goed doordacht project.

Maar er is niks gebeurd. De privacy is gewaarborgd. Dus gewoon doorgaan met gebruiken, mensen!
24-11-2020, 15:51 door Erik van Straten
[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]
24-11-2020, 17:10 door Anoniem
Door Erik van Straten: [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.
24-11-2020, 17:40 door Anoniem
Door Erik van Straten: [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]
Teveel Lexicon is lastig voor IT mensen die de woorden niet kennen of non technische mensen. Maar ik ben het met je eens dat de term "beveiligingslek" nergens over gaat. Mensen die deze apps gebruiken zijn zowiezo niet heel security/privacy minded denk ik.
24-11-2020, 18:31 door Anoniem
Door Erik van Straten: 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?

Een "gat", in plaats van een "lek"? Beide woorden zijn drie letters lang :-)
25-11-2020, 11:09 door Anoniem
Waarom niet gewoon 'Fout'?
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.
25-11-2020, 12:19 door Anoniem
Als software iets kan doen, wat men niet verwacht, dat het zou kunnen doen, heb je zoiets.

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
25-11-2020, 13:29 door Erik van Straten
Door Anoniem:
Door Erik van Straten: 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?

Een "gat", in plaats van een "lek"? Beide woorden zijn drie letters lang :-)
In een deel van de gevallen is "gat" waarschijnlijk beter dan "lek", maar waar ik op zoek naar ben is een kort alternatief voor "kwetsbaarheid' (en dat is niet altijd een "gat").

Door Anoniem: Waarom niet gewoon 'Fout'?
Het is namelijk geen 'lek' maar gewoon een fout in de software of de configuratie die het mogelijk maakt dat er informatie lekt.
Het gaat niet altijd om een "fout" (denk aan een opzettelijk aangebrachte backdoor), het betreft niet altijd software (hardware waaronder mensen kan ook) en, zoals ik eerder al schreef, niet in alle gevallen wordt vertrouwelijke informatie gelekt (denk bijv. aan de klassieke ransomware).

Door Anoniem: 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.
Zoals jij, door "fout" voor te stellen?

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.
28-11-2020, 00:48 door [Account Verwijderd]
Door Erik van Straten: ... 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.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.