Trojan Source-aanval maakt verbergen van kwetsbaarheden in broncode mogelijk
Onderzoekers hebben een nieuwe aanval ontwikkeld genaamd "Trojan Source" waardoor het mogelijk is om kwetsbaarheden op zo'n manier in broncode te verbergen waardoor het niet zichtbaar voor menselijke ogen is. "We hebben manieren ontdekt om broncodebestanden zo te manipuleren dat menselijke reviewers en compilers een andere logica zien", zegt Ross Anderson, hoogleraar Security Engineering aan de Universiteit van Cambridge en één van de onderzoekers achter de aanval.
Voor het uitvoeren van de aanval wordt er gebruik gemaakt van Unicode "directionality-control override characters" die een anagram van de werkelijke logica tonen. Voor het encoderen van tekst moeten zowel talen worden ondersteund die van links-naar-rechts lezen, zoals Engels en Russisch, en talen die van rechts-naar-links lezen, zoals Arabisch en Hebreeuws.
Wanneer scripts verschillende teksten bevatten moet er een manier zijn om de conflicterende leesvolgorde op te lossen. Unicode maakt hiervoor gebruik van het Bidirectional, of Bidi, algoritme. In sommige gevallen is de volgorde die Bidi gebruikt niet voldoende. Voor deze gevallen zijn er "override control characters". Deze "Bidi overrides" zijn onzichtbare karakters die het mogelijk maken om de weergavevolgorde van groepen karakters te veranderen.
Dit kan voor problemen zorgen. De meeste programmeertalen staan namelijk toe om deze Bidi overrides aan comments en strings in de code toe te voegen. Compilers en interpreters negeren de tekst in deze opmerkingen. "Door Bidi override characters binnen comments en strings te plaatsen, kunnen we ze de broncode binnensmokkelen op een manier die de meeste compilers accepteren", aldus de onderzoekers. "Ons belangrijkste inzicht is dat we broncodekarakters kunnen herordenen op een manier dat de resulterende weergavevolgorde ook syntactisch geldige broncode weergeeft."
De code zou voor een menselijke reviewer onschuldig lijken, maar in werkelijkheid iets vervelends kunnen doen, aldus Anderson. Hij merkt op het vooral slecht nieuws is voor opensourceprojecten zoals Linux en WebKit waar willekeurige mensen aan kunnen bijdragen. "Door het injecteren van Unicode Bidi override characters in comments en strings, kan een aanvaller in de meeste moderne talen syntactisch geldige broncode produceren waarvan de weergavevolgorde van karakters een logica weergeeft die verschilt van de echte logica", merken de onderzoekers op.
Als oplossing adviseren de onderzoekers dat compilers en interpreters die Unicode ondersteunen foutmeldingen laten zien bij unterminated bidirectional control characters in comments of strings. Programmeertalen zouden in hun specificaties het gebruik van deze karakters moeten verbieden. Verschillende partijen, waaronder Atlassian, hebben advisories over de aanval uitgebracht.
Want jij was daar jaren geleden al achter. Toch?
Want jij was daar jaren geleden al achter. Toch?
Deze mogelijkheid, namelijk RLO en LRI is idd niet nieuw.
Table of possible BiDi character types
https://en.wikipedia.org/wiki/Bidirectional_text
Als de editor een instelling heeft om tekst van rechts naar links te laten lopen (ter ondersteuning van talen waarin zo geschreven wordt) dan maakt even overstappen op die instelling dingen zichtbaar die met tekst van links naar rechts verborgen blijven. In vim doe je dat met :set rl. Zoiets doe je natuurlijk pas als je al iets raars is opgevallen, zoals een keyword in een string dat als een keyword is gekleurd.
Als je git gebruikt voor versiebeheer zie je dat git gui en gitk er niet in trappen, die negeren kennelijk deze reeks tekens en laten dus de code zien die wordt uitgevoerd.
Tenslotte kan je je ertegen beschermen door je versiebeheersysteem de negen unicode-tekens die hiervoor gebruikt worden niet te laten accepteren in broncode. In git kan je hooks opnemen die van alles en nog wat kunnen controleren (zie 'git help hooks' voor details). Als je bijvoorbeeld een bare repository hebt die als centrale repository dient voor je project, dan kan je een pre-recieve-hook maken met (quick&dirty) de volgende inhoud:
import sys
import subprocess
bidi_chars = '\u202A\u202B\u202D\u202E\u2066\u2067\u2068\u202C\u2069'
for line in sys.stdin:
oud, nieuw, ref = line.split()
diff = subprocess.run(['git', 'diff', oud, nieuw],
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT,
text=True)
if diff.returncode != 0:
print(diff.stdout)
sys.exit(f'git diff eindigde met rc={diff.returncode}, receive AFGEBROKEN')
if any(c in diff.stdout for c in bidi_chars):
print(diff.stdout)
sys.exit('Mogelijke Trojan Source-aanval, receive GEWEIGERD')
Hier zijn oud en nieuw de SHA1-hashes van de vorige en de nieuwe commit, en ref de branch waar de wijziging op plaatsvindt. De twee hashes worden in een git diff-commando gebruikt, en de verschillen worden simpelweg op de aanwezigheid van de bidi-tekens geïnspecteerd.
Aardig is dat git diff uitvogelt welke wijzigingen tekstbestanden betreffen en welke binaire bestanden. Verschillen worden alleen voor de tekstbestanden gegeven (inclusief broncode), van binaire bestanden wordt alleen aangegeven of er verschillen zijn. De hook blokkeert daardoor geen bidi-tekens die (per ongeluk en betekenisloos) in bijvoorbeeld een afbeelding of een zip-bestand voorkomen.
De uitvoer van print (op stdout), en de meldingen die via sys.exit worden gegeven (die gaan naar stderr), worden getoond aan degene die git push uitvoert om zijn locale wijzigingen door te zetten naar de centrale repository.
Deze hook werkt niet op de eerste commit in een nog lege repository. Dan bestaat de oude hash uit 40 nullen, en git diff vindt die ongeldig. Bij het opzetten van een nieuwe repository moet een hook als deze dus pas worden toegevoegd na de eerste commit.
Ik neem aan dat andere versiebeheersystemen ook mogelijkheden hebben om wijzigingen te controleren voor ze geaccepterd worden.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
