Lek in identificatiesysteem eIDAS liet aanvallers zich voordoen als EU-burger

De Europese Commissie heeft een kritiek lek gedicht in het elektronische identificatiesysteem eIDAS. Aanvallers konden het lek misbruiken om zich voor te doen als een Europese burger bij het uitvoeren van handelingen die via eID-applicaties worden geregeld.

De afkorting eIDAS staat voor 'electronic identification, authentication and trust services'. Het systeem is ingesteld naar aanleiding van een Europese verordening die bepaalt dat lidstaten onderling toegang moeten verlenen tot digitale diensten. Dat betreft bijvoorbeeld eID-middelen, waarmee burgers belastingaangifte kunnen doen of een bankrekening kunnen openen in andere Europese landen. Dat gebeurt via het draaien van een speciaal serversoftwarepakket genaamd eIDAS-Node. Overheidsinstanties draaien dat pakket op hun servers om eID-applicaties te ondersteunen.

Beveiligingsonderzoekers van SEC Consult hebben onlangs twee kwetsbaarheden in eIDAS-Node gevonden. Volgens de onderzoekers was het mogelijk om een certificaat te spoofen, doordat eIDAS-Node dat niet valideerde. Het spoofen kan al tijdens het opzetten van een verbinding met iedere willekeurige Node-server en is daarmee volgens de onderzoekers relatief eenvoudig in te zetten als aanval. Door het lek uit te buiten, was het mogelijk voor een aanvaller om zich voor te doen als een EU-burger en op die manier gebruik te maken van de applicaties die door eID worden ondersteund.

De kwetsbaarheden zijn inmiddels opgelost, zeggen de onderzoekers tegen ZDNet. Dat gebeurde nadat zij hun bevindingen hadden gedeeld met de Europese Commissie. Die brengt vandaag versie 2.3.1 van eIDAS-Node uit, inclusief een waarschuwing aan lidstaten om de software te updaten.

Door Tijs Hofmans

Nieuwscoördinator

31-10-2019 • 10:01

24

Reacties (24)

Sorteer op:

Weergave:

Slecht of niet getest? Staat zo te zien gewoon in hun specs:
4.2.3. Response messages verification
Each eIDAS-Connector should verify the authenticity of a SAML Response message before processing the included assertion.
For messages originating at an eIDAS-Proxy Service, this comprises the following steps:
1. Retrieve the SAML Metadata object of the sender, either from the metadata URL contained in the Assertion or from a local cache. A local cache is used to reduce latency (redirect processing is usually faster than POST-processing) and to enhance usability in environments where JavaScript is not available, e.g. corporate networks.
2. Verify the signature of the SAML Metadata object including Certification Path Validation according to [RFC5280]. The Path should start at a valid trust anchor.
3. Extract the signature certificate of the sender from the SAML Metadata and using it to verify the signature of the SAML Response message.
4. If the SAML Assertion is signed, its signature MAY be verified.
Assertion messages which cannot be verified via this procedure should be rejected. Unsolicited Response Messages should not be accepted.
Bron
Inderdaad. De gevonden problemen zijn echt de 2 standaard problemen die je tegenkomt bij een zelfgeschreven Service Provider implementatie en dus ook de eerste zaken wat een pentester zou proberen. Dus ik gok helemaal niet getest. Probleem is ook wel deels te wijten aan dat de SAML specificatie te veel vrijheidsgraden heeft. Je kan alles op 10 verschillende manieren gaan doen, dus dan is de kans op een foute implementatie ook een stuk groter.
Net is er reactie op #DVP2019 gegeven.
Vorige week is het lek al gedicht (in gehele EU)
NL heeft hier geen last van gehad, en ook na onderzoek niets gevonden.
Volgende keer gaat communicatie beter.

Toevoeging: gehele

[Reactie gewijzigd door ollie1965 op 23 juli 2024 14:57]

Gelukkig dus.
Hopelijk in België idem :+
Gehele EU, dus ja B ook :+
Ah sorry, ik verstond onder EU, de europese instanties. 8)7
Hopelijk updaten de lidstaten dit in afzienbare tijd, want de vulnerability is nu wel gekend voor het publiek.

[Reactie gewijzigd door Bein Stuyle op 23 juli 2024 14:57]

Het publiek, ja. Moet je voorstellen dat specifieke groepen zich allang ingezet hebben op het reverse engineeren van de node. Zo'n platform is natuurlijk rete interessant voor letterlijk iedereen die zich ongeoorloofd toegang wil verschaffen tot overheidssystemen.
Dat is nu eenmaal hoe responisble disclosure werkt. Een vastgestelde kwestbaarheid is opgelost. Door informatie te geven over het hoe en waarom vermijdt men dat grey- of blackhats diezelfde informatie zullen extraheren uit de patch en op een eilandje van kennis kunnen operereren. Maw, de informatie zelf ís al publiek (door de patch)
De informatie is voor beheerders dan juist weer minder makkelijk uit die patch te extraheren, terwijl het wel zij zijn die een threat analysis moeten maken - en dus nood hebben aan informatie over het hoe wat waarom.
Zeker maar als - zo als uit andere reacties dus ook blijkt - er geen tests gedaan zijn dan zijn deze onderzoekers niet de eerste die het eens aan de tand voelen zonder dat het ze gevraagd is. Daar durf ik theoretisch gezien wel geld op in te zetten echter is dit allemaal zo slecht geïmplementeerd dat we de waarheid toch nooit zullen weten.
Sowieso wel raar dat het een optie is of ze het updaten. Je zou verwachten van een dergelijke applicatie/infrastructuur dat de node geweigerd kan worden als het niet up-to-date is.
Dat kan een mogelijkheid zijn, maar als updates simultaan gebeuren op alle nodes, zit je natuurlijk wel met een plotse onbeschikbaarheid. Niet dat dit veel gevolgen kan hebben, maar het is toch belangrijk om eerst te kunnen nagaan welke impact een uitrol van een patch heeft op de business continuity.

Afweging risico tegen beschikbaarheid dienst.
Dat wordt vragen stellen op het dienstverlenersplatform vanmiddag ;) :+


(onderweg naar...)

[Reactie gewijzigd door ollie1965 op 23 juli 2024 14:57]

Zo en hoeveel valse bankrekeningen zijn er nu geopend en hoeveel valse paspoorten? Alles maar digitaal is lang niet zo'n goed idee, zeker niet bij dit soort zaken.
Alles maar digitaal is lang niet zo'n goed idee, zeker niet bij dit soort zaken
Risico = kans x effect. Hoewel de kans wellicht klein is, blijkt deze uiteraard nooit nul. Het effect is soms echter heel groot.

Ik kan de impact van het effect hier niet goed inschatten, maar soms moet je inderdaad overwegen om in het geheel geen gebruik te maken van een bepaalde techniek.
gespoofde certificaten.. geen validatie.. m.a.w.: kans is groot dat ze de legitieme verzoeken niet meer van onlegitieme kunnen scheiden (achteraf).

Wat een letterlijke shitshow.
die these is natuurlijk gebaseerd op een hoop veronderstellingen. Je zou er ook vanuit kunnen gaan dat ze wel degelijk goed logging en auditing hebben. Wat mij betreft is die kans even groot.
Bovendien biedt een PKI natuurlijk de mogelijkheid om retroactief trusts te invalideren (aka revocation).

Ook is het zo dat dit lek ontdekt werd door beveiligingsonderzoekers en dan gerepareerd, waardoor het helemaal niet zeker (zelfs eerder onwaarschijnlijk) is dat er misbruiken zijn geweest.

Wel ben ik het met je eens dat dit een grove fout is... een certificaat gebruikt ter authenticatie niet checken 8)7 :X :?
Geen pentests lees ik... ik doe een hoop veronderstellingen ja vanuit eerdere situaties. Helaas scheelt het vaak ook op andere gebieden als de standaard beveiligingsmechanismes al simpelweg te ontwijken zijn. In dit geval was het geen ontwijking. Er werd niet eens gevalideerd. 8)7
In het verleden is keer op keer gebleken dat dit soort zaken nooit 100% op orde zijn..
Nee, want toen alles op papier was was het natuurlijk véél moeilijker om zonder sporen valse documenten te produceren ;).
Niks is onfeilbaar maar als jij persoonlijk naar het gemeentehuis moet komen om een paspoort aan te vragen is de kans om te frauderen aanzienlijk kleiner en is de drempel ook wat hoger dan ff achter je schermpje zitten kloten.
Paspoort no way. Dat proces heeft vele waarborgen.
Bankrekening? Als de banken doen wat ze moeten doen vallen ze na de aanvraag ook door de mand
Oh nee andere basale dingen doen ze ook al niet goed

Op dit item kan niet meer gereageerd worden.