Onzichtbare implantaten in broncode

Experts van de Universiteit van Cambridge hebben een kwetsbaarheid beschreven die volgens hen de meeste moderne computers treft. Een nieuwe aanvalsmethode maakt gebruik van een legitieme functie van ontwikkelingstools, waarbij de broncode één ding weergeeft, maar iets heel anders compileert. Dit gebeurt door de magie van Unicode-stuurtekens.

Directionele Unicode-opmaaktekens die relevant zijn voor herordeningsaanvallen. Source.

Meestal verschijnen stuurtekens niet samen met de rest van de code op het scherm (hoewel sommige editors ze wel tonen), maar ze wijzigen de tekst op de een of andere manier. Deze tabel bevat bijvoorbeeld de codes voor het Unicode Bidirectional (bidi) Algorithm.

Zoals u waarschijnlijk weet, worden sommige menselijke talen van links naar rechts geschreven (bijv. Engels en Nederlands), en andere van rechts naar links (bijv. Arabisch). Wanneer de code slechts één taal bevat, is dat geen probleem, maar wanneer dat nodig is – bijvoorbeeld wanneer één regel woorden in het Engels en in het Arabisch bevat – geven bidi-codes de tekstrichting aan.

In het werk van de auteurs gebruikten ze dergelijke codes om bijvoorbeeld het eindpunt van commentaar in Python-code van het midden van een regel naar het einde te verplaatsen. Ze pasten een RLI-code toe om slechts enkele tekens te verschuiven, en lieten de rest ongemoeid.

Voorbeeld van kwetsbare Python-code met gebruik van bidi-codes. Source.

Rechts staat de versie die programmeurs zien als ze de broncode controleren; links laat zien hoe de code zal worden uitgevoerd. De meeste compilers negeren stuurtekens. Iedereen die de code controleert zal denken dat de vijfde regel een onschuldig commentaar is, hoewel er in werkelijkheid een early-return statement in verborgen zit, wat ervoor zorgt dat het programma de bewerking overslaat die het geld van de bankrekening debiteert. Met andere woorden, in dit voorbeeld zal het gesimuleerde bankprogramma geld uitgeven, maar het rekeningsaldo niet verminderen.

Waarom is dit gevaarlijk?

Op het eerste gezicht lijkt deze kwetsbaarheid te simpel. Wie zou er nou onzichtbare tekens invoegen, in de hoop controleurs van broncode te misleiden? Toch werd het probleem ernstig genoeg geacht om een kwetsbaarheidsidentificatie te rechtvaardigen (CVE-2021-42574). Alvorens het artikel te publiceren, hebben de auteurs de ontwikkelaars van de meest gebruikte compilers op de hoogte gebracht, zodat zij de tijd hadden om patches voor te bereiden.

Het rapport beschrijft de eenvoudigste aanvalsmogelijkheden. De twee uitvoeringsstrategieën zijn het verbergen van een commando binnen het commentaar, en het verbergen van iets in een regel die, bijvoorbeeld, op het scherm verschijnt. Het is in theorie mogelijk het tegenovergestelde effect te bereiken: code maken die op een commando lijkt, maar in feite deel uitmaakt van een commentaar en niet zal worden uitgevoerd. Er zullen ongetwijfeld nog creatievere methoden bestaan om deze kwetsbaarheid uit te buiten.

Iemand zou de truc bijvoorbeeld kunnen gebruiken om een geraffineerde aanval op de supply chain uit te voeren, waarbij een opdrachtnemer een bedrijf code levert die er correct uitziet, maar niet werkt zoals de bedoeling was. Vervolgens, nadat het eindproduct is vrijgegeven, kan een externe partij de “alternatieve functionaliteit” gebruiken om klanten aan te vallen.

Hoe gevaarlijk is dit nou echt?

Kort na de publicatie van het artikel bekritiseerde programmeur Russ Cox de Trojan Source-aanval. Hij was op zijn zachtst gezegd niet onder de indruk. Dit waren zijn argumenten:

• Dit is helemaal geen nieuwe aanval;
• Veel code-editors gebruiken syntax highlighting om “onzichtbare” code weer te geven;
• Patches voor compilers zijn niet nodig – het zorgvuldig controleren van de code om toevallige of schadelijke bugs op te sporen is voldoende.

Het probleem met Unicode-stuurtekens dook bijvoorbeeld al op in 2017. Een soortgelijk probleem met homogliefen – tekens die er hetzelfde uitzien maar verschillende codes hebben – is nauwelijks nieuw en kan ook dienen om vreemde code langs handmatige controleurs te laten glippen.

De kritische analyse van Cox ontkent echter niet het bestaan van het probleem, maar veroordeelt de berichten eerder als té dramatisch – een treffende karakterisering van bijvoorbeeld het apocalyptische ‘Trojan Source’ Bug Threatens the Security of All Code van journalist Brian Krebs.

Het probleem is reëel, maar gelukkig is de oplossing vrij eenvoudig. Alle patches die al uit zijn of binnenkort worden verwacht, zullen het compileren van code met dergelijke tekens blokkeren. (Zie bijvoorbeeld deze veiligheidswaarschuwing van de ontwikkelaars van de Rust-compiler). Als u uw eigen programma’s voor het bouwen van software gebruikt, raden we u aan een soortgelijke controle toe te voegen voor verborgen tekens, die normaal niet in de broncode aanwezig mogen zijn.

Het gevaar van supply-chain-aanvallen

Veel bedrijven besteden ontwikkelingstaken uit aan opdrachtnemers of gebruiken kant-en-klare open-source modules in hun projecten. Dat opent altijd de deur voor aanvallen via de supply chain. Cybercriminelen kunnen een opdrachtnemer compromitteren of code in een open-source project insluiten en schadelijke code in de uiteindelijke versie van de software stoppen. Code-audits brengen dergelijke achterdeurtjes meestal aan het licht, maar als dat niet het geval is, kunnen eindgebruikers software van betrouwbare bronnen krijgen maar toch hun gegevens verliezen.

Trojan Source is een voorbeeld van een veel elegantere aanval. In plaats van te proberen megabytes aan schadelijke code in een eindproduct te smokkelen, kunnen aanvallers een dergelijke aanpak gebruiken om een moeilijk te detecteren implantaat in een kritiek onderdeel van de software te introduceren en het jarenlang uit te buiten.

Hoe u zich hiertegen beschermt

Zo beschermt u zich tegen Trojan Source-achtige aanvallen:

• Update alle compilers van de programmeertaal die u gebruikt (als er een patch voor is uitgebracht), en
• Schrijf uw eigen scripts die een beperkte reeks stuurtekens in broncode detecteren.

Meer in het algemeen vereist de strijd tegen mogelijke aanvallen op de supply chain zowel handmatige code-audits als een reeks geautomatiseerde tests. Het kan nooit kwaad om uw eigen code vanuit het perspectief van een cybercrimineel te bekijken, in een poging die ene simpele fout te ontdekken die het hele beveiligingsmechanisme zou kunnen aantasten. Als u zelf de middelen voor zo’n analyse niet hebt, overweeg dan om [Cybersecurity Services placeholder]externe experts[/Cybersecurity Services placeholder] in te schakelen.