Fortinet waarschuwt voor zeroday waarmee SQL-injectie op FortiClient mogelijk is

Fortinet heeft een patch uitgebracht voor diverse kwetsbaarheden in uiteenlopende software. Een van de bugs maakt het mogelijk om een SQL-injectie uit te voeren op FortiClient-EMS. Inmiddels is er een proof-of-concept verschenen van die exploit en wordt hij actief misbruikt.

Fortinet waarschuwt in een advisory voor een van de bugs, die het bedrijf zelf trackt als FG-IR-24-007 en die ook bekendstaat als CVE-2023-48788. Die bug krijgt een Kritieke CVSS-score van 9,3, met name omdat aanvallers hem op afstand en zonder authenticatie kunnen uitvoeren. De kwetsbaarheid zit in FortiClientEMS-versies 7.2.0 tot en met 7.2.2 en in versies 7.0.1 tot en met 7.0.10. In versies 7.2.3 en 7.0.11 zijn de kwetsbaarheden opgelost. De bug maakt het mogelijk om een SQL-injectie uit te voeren op apparaten waarop FortiClientEMS draait.

Fortinet zegt dat de bug in het wild wordt misbruikt, maar geeft daar geen details over. Het Nederlandse Digital Trust Center waarschuwt inmiddels ook voor de bug. Daarvan is inmiddels ook een proof-of-concept verschenen, schrijft het DTC, waardoor het in theorie makkelijker is een aanval uit te voeren.

Behalve voor de zeroday waarschuwt Fortinet voor verschillende andere kwetsbaarheden. Een daarvan is FG-IR-23-390 of CVE-2023-47534, die in dezelfde kwetsbare versies van FortiClientEMS zit. Die bug, met een Hoge CVSS-score van 8.7, zit daarnaast in alle versies van FortiClient 6.0, 6.2 en 6.4. Fortinet raadt gebruikers daarvan aan naar een nieuwere versie te migreren. Deze bug is een kwetsbaarheid in de manier waarop elementen in een csv-bestand worden gezet: CWE-1236.

Verder zit er een kwetsbaarheid in FortiManager en FortiAnalyzer: FG-IR-23-304 of CVE-2023-41842. Daarmee kan een aanvaller code uitvoeren op een systeem, maar daarvoor is wel authenticatie nodig. De laatste bug is FG-IR-23-103 of CVE-2023-36554, een kwetsbaarheid in FortiManager. Die bug krijgt een CVSS-score van 7,7, maar is alleen uit te buiten als gebruikers FortiWLM MEA aan hebben staan. Dat gebeurt niet standaard en beheerders kunnen hun systemen beveiligen door deze functie uit te schakelen.

Reacties (78)

[ShatterNL]

Gaat wel lekker bij Fortinet de afgelopen maanden met alle lekken

[Bor]

Daar heb je een goed punt. Het ene lek volgt momenteel het andere op. Lekken kunnen natuurlijk altijd voorkomen maar in de frequentie en met de ernst waar we de laatste tijd naar kijken mag je je wel eens achter je oren gaan krabben als producent van security producten die o.a. bij de grotere bedrijven waaronder binnen de fortune 500 worden ingezet.

Op termijn gaat dit mogelijk klanten kosten. Het imago krijgt een redelijke dreun.

[Reactie gewijzigd door Bor op 22 juli 2024 17:07]

[CH4OS]

Daar heb je een goed punt. Het ene lek volgt momenteel het andere op. Lekken kunnen natuurlijk altijd voorkomen maar in de frequentie en met de ernst waar we de laatste tijd naar kijken mag je je wel eens achter je oren gaan krabben als producent van security producten die o.a. bij de grotere bedrijven waaronder binnen de fortune 500 worden ingezet.

Tja, bij Flash was het natuurlijk niet anders, ook nadat Adobe het overgenomen had. Gelukkig is het intussen verouderde technologie en is dat vervangen door wat anders, hier is dat echter wat lastiger, helaas.

Op termijn gaat dit mogelijk klanten kosten. Het imago krijgt een redelijke dreun.

Niet op termijn, dat doet het nu al.

[InjecTioN]

@Bor sorry hoor, maar wat een onzin. Mensen moeten eens ophouden met op die manier denken. Het beleid is juist goed, anders vonden ze die kwetsbaarheden niet. Gevonden (en gepatchte) kwetsbaarheden maakt een product niet per definitie onveilig. Het maakt een product juist veiliger tot er een nieuw lek gevonden is.

Actieve support bieden en blijven patchen - evenals het openbaar maken van de patches - is juist een transparante manier om te laten zien dat ze er alles aan doen om de apparaten zo veilig als mogelijk te maken.

Ik ken geen ander bedrijf die zo vaak als Fortinet, meestal zelfs proactief, hun lekken dicht. Het is en blijft namelijk software. Dat is door mensen gemaakt en heeft constant updates nodig. Zo is FortiOS van een (uit mijn hoofd) BSD geforkt, waardoor er ook regelmatig packages geüpdatet moeten worden.

Kwetsbaarheden worden overigens alleen gevonden als erop getest wordt. Ik zie daarin niet dat Fortinet een slecht testbeleid heeft, maar juist het tegenovergestelde. Ze vinden wat ze vinden kunnen. Dat wilt dus ook niet zeggen dat de ontwikkeling slecht is, maar alleen dat er kwetsbaarheden gevonden en daadwerkelijk worden.

Je kan veel zeggen over Fortinet. Maar slechte software of slecht beleid op ontwikkeling, testen en transparantie hebben ze niet.

Dat gezegd hebbende: De software blijft “man made”. Kwetsbaarheden vinden ook. Als je security software maakt, zal je veel security kwetsbaarheden moeten patchen. Simple as that! ¯\_(ツ)_/¯

[Reactie gewijzigd door InjecTioN op 22 juli 2024 17:07]

[Bor]

Het beleid is juist goed, anders vonden ze die kwetsbaarheden niet.

Eh veel kwetsbaarheden zijn gevonden door derden, niet door Fortinet zelf. Dat heeft dus niets met het beleid te maken. Als je er ervan uitgaat dat niet elke kwetsbaarheid netjes of tijdig wordt gemeld heb je een nog iets pessimistischer beeld.

Gevonden (en gepatchte) kwetsbaarheden maakt een product niet per definitie onveilig.

Duh... Er is niemand hier die anders beweerd.

Ik ken geen ander bedrijf die zo vaak als Fortinet, meestal zelfs proactief, hun lekken dicht.

Microsoft, Google, Apple en zo ongeveer de meeste professionele bedrijven doen dit. Het punt is hier dat het bij Fortinet de laatste tijd wel heel erg vaak nodig is om te patchen met, afhankelijk van de opstelling, downtime ten gevolge en risico voor de organisatie totdat de patch geïnstalleerd is in productie.

Heb je toevallig enige belangen in Fortinet?

[Reactie gewijzigd door Bor op 22 juli 2024 17:07]

[InjecTioN]

Eh veel kwetsbaarheden zijn gevonden door derden, niet door Fortinet zelf. Dat heeft dus niets met het beleid te maken. Als je er ervan uitgaat dat niet elke kwetsbaarheid netjes of tijdig wordt gemeld heb je een nog iets pessimistischer beeld.

Precies. Zoals bij de meeste software. Daar verschilt het dus niets. Dat is dus geen reden om een Fortinet apparaat niet meer te overwegen.

Microsoft, Google, Apple en zo ongeveer de meeste professionele bedrijven doen dit. Het punt is hier dat het bij Fortinet de laatste tijd wel heel erg vaak nodig is om te patchen met, afhankelijk van de opstelling, downtime ten gevolge en risico voor de organisatie totdat de patch geïnstalleerd is in productie.

De frequentie is niet relevant. Het gaat erom hoe - en dàt - het opgepakt wordt wanneer er kwetsbaarheden gevonden worden.

Wanneer een bedrijf hoge eisen heeft aan de netwerk (dan wel internet) -connectie, dan dient een bedrijf ook te betalen voor een fatsoenlijke HA opstelling. Dat is dus puur op basis van wat het desbetreffende bedrijf wilt besteden/het waard vindt. Die downtime is dus geen excuus om een patch niet door te voeren wanneer de veiligheid in het gedrang is.

[Bor]

Precies. Zoals bij de meeste software. Daar verschilt het dus niets. Dat is dus geen reden om een Fortinet apparaat niet meer te overwegen.

O, daar kan zeker reden voor zijn. Fortinet producten dienen ter beveiliging van de infrastructuur en scheiden o.a. het interne netwerk van het internet. Het is een product dat wordt ingezet in er mult layered defence aanpak. Een product als dit behoort zo veilig mogelijk te zijn en daar kom je op de frequentie en impact van de lekken de laatste tijd. Beide zijn voor een security product lastig te voorkomen, zeker wanneer je dit vergelijkt met de concurrentie.

De frequentie is niet relevant

De frequentie is zeer relevant. Je kan niet zo maar elke patch doorvoeren in productie. Daar gaat doorgaans test werk en ene risico analyse, CAB verzoeken etc aan vooraf. Hoe frequenter hoe kostbaarder. Liever weinig tot geen kwetsbaarheden dan frequente kwetsbaarheden met ene hoog risico zoals we de laatste tijd bij Fortinet zien.

[Reactie gewijzigd door Bor op 22 juli 2024 17:07]

[InjecTioN]

Het is geen last line of defense, en zo mag het ook zeker niet gezien worden. Wanneer security een ding is, moet je ervan uit gaan dat het een permanent doelwit is voor een hack. Zeker wanneer het bedrijf een groot aandeel van de markt in handen heeft.

Het apparaat is zo veilig als mogelijk inderdaad. En geen last line of defense. Dergelijke apparatuur koppel je ook niet aan je interne netwerk (SSO). Net zoals de backup voorziening. Anders ben je per definitie al nat bij de eerste hack die er doorheen komt.

Ik heb het gevoel dat je vergeet dat nieuwe functionaliteit ook nieuwe kwetsbaarheden met zich mee kan brengen. Die kwetsbaarheden krijg je niet altijd gevonden, omdat je als ontwikkelaar van Fortinet apparatuur/software ook afhankelijk bent van 3rd party packages en hardware die alsnog grondig getest dienen te worden. Ze vinden daar niet iedere keer zelf het wiel opnieuw uit.

Ik snap je standpunt, maar een wijzigingsbeheer doorlopen voor een nieuwe firmware update is het moeilijkste niet. Dat doe je altijd met een minimum van 2 bekwame personen. Daarbij zorg je er dan voor dat de opstelling niet de functionaliteit schaadt, of je mitigerende maatregelen neemt wanneer een patch op software niveau niet mogelijk is.

[Bor]

Je zet doorgaans in op een meerlaags beveiliging. Een Fortinet device is echter doorgaans een perimeter device. Die hoort zo veilig mogelik te zijn. SSO heeft niet niets mee van doen.

[Bor]

Wanneer een bedrijf hoge eisen heeft aan de netwerk (dan wel internet) -connectie, dan dient een bedrijf ook te betalen voor een fatsoenlijke HA opstelling.

Een HA opstelling bouw je doorgaans met twee dezelfde productie. Die zijn dan beide kwetsbaar

[InjecTioN]

Mitigerende maatregelen tegen een service die gecompromitteerd is, is altijd van belang. En dat zal bij ieder product zo werken. Zo is het vaak al verstandig om een groot doelwit als SSL-VPN, wat een erg groot doelwit is ivm de complexiteit, te vervangen door bijvoorbeeld IPsec. En dat betreft alleen VPN. Zo heb je ook nog het ZTNA concept, wat in veel situaties een prima toevoeging is. Oók mogelijk vanuit een Fortinet apparaat.

[Bor]

Je kan veel zeggen over Fortinet. Maar slechte software of slecht beleid op ontwikkeling, testen en transparantie hebben ze niet.

Goede software bevat geen tot zo weinig mogelijk security issues, zeker bij een security product. Het aantal lekken dat na productierelease wordt gevonden zegt wel degelijk iets over kwaliteit en testprocedures.

[InjecTioN]

Dat is gewoon onmogelijk om te zeggen. “Veilig” is een concept dat volledig op basis van je perspectief is.

Er worden iedere dag nieuwe technieken, technologieën en lekken gevonden in apparatuur en software, die niet voorzien waren. Zo heeft zelfs Microsoft in de loop der jaren een aantal zero-days moeten repareren, die nog lijken te stammen uit het Windows 95 tijdperk. Het gaat om de use case en of iemand er tegenaan loopt. Dus: perspectief.

[Shadow_Fokx]

je kan het ook van de goeie kant bekijken, als ze ze vinden dan zal er goed onderzoek gedaan worden, beter dit als dat het er in blijft zitten en niemand ziet de lekken

[Bor]

Bij die stelling is het belangrijk onderscheid te maken tussen de lekken die Fortinet zelf vindt en verhelpt en de lekken die door derden worden gevonden (dus na quality control etc).

[crazyboy01]

Het is zelfs zo dat de naam aardig bekender is geworden op grotere schaal in die tijd, puur en alleen vanwege alle lekken en schandalen. Veel van mijn collega's kennen het in ieder geval hierdoor. En dat is nou nét de negatieve reclame die je níét wilt.

[daanb14]

Het is ook wel een erg hoge boom die daardoor veel wind kan vangen. Fortinet is met afstand marktleider als het gaat om Next Generation Firewalls.

Next Generation Firewalls zijn daarbij ook nog eens enorm interessante targets, omdat zij erg centraal in het netwerk zitten. Je VLANs komen er binnen, je IPsec-tunnels komen er binnen en ook je VPN-clients en ZTNA-clients komen er binnen. Het breachen van een firewall levert dus een enorm potentieel om erg snel lateral movement uit te kunnen voeren in een netwerk.

Nou gaat het in dit specifieke voorbeeld om de FortiClient EMS. Dat is de Enterprise Management Server, waarmee je de anti-malware, remote access en ZTNA-instellingen van de FortiClients beheert. Maar veruit de meeste vulnerabilities zijn echt wel gericht op FortiGate, omdat het zo'n interessante target is om de hierboven genoemde reden.

Het belangrijkste blijft echter gewoon om je software up-to-date te houden. De hier genoemde vulnerability met FG-IR-24-007 is uitgekomen op 22 februari. De versie die deze vulnerability fixt, EMS 7.0.11 is uitgekomen op 31 januari! Het Proof of Concept is als ik Bleeping Computer lees gisteren uitgekomen. Hier was dus ruimschoots tijd genoeg om te patchen.

Wat daarnaast een positieve kant is dat aan dit voorbeeld, maar ook andere lekken mede door of alleen door Fortinet zelf zijn gevonden en zij dus wel transparant zijn over de kwetsbaarheden die zij zelf intern vinden.

[Reactie gewijzigd door daanb14 op 22 juli 2024 17:07]

[theduke1989]

klopt, wij patchen al langere tijd alle issues. gisteren nog eentje moeten doen dat was deze.

[Frame164]

Deze opmerking en de daarop volgende discussie is letterlijk hetzelfde bij ieder topic over vulnerabilities bij fortinet.

[Erikkamm]

Ach, dit is eigenlijk een storm in een glas water. Als het goed is zit iedereen die b.v. Op de lijn 7.2.x draait al sinds februari op 7.2.7, want er waren al andere ernstige kwetsbaarheden die in 7.2.7 zijn opgelost. Het is nu al de 2e keer ik korte tijd dat kwetsbaarheden in een versie wordt bekendgemaakt die je al niet meer zou moeten gebruiken i.v.m. andere lekken. De moraal is dus, blijf niet te ver achter met updaten. En het updaten van een Fortigate is nu ook weer niet heel ingewikkeld. En als je in een cluster draait al helemaal niet zo’n probleem. Hooguit dat je onderbreking hebt in udp en sslvpn. Maar slechts voor korte tijd. Dus er is altijd wel een moment om te upgraden.
Windows moet je ook minimaal elke maand updaten. Dat kan bij servers veel vervelender zijn.

[cariolive23]

SQL injection anno 2024, hoe is het mogelijk. Wie heeft daar zitten slapen? Gebrekkige opleiding, gebrekkige code review en gebrekkig testen. Wanneer ze zélfs last hebben van SQL injection, dan moet er nog wel meer fout zitten. Want dit is eenvoudig te signaleren, andere lekken zijn moeilijker te vinden

[Bor]

Het komt nog heel veel voor helaas. Injection staat nog steeds in de OWASP top 10 (A03:2021-Injection)

[maevian]

Lawrence Systems had hier overlaatst nog een goede uitleg over.
https://www.youtube.com/live/4AWJz2OK-JM?si=zYpQp3EUQGhQL_RR

Grote bedrijven bouwen heel wat technical debt op, en vaak is opschonen veel winstgevender dan iets veilig van de grond opnieuw te bouwen.

[Memori]

Het kan nog wel eens voorkomen door onvoorzichtigheid. Natuurlijk kan je er voor zorgen dat je alles standaard door een escape filter gooit, of altijd stored procedures prepared statements gebruikt. Zou ik ook gewoon aanraden. Maar er zijn situaties waar dat helemaal niet nodig is.

Edit: Ik wil toelichten dat als je een object hebt dat zich als een string kan laten parsen, en dat object gegarandeerd geen SQL-injectie achtige karakters heeft, escaping niet nodig is.

[Reactie gewijzigd door Memori op 22 juli 2024 17:07]

[cariolive23]

of altijd stored procedures gebruikt.

Dat is gewoon code, maar dan in de database zelf, en ook daarin kun je SQL injection veroorzaken.

Persoonlijk ben ik wel een groot voorstander van het gebruik van stored procedures en functions, je maakt een soort van API waar de applicaties gebruik van kunnen maken. Maakt de applicaties eenvoudiger en geeft je de mogelijkheid om de database te optimaliseren voor elke applicatie die er gebruik van maakt, zonder dat er aanpassingen in deze applicaties nodig zijn.

[Memori]

Je hebt gelijk, ik bedoelde dus prepared statements.

[The Zep Man]

Het kan nog wel eens voorkomen door onvoorzichtigheid.

Onvoorzichtigheid met producten die netwerksegmenten grenzend aan het internet scheiden? Onverstandig.

[jochem4207]

Zo lang bedrijven nog te complex werken, managers te veel willen managen en iedereen voor dubbeltje op de eerste rang wil zitten.

[Frame164]

Jij doet alles wat jouw manager zegt dat je moet doen? En je doet ook alleen maar de dingen die jouw Manager jou vraagt te doen? Ipv dat je je jouw werk doet vanuit je professionele competenties?

[SuperDre]

Nou, je kunt het ook anders zien, wie ben ik om mijn manager tegen te spreken? Als ik heb aangegeven wat de gevolgen kunnen zijn van bepaalde aanpassingen en dat het bv langer duurt om het 'goed' te doen, maar de manager beslist om toch de korte weg te nemen, dan ben ik wel degelijk gewoon professioneel competent bezig. Ik zou dat juist niet zijn als ik toch tegendraads ga zijn.

[divvid]

En daar gaat het dus fout. De manager van je manager zou hier moeten ingrijpen

[SuperDre]

Ja ja, en nu terug naar de realiteit. Het blijft sowieso altijd afwegen, tijd is gewoon geld, dus als iets op de 'goede' manier maanden kost, maar op de 'foute' manier uren, dan is de keuze voor een vol traject snel gemaakt (overdreven verschil natuurlijk hier, want in realiteit zal het verschil niet zo extreem zijn).
Naast dat er dan wel een manager boven de manager moet zitten, en juist die manager dus misschien wel de beslissing heeft genomen.

[divvid]

Vroeg of laat krijg je dan die foute beslissing van boven in jouw schoenen geschoven. Tijd voor een nieuwe uitdaging voordat dat gebeurt wellicht?

[SuperDre]

En waarom zou ik dan een nieuwe uitdaging gaan zoeken als ik een 'foute' beslissing moet uitvoeren? Dat gebeurd bij elk bedrijf wel eens, en dan zul je dus niet echt lang bij veel bedrijven blijven werken en dus veel van baan veranderen. Iemand die om elke scheet vindt dat die dan maar ergens anders moet gaan werken zou ik ook niet eens in mijn team willen, want dat is verre van een teamplayer en waar je dus niets aan hebt omdat die niet te vertrouwen is of die zijn of haar werk wel doet. Wel als manager wil je door de developer op gewezen worden als mogelijk iets fout zou gaan, maar het is dan aan de manager om de knoop door te hakken. Aan iemand die dan niets zou zeggen heb je ook evenmin wat aan. Als je nu keer op keer wordt genegeerd, tja, DAN is het wel misschien eens tijd om op zoek te gaan naar een andere werkgever want dan zul je je ook zeker niet op je plek daar thuisvoelen. Laten we wel realistisch blijven, jij bent niet de baas, anders had je maar je eigen bedrijf/software moeten starten, dan mag jij helemaal zelf beslissen wat jij met het budget doet.

[Reactie gewijzigd door SuperDre op 22 juli 2024 17:07]

[divvid]

Als je nu keer op keer wordt genegeerd, tja, DAN is het wel misschien eens tijd om op zoek te gaan naar een andere werkgever

Zo kwam het wel over. Helaas al te vaak meegemaakt dat management een shortcut nam en de problemen uiteindelijk op het bordje van de developer geschoven worden.

[SuperDre]

En daarom dus wel altijd zorgen dat je bezwaren gedocumenteerd hebt zodat ze jou niet achteraf er op aan kunnen kijken dat je het niet verteld had. Dat jij het uiteindelijk toch weer moet oplossen is gewoon part of the job waar je voor betaalt wordt.

[The Zep Man]

En programmeurs geen verantwoording hoeven af te leggen over slechte kwaliteit werk. "Nee" is ook een antwoord.

[Frame164]

Dat inderdaad. Mensen die zich verschuilen achter managers blijven nooit lang in mijn team. Ik vraag die mensen omdat ze iets kunnen en weten. Niet omdat je handjes hebben die iets kunnen intypen.

[fRiEtJeSaTe]

Geldt dit ook voor de gratis Forticlient (VPN) applicatie?

[daanb14]

Nee. Het gaat hier puur om de Enterprise Management Server die supported FortiClients beheert en niet om de FortiClients zelf ongeacht of zij betaald of gratis zijn.

[Insehh]

En dan ook alleen aan de server side, niet client side.

[jimshatt]

Maar als de server compromised is dan volgen de clients niet lang daarna? Tenminste, als EMS betekent wat ik denk dat het betekent.

[dasiro]

de clients moet je niet patchen tegen een SQL-inject op de server. Wat die server dan hierdoor allemaal naar de clients kan sturen, dàt is wat het pas gevaarlijk maakt, want je EMS moet per definitie ook publiekelijk bereikbaar zijn, anders kan je geen verbinding opbouwen. Gelukkig hebben we een tijd geleden al alles gepatched naar versies die nu niet geïmpacteerd zijn.

[MrRobot]

De titel klopt denk ik niet helemaal, de kwetsbaarheid zit in het management systeem, niet de client.
FortiClient EMS - Enterprise Management Server

[Reactie gewijzigd door MrRobot op 22 juli 2024 17:07]

[eric.1]

SQL-injectie is wel een heel basale kwetsbaarheid. Een van de eerste dingen wat je tegenkomt in opleidingen...tenminste, een jaar of tien terug. Toen was het al de norm om input, zeker welke je gebruikt in queries, nooit maar dan ook echt nooit te vertrouwen.

Maar goed, een bug sluipt er al snel in.

[MartijnHavinga]

Had laatst nog een portaal waarbij mijn login niet werkte, na uitzoeken kwam men er achter dat mijn gebruikersnaam niet geaccepteerd werdt omdat er "having" in voorkwam. Nu wil ik niet gelijk zeggen dat het desbetreffende portaal kwetsbaar is voor sql injectie, maar een dusdanige restrictie op geldige input zet je wel aan het denken over de kwaliteit van de backend van het systeem...

[Wafeltje]

Waarom komt dit nu pas op tweakers? Dit nieuwsbericht is al 10 dagen oud!

Ja, het DTC heeft er een artikel aan gewijd vandaag, maar ook 10 dagen geleden al. De minimale upgrade voor EMS betreft ook niet eens de meest recente. 7.2.3 die nu wordt aanbevolen, is volgens google al uit januari.

@ShatterNL : Ja, er zijn veel lekken, maar het aantal updates wat uit komt lijkt op deze manier meer dan het daadwerkelijk is. Fortinet is een grote jongen in security wereld, maar voor de media nog een kleintje. Ook is de forticlient EMS 1 van de minder populaire producten van ze, en dat merk je ook wel met hoeveel personeel ze erop kunnen zetten. De lijst met known issues is altijd lang, en duurt meerdere patches voordat sommige belangrijke zaken opgelost worden.

[nout77]

Voor wie niet direct doorheeft waar DTC (Digital Trust Center) voor staat, hier worden kritieke veiligheidslekken gepubliceerd door het Ministerie van Economische Zaken: https://www.digitaltrustcenter.nl/nieuws
Ook eenvoudig via RSS op te abonneren.

Zij plaatsen deze berichten zo snel mogelijk wanneer het bekend is geworden, Tweakers plaats uiteraard niet alle lekken en soms dus ook wat later.

[Reactie gewijzigd door nout77 op 22 juli 2024 17:07]

[satya]

Wat is het verschil met het NCSC die ook advisories uitgeeft?

Ben nogal gecharmeerd van Vulndb, je kunt voor jezelf een selectie maken en krijgt een email van events binnen je eigen interesse.

[SuperDre]

Zonder SQL zul je niet ver komen tegenwoordig, let wel, zaken als Link is onderliggend ook gewoon SQL. Denk dat je dan eerder bedoelt, rechtstreeks SQL gebruiken bij user input.

[krflyer]

SQL injectie, aan de ene kant knullig aan de andere kant had iedereen meer dan 20 jaar terug moeten stoppen met SQL.

Huh? Weet je wel waarover je hebt? En heb je een alternatief voorstel dan? Dan kunnen wij SQL mensen even opletten en leren.

[cricque]

Stored procedure or GTFO ?

Serieus ga jij voor alles stored procedures schrijven ? Een database dient om dingen te bewaren. Logica in een database is not done. Wel resultaten berekenen ofzo. Maar Je logica zit in je programma. Je database "dom" houden is het simpelste wat er is

En trouwens als je een ORM gebruikt dan is er al sql injection protection. Enja ORM queries zijn niet altijd de meest performante queries. Maar bijna elk ORM laat je ook vrij queries schrijven en dan params te gebruiken waar ze wel checken om SQL injection.

Als iemand alles in stored procedures wilt steken dan ben ik direct weg.

[cariolive23]

Logica in een database is not done. Wel resultaten berekenen ofzo. Maar Je logica zit in je programma. Je database "dom" houden is het simpelste wat er is

Het is voor jou misschien not done. De rest van de wereld mag dat gelukkig toch echt zelf bepalen.

En wat is logica? Het gebruik van data types is al logica, een int kan geen waarde "appel" bevatten, zal een foutmelding opleveren. Volgens jou mag dat niet, want het is logica en dus mag je geen integers gebruiken. Of welk ander datatype dan ook. Unique constraint? Nope, is logica. Oh, hoe ga je dan met concurrency om? Dan moet je wel iedere keer de tabel locken, opzoeken of een waarde al bevat en zo niet, dan het nieuwe record aanmaken en de lock weer verwijderen. Performance kun je wel op je buik schrijven.

In jouw wereld zul je eveneens 25TB uit de database moeten trekken om binnen jouw applicatie te gaan zoeken naar het juiste record in deze berg van 25TB. Of de laatste datum opvragen wanneer een bepaalde klant is ingelogd, etc. etc.

Een DBMS bevat meer logica en meer code, dan jij en ik samen ooit in ons leven hebben geschreven of gaan schrijven. En nu wil jij in jouw eigen code alle logica gaan zetten? Dream on, daarvoor leef je niet lang genoeg. Al wordt je 1000 jaar oud.

Alles in stored procedures is mogelijk, maar een keuze van de organisatie. Wanneer jij daar niet bij past, dan niet, zoek je een andere opdrachtgever.

[nullbyte]

Het is voor jou misschien not done. De rest van de wereld mag dat gelukkig toch echt zelf bepalen.

Schijnt inderdaad wel voor te komen.

[Reactie gewijzigd door nullbyte op 22 juli 2024 17:07]

[cricque]

Dus om iets op te halen heb je een stored procedure nodig ? JIj bent ook gods geschenk aan de database wereld volgens mij. Ik heb voor fortune 500 bedrijven gewerkt, overheden, grote organisaties, kleine organisaties. Ik heb nog nooit zo een idiote commentaar gehoord/gelezen/gezien ... alles moet een stored procedure zijn. Ik heb nooit iets gezegd over een unique constraint.

[cariolive23]

Nee, ik zeg niet dat álles in stored procedures moet. Ik zeg alleen dat het een optie is.

Ik zeg wel dat het een ronduit idioot idee is om geen enkele vorm van logica in de database te hebben. Of je moet terug willen naar een CSV-bestandje waarmee je leest en schrijft. Iedere andere vorm van dbms bevat namelijk logica. Of je nou Oracle, MongoDB of Neo4j gebruikt, het is logica, logica en nog meer logica. En één van die voorbeelden van logica in de database, is een unique constraint.

[GeroldM]

Wat ik uit het verhaal van @cricque begreep was dat je van zo weinig mogelijk gebruik maakt van opties en logica die is ingebouwd in de database van je keuze. Dat kun je vaak zelf beter/sneller.

Je bent daarmee gelijk van vendor-lockin af en de logica/opties in de database kan op zich wel competent zijn geschreven, het onderhoud daarop volgt de wensen en noden van veel grotere klanten dan jij ooit zult zijn op het tijdsbestek van hun betalingen aan de de database software maker.

Komen jouw noden en wensen overeen met die van de veel grotere klanten, dan pas ga je overwegen of het niet beter is om de optie/logica van de database te gebruiken i.p.v. zelf je eigen opties/logica te schrijven.

Bovenstaande geld echter alleen met database makers die hun klanten voorop hebben staan. Heb je al eens met Oracle RDBMS gewerkt? Zij zitten namelijk al vrolijk hun geld te tellen wat zij uit hun eigen audits ende daaruit volgende gebreken van jouw/je bedrijf aftroggelen. Ben je een beetje grotere klant, dan gaat dat al gauw over 20.000 Euro of meer. Zulke bedragen, dat vindt geen enkel IT budget leuk.

Ja, het doet in het begin "zeer" wanneer je zoveel mogelijk zelf schrijft. Maar je word er wel competent van, en je blijft complete controle houden, je kunt aanpassingen maken die je maar wil, op het moment dat je dat wil en je kan gauw overstappen van de ene naar de anadere database maker, zonder alteveel zorgen.

De kern achter de post van @cricque, 'zoveel mogelijk zelf doen', daar kan ik me wel in vinden. Het is uiteindelijk ook gemoedsrust als je weet dat je zo kan overstappen van de ene naar de anadere databasemaker. Dat houd de database maker en jezelf eerlijk.

Dan zou je het argument 'waarom het wiel opnieuw uitvinden?' wel tegen kunnen zetten. Doe je dat echter goed, dan heb je wel meteen de mogelijkheid om de 'rims in rims' uit te vinden, in plaats van te moeten wachten op een nieuw wieldeksel die je na veel gesmeek en gebedel van je database maker krijgt aangelevert. Beide opties kosten echter net zoveel.

[SuperDre]

Wat een onzin, uiteindelijk wordt die querytaal omgezet naar binary commands. In feite wat je zegt is dat we geen programmeertalen meer moeten gebruiken en alles rechtstreeks zelf in binary moeten doen, dus geen compilers meer want dat tikken we zelf.

[Pinkys Brain]

Nee, ik zeg dat er in parameter strings geen speciale karakters moeten bestaan, omdat er altijd een lengte mee moet worden gegeven. Als er dan zeg een ' inzit, hoeft die niet ge-escaped te worden ... je kan ook niks escapen want \ is dan ook geen speciaal karakter.

Als niks ge-escaped moet worden, kan je het ook niet vergeten.

Injectie is niet alleen een SQL probleem. Shell, HTML, XML en zelfs bij printf heeft het tot exploits geleid. Het is een klasse van fouten die heel vaak exploiteerbaar is, net zoals buffer overflows dat waren (nu wat minder door alle mitigatie van OSen). Net als buffer overflows moet je dit soort klasses eigenlijk vermijden op taal niveau.

[Reactie gewijzigd door Pinkys Brain op 22 juli 2024 17:07]

[SuperDre]

Als er geen escape is, hoe doe je dan LIKE queries waar je moet escapen om gebruik van wildcards te kunnen doen?

[Pinkys Brain]

In een editor gebruik je een toets combinatie om de wildcards in te voeren en die worden dan weergegeven in een aparte kleur. In de query taal worden tekst strings gecodeerd met lengtes.

Dus in plaats van zeg '%\%blah' krijg je %%blah met twee verschillende kleuren in de editor, wat dan bijv. in de query taal iets kan zijn van %S5%blah. De lengte van de String is gecodeerd, dus %blah hoeft niet geparsed te worden en je hebt geen escape nodig.

Als je dan in een programma een parameter in een query douwt is het veel moeilijker om het fout te doen omdat daar ook alle strings lengtes hebben. Uiteraard gebruik je in de programmeertaal geen null ended strings, want dat was de original sin ... het ging vanaf het begin fout.

PS. ik verwacht niet dat de industrie het roer nu nog omgooit, net als geheugen veiligheid had dit tientallen jaren terug al onderkent moeten worden toen de exploits binnen bleven stromen. Nu is het de moeite niet meer waard, laat AI het maar fixen.

[Reactie gewijzigd door Pinkys Brain op 22 juli 2024 17:07]

[SuperDre]

met twee verschillende kleuren in de editor

Ugh, nee dank je, want dat betekent dat je dus volledig afhankelijk bent van de editor, en uiteindelijk moet je dan nog steeds user-input controleren, want daar zit nu net het hele probleem. In principe als je user-input via parameters door geeft aan de query zou er niets aan de hand moeten zijn, tenzij er wat fout is aan de SQL library die de parameters afhandelt, maar dan is het in principe alleen de SQL-library fixen en niet elke plek waar je user-input doorgeeft.

[Pinkys Brain]

Het gaat niet fout bij het schrijven van de query, het gaat fout wanneer data in de query word gestopt. Als SQL alleen werd gebruikt met geschreven queries ipv. geconstrueerde queries was er niets aan de hand.

Om te zorgen dat het makkelijk is om het goed te doen, moet je de parameters expliciet scheiden van de operators, niet impliciet zoals dat gebeurt bij plain text interfaces. Een plain text interface hoort alleen bedoeld te zijn voor interactief gebruik, het moment dat je het gebruikt met potentieel vijandige input blijft het fout gaan, get good is te optimistisch.

[Reactie gewijzigd door Pinkys Brain op 22 juli 2024 17:07]

[SuperDre]

zucht. zoals ik dus al aangaf, als je user-input doorgeeft aan de query via parameters zal er in principe niets fout gaan tenzij dus de SQL-library die de user-input doorgeeft aan de query via parameter iets fout doet.

user-input zal altijd 'plain text' zijn en je zult altijd die dus naar je query moeten leiden. Zelfs rechtstreeks de user-input via een functie die escapen etc afhandelt moet geen probleem zijn, behalve als die functie iets dus niet goed doet.
Of je nu dus iets doet als 'WHERE Blah=' + SqlString(MyUserInpu) of 'WHERE Blah=@@MyParameter@@' en dan Parameters('MyParameter') = MyUserInput, er zal altijd een punt zijn waar de userinput omgezet moet worden in iets dat in de query uitgevoerd moet worden (of dus rechstreeks uit een userinput veld in de database komt).
Je kunt dan vanalles bedenken om SQL-injection tegen te gaan, maar uiteindelijk kom je gewoon op hetzelfde uit, of het wordt niet meer leesbaar en onderhoudbaar.

[Pinkys Brain]

Nee user input voor SQL mag geen plain text zijn. De taal als geheel is plain text maar de parameters zijn dat niet. In plain text mogen namelijk gewoon ', %, / etc etc zitten, zonder escapes, in de parameters niet.

User input voor SQL moet gefilterd of escaped zijn ... dat gaat fout en blijft fout gaan.

De oplossing is om met elke parameter een lengte mee te geven, dan maakt het niet uit wat er in zit. Plain text, een string van meerdere nulls, een SQL query ... niks binnen die lengte zal tot injectie leiden, want niks binnen die lengte word geparsed.

Maar dan is de taal niet echt plain text meer, want niemand kan handmatig lengtes bijhouden.

[Reactie gewijzigd door Pinkys Brain op 22 juli 2024 17:07]

[SuperDre]

Zoals ik al aangaf, dan kun je dus geen LIKE gebruiken, want dat is dus user-input waar wildcard characters in zitten die altijd geparsed moeten worden.
En escapen etc hoeft echt geen probleem te zijn mits je maar de correcte functies/parameters gebruikt en niet zelf gewoon handmatig "blah='" + myuserinput + "'" doet. En parameters handelt juist dus dat escapen al voor jou af. Geen gezever met lengtes mee moeten geven (want is het dan byte lengte of string lengte).

[Pinkys Brain]

Een veilige taal laat geen wildcards meer toe in tekst want de taal is niet meer plain text.

Ipv '%\%blah' is het in een veilige taal %S5%blah, in je editor kan het er nog uitzien als een infix wildcard (met kleur codering) maar in de echte taal is de string+lengte expliciet gescheiden van de wildcards en kan de string alles bevatten, zonder escapen.

Escapen gaat fout, blijft fout gaan, get good werkt niet. Het werkte niet voor C en het werkt niet voor SQL/shell/HTML/XML/printf/etc. Dat IT'ers plain text API's gebruiken met potentieel vijandige data is een heel dure grap voor de economie.

[SuperDre]

Man man wat heb jij toch oogkleppen op. Want jouw oplossing lost niets op. Jouw tekst moet nog steeds geparsed worden, en is zo gebruikersonvriendelijk als de pest. Escapen is totaal geen probleem. En zoals ik al aamgaf, is jouw lengte een byte lengte of een tekst lengte, want een letter kan uit meerdere bytes bestaan en op zo'n manier zal er dus ook met jouw methode wel een manier te vinden zijn om een vorm van SQL injection te doen, want ook jouw methode is compleet afhankelijk van dat een editor zaken voor jouw afhandelt.

[Pinkys Brain]

De text van de query moet geparsed worden, de tekst van de blah string niet. Na S5 kopieert de parser 5 bytes en verspringt (lengte natuurlijk altijd in bytes, niet karakters, neem hier even ASCII aan). De parser zal nooit naar de inhoud van die 5 bytes kijken, dat mag de engine doen.

De engine op zijn beurt zal nooit gaat zitten zoeken naar wildcards of escapes of instructies in die 5 bytes, want de engine weet dat het puur een string is om te matchen.

Een lengte berekening van een string hoef je maar een keer goed te doen in een editor/scripting-taal. Voor escapen/de-escapen word continu het wiel opnieuw foutief uitgevonden.

PS. Het is ook wel grappig dat webprogrammeurs vaak filteren en escapen. Het is allemaal niet zo simpel als het over meerdere lagen gaat, het is veel te makkelijk om per ongeluk iets te vroeg te de-escapen etc. Als IT lang geleden op string+lengte had gestandardiseerd voor alle tekst argumenten had het wel simpel geweest (zowel in code, als in markup taal, als in APIs).

[Reactie gewijzigd door Pinkys Brain op 22 juli 2024 17:07]

[SuperDre]

En hoe doe je dan dus wildcards? Niet. Hoe doe je dan deels zoeken? Niet.
Wat jij voorstelt is geen realistische/gebruikervriendelijke oplossing, maar zeer onpractisch, en lost dus niets op. Jouw tekststring moet ook nog steeds geparsed worden, en wordt vooral complex met multibyte characters. Ik ben blij dat we niet zo'n onpractisch systeem hebben. Ik weet zeker als het daar ooit mee begonnen zou zijn al heel snel vervangen zou worden door de systematiek van nu.

[Pinkys Brain]

In het voorbeeld %S5%blah is de eerste % een wildcard en de tweede een deel van de 5 byte ASCII string.
Of S4blah_S5%blah, waar _ de wildcard is.

Maar dat is op een niveau waar je als mens niet mee bezig bent wanneer je een query schrijft. De mens ziet het in kleur, of bold/italic in de editor ... wat je wil, zolang de signalering van wat tekst is en wat wildcard maar out-of-band is van plain text.

Behalve exploits, nog een voorbeeldje waar de plain text bias toe leid ... base64, nee dat is praktisch.

[CH4OS]

Nee, de database moet doen waar de database goed in is: op een gestructureerde wijze data opslaan en bewaren, meer niet. De rest is logica voor de applicatie. Je gaat geen applicatie logica in een database proppen, zo gauw je dat doet, ben je flexibiliteit kwijt en kun je niet zomaar migreren naar een nieuwe versie van de database of naar een ander RDBMS.

Geen speciale karakters in strings en er is geen injectie. Maar dat moet dan van top tot bodem op die manier gedaan worden, niet alleen SQL. Alles is van top tot bodem fout. Het begon met null in strings en het werd alleen maar erger.

Die dus eruit gefilterd moeten worden door de applicatie, dat laat je niet de database zelf doen. In de database sla je zoals gezegd, alleen de gestructureerde data sla je op.

Een lege string (null in string) is dus ook iets wat de applicatie moet afvangen, niet de database. Het is de verantwoordelijkheid van de applicatie om de data/objecten valide te houden voor zichzelf, niet de database.

[Reactie gewijzigd door CH4OS op 22 juli 2024 17:07]

[Pinkys Brain]

Eruit filteren gaat vaak fout, de huidige exploit het laatste voorbeeld is. Get Gud werkt niet gud.

De oplossing zou zijn geweest om te zorgen dat er niks uitgefilterd hoeft te worden. Als er geen speciale karakters zijn die niet in een string mogen zitten kunnen er geen speciale karakters voor injectie zorgen. Maar deze discussie is veel te laat, dit word niet opgelost voordat het irrelevant is.

[CH4OS]

Eruit filteren gaat vaak fout, de huidige exploit het laatste voorbeeld is. Get Gud werkt niet gud.

Als het op applicatie niveau al fout gaat volgens jou, dan kan het ook fout gaan op database niveau (en zelfs in de stored procedure).

De oplossing zou zijn geweest om te zorgen dat er niks uitgefilterd hoeft te worden.

Sorry? User input maar vertrouwen? Dacht het niet! Altijd filteren en checken, zo kaal mogelijk de data opslaan.

Als er geen speciale karakters zijn die niet in een string mogen zitten kunnen er geen speciale karakters voor injectie zorgen.

Die speciale karakters zijn niet zo speciaal, je moet ze er alleen wel eruit filteren, maar dat moet de applicatie dus al doen, niet de database. Nogmaals, de applicatie is verantwoordelijk voor zijn data, de database is alleen verantwoordelijk voor het opslaan ervan.

[Reactie gewijzigd door CH4OS op 22 juli 2024 17:07]

[Pinkys Brain]

De database zal nooit een byte string (blob) als query interpreteren tenzij je hem exec'd. Het gaat mij om de query taal.

Sorry? User input maar vertrouwen? Dacht het niet! Altijd filteren en checken, zo kaal mogelijk de data opslaan.

Oftewel get good. Maar dat was klaarblijkelijk te optimistisch in dit geval.

Als er geen speciale karakters in een string kunnen zitten, omdat de string doorgegeven word met lengte en niet geinterpreteerd hoeft te worden, hoef je niet optimistisch te wezen. De query taal is verantwoordelijk om exploitable fouten moeilijk te maken.