FBI roept softwareontwikkelaars op einde aan command injection te maken
De FBI en het Amerikaanse Cybersecurity and Infrastructure Security Agency (CISA) hebben softwareontwikkelaars opgeroepen om een einde aan command injection in hun producten te maken. Volgens de overheidsdiensten is command injection een te voorkomen klasse van kwetsbaarheden, maar komt het probleem in de praktijk nog steeds voor. De FBI en CISA hebben de oproep gepubliceerd in reactie op actief misbruik van command injection-kwetsbaarheden in netwerkapparatuur van Cisco, Palo Alto Networks en Ivanti.
Command injection-kwetsbaarheden doen zich voor als softwareleveranciers en fabrikanten gebruikersinvoer niet goed valideren en sanitizen, waardoor gebruikers commando's op het onderliggende besturingssysteem kunnen uitvoeren. "Het ontwerpen en ontwikkelen van software die zonder goede validatie en sanitization gebruikersinvoer vertrouwt maakt het mogelijk voor aanvallers om malafide commando's uit te voeren, waardoor consumenten risico lopen", aldus de Amerikaanse overheidsdiensten. Die stellen dat deze beveiligingslekken te voorkomen zijn als softwareontwikkelaars en leveranciers een 'secure by design' aanpak hanteren.
De FBI en het CISA roepen software- en techbedrijven op om een plan op te stellen om command injection-kwetsbaarheden in de toekomst te elimineren. Het gaat om het gebruik van functies die commando's op een veiligere manier genereren, gebruik van moderne libraries, uitvoeren van code reviews, herzien van dreigingsmodellen en tijdens de gehele ontwikkellevenscyclus de kwaliteit en veiligheid van de code testen.
Softwareleveranciers en fabrikanten die willen laten zien dat ze 'secure by design' producten maken worden door de FBI en het CISA opgeroepen de 'Secure by Design Pledge' af te leggen. De pledge bevat zeven doelen voor leveranciers om binnen een jaar naartoe te werken. Zo moeten de bedrijven stappen nemen om het gebruik van multifactorauthenticatie (MFA) binnen de eigen producten te vergroten en het gebruik van standaard wachtwoorden te verminderen. Ook geven leveranciers via de plegde aan dat ze zullen proberen om gehele klassen van kwetsbaarheden te verminderen, alsmede het installeren van beveiligingsupdates door klanten te verbeteren.
Eerder kwamen het CISA en de FBI al met oproepen om een eind aan SQL-injection en path traversal te maken. "Dit Secure by Design Alert is onderdeel van een reeks die als doel heeft om industriebrede best practices te bevorderen die gehele klassen van kwetsbaarheden tijdens het ontwerp en ontwikkeling van een product kunnen elimineren. Via het Secure by Design initiatief willen we binnen de industrie een cultuurverandering bevorderen door de ontwikkeling te normaliseren van producten die out of the box veilig te gebruiken zijn", zo stellen de overheidsdiensten.
Dat is inderdaad de oplossing gewoon geen bugs en kwetsbaarheden in je code schrijven en daar dan een eed op afleggen.
BTW, zullen we dan ook alle leveranciers van auto's een eed laten afleggen dat je auto nooit kapot zal gaan. En alle fabrikanten van sloten laten zweren dat er geen inbreker ooit het slot zal kraken :-)
Als programmeur heb ik een kanttekening:
Command-injection, SQL-injection, HTML-injection zijn 3 keer hetzelfde probleem. Het probleem is dat de data niet correct wordt ge-encodeerd naar het *uitvoerformaat*.
En dat zul je voor elk uitvoerformaat apart moeten doen volgens de regels van dat formaat.
De regels voor SQL-encoding zijn de afgelopen 50 jaar niet veranderd: Voor elke: ' (single quote) in de data, schrijf er twee: '' (twee single quotes) in de query. De database zoekt naar de user [[ '); DELETE from users; ]] en komt terug met een lege lijst. En daarmee is het gevaar verdwenen, ook zonder input validatie.
Oproep aan alle pentesters: schrijf in jullie rapport niet over invoervalidatie of 'gevaarlijke characters' maar gebrekkige uitvoer-encoding.
Als programmeur heb ik een kanttekening:
Command-injection, SQL-injection, HTML-injection zijn 3 keer hetzelfde probleem. Het probleem is dat de data niet correct wordt ge-encodeerd naar het *uitvoerformaat*.
En dat zul je voor elk uitvoerformaat apart moeten doen volgens de regels van dat formaat.
De regels voor SQL-encoding zijn de afgelopen 50 jaar niet veranderd: Voor elke: ' (single quote) in de data, schrijf er twee: '' (twee single quotes) in de query. De database zoekt naar de user [[ '); DELETE from users; ]] en komt terug met een lege lijst. En daarmee is het gevaar verdwenen, ook zonder input validatie.
Oproep aan alle pentesters: schrijf in jullie rapport niet over invoervalidatie of 'gevaarlijke characters' maar gebrekkige uitvoer-encoding.
Daarom zou er een eed moeten komen
De programmeur gebruiker vindt het wel handig omdat hij dan geen last van allerlei wonderlijke beperkingen heeft.
De bewering dat programmeurs code injection wel kunnen oplossen klopt niet.
Het zo zo moeten zijn dat enkel de rechten van de actieve gebruiken met een een eventueel privileged account zo zijn ingesteld dat er geen overbodige rechten tot wat dan ook als informatie zijn. In dat geval maakt hoe je daarbij komt via een api of onbedoeld commando niets uit. Het begint dat er veel te ruime rechten ingesteld worden als gangbare cultuur. (root)
Als programmeur heb ik een kanttekening:
Command-injection, SQL-injection, HTML-injection zijn 3 keer hetzelfde probleem. Het probleem is dat de data niet correct wordt ge-encodeerd naar het *uitvoerformaat*.
En dat zul je voor elk uitvoerformaat apart moeten doen volgens de regels van dat formaat.
De regels voor SQL-encoding zijn de afgelopen 50 jaar niet veranderd: Voor elke: ' (single quote) in de data, schrijf er twee: '' (twee single quotes) in de query. De database zoekt naar de user [[ '); DELETE from users; ]] en komt terug met een lege lijst. En daarmee is het gevaar verdwenen, ook zonder input validatie.
Oproep aan alle pentesters: schrijf in jullie rapport niet over invoervalidatie of 'gevaarlijke characters' maar gebrekkige uitvoer-encoding.
Waarom zou ik een query uit laten voeren als ik input met vervelende symbolen vooraf al kan filteren en ik mezelf een query bespaar (en dus performance win, geen onnodige logfile vervuiling over me afroep, side effects per ongeluk toch mogelijk maak etc)?
De wereld bevat namen met 'vervelende symbolen'. Denk aan 'modezaak C&A'. Of de meme <3. Je kunt ze niet uitfilteren omdat daarmee de betekenis verloren gaat.
Je kunt ze ook niet 'sanitizen' aan de invoerkant. C&A wordt dan C&A. Je kunt deze gesanitizede waarde *alleen* nog maar gebruiken om in een HTML-pagina te plaatsen, of in een URL-parameter. Als je het in een database stopt gaat het mis. Want de zaak heet nog steeds C&A, niet C&A. En de & is geen vervelend symbool in SQL.
En wat als je die C&A niet alleen op een pagina wilt plaatsen, maar ook in een shell-process meegeven, dan is zowel C&A als C&A vervelend want die & betekent in Linux: 'einde van deze commando-regel, en in de achtergrond draaien.
Daarom mijn oproep voor uitvoer-encoding. Dat gaat altijd goed.
En als een hacker een poging doet, wil je dat als onnodige vervuiling weggepoetst hebben zodat je het niet ziet, of wil je het loggen en er met fail2ban op reageren en dat IP-adress blokkeren?
Als programmeur heb ik een kanttekening:
Command-injection, SQL-injection, HTML-injection zijn 3 keer hetzelfde probleem. Het probleem is dat de data niet correct wordt ge-encodeerd naar het *uitvoerformaat*.
En dat zul je voor elk uitvoerformaat apart moeten doen volgens de regels van dat formaat.
...snip
Oproep aan alle pentesters: schrijf in jullie rapport niet over invoervalidatie of 'gevaarlijke characters' maar gebrekkige uitvoer-encoding.
Waarom zou ik een query uit laten voeren als ik input met vervelende symbolen vooraf al kan filteren en ik mezelf een query bespaar (en dus performance win, geen onnodige logfile vervuiling over me afroep, side effects per ongeluk toch mogelijk maak etc)?
exact, input validation en sanitation en iets dergelijks als prepared statements. Die invoervelden hoeven niks anders te bevatten dan wat er nodig is.
i.c.m. met code die ervoor zorgt dat de backend (de database server) geen extra commando's gaat uitvoeren, met alleen de queries die van te voren bepaald zijn voor die funtie.
Kijk naar de breach van AT&T:
https://www.security.nl/posting/849649/Telecomgigant+AT%26T+lekt+telefoongegevens+van+%27bijna+alle%27+klanten
Komt ook door oncapable programmeurs die alleen op functionaliteit bouwen en het niet afdichten.
En het erge is... Op school leert men dat ook nog maar zelden.
...
Oproep aan alle pentesters: schrijf in jullie rapport niet over invoervalidatie of 'gevaarlijke characters' maar gebrekkige uitvoer-encoding.
Het is in mijn ogen vaak precies dit soort haastige slordigheid die dingen fout doet gaan. En werkgevers die druk uitoefenen om dingen zo snel en goedkoop mogelijk te doen werken dat natuurlijk sterk in de hand, en dan gaan zelfs de beste mensen fouten maken die ze met wat meer ruimte voor zorgvuldigheid niet hadden gemaakt.
Wat ik zeker niet wil is dat die query mijn netwerk in komt. Dat is hetzelfde als zeggen "laat dat virus maar door, want we hebben antivirus software op alle servers draaien, dus de backend vangt het wel af". Je blokkeert (potentieel) ongewenst gedrag in een zo vroeg mogelijk stadium. En dat is dus niet aan de backend op een database. Dat is security-technisch echt zó fout, zeker bij onvertrouwde queries van onvertrouwde partijen.
Dat ik context verlies is zelden van toepassing. Je maakt prepared statements en filtert alle andere onzin. Daar kun je je applicatie prima op inrichten.
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.
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.
