image

MITRE's Top 25 gevaarlijkste kwetsbaarheden gepubliceerd: top 3 onveranderd

donderdag 29 juni 2023, 17:22 door Redactie, 10 reacties
Laatst bijgewerkt: 30-06-2023, 10:46

De MITRE Corporation heeft weer de Top 25 van gevaarlijkste kwetsbaarheden gepubliceerd en de top 3 is ten opzichte van vorig jaar onveranderd. Wederom staat "out-of-bounds write" op de eerste plek, gevolgd door cross-site scripting en SQL Injection. MITRE is de organisatie achter het Common Vulnerabilities and Exposures (CVE) systeem om kwetsbaarheden mee te identificeren.

De organisatie stelt jaarlijks een Top 25 vast van gevaarlijke kwetsbaarheden die veel in software voorkomen, eenvoudig zijn te vinden en misbruiken, en aanvallers de mogelijkheid geven om systemen volledig over te nemen, data te stelen of een denial of service uit te voeren. Volgens MITRE biedt de Top 25 professionals een praktische en handige bron om risico's te mitigeren. Het gaat dan om programmeurs, testers, gebruikers, projectmanagers en beveiligingsonderzoekers.

De Top 25 is gebaseerd op duizenden kwetsbaarheden die in 2021 en 2022 werden gevonden. Vervolgens werd er een scoreformule gebruikt om de ranking van elke kwetsbaarheid te bepalen. Deze formule kijkt hoe vaak de betreffende kwetsbaarheid voorkomt en de beoogde impact wanneer die wordt misbruikt. Dan staat wederom out-of-bounds write bovenaan. Via deze klasse van kwetsbaarheden is het mogelijk voor een aanvaller om een applicatie te laten crashen of code op het systeem uit te voeren.

De grootste stijgers dit jaar waren improper privilege management, incorrecte autorisatie, ontbrekende autorisatie en Use After Free. Problemen zoals hard-coded wachtwoorden en incorrecte standaardpermissies werden juist minder vaak waargenomen en daalden een aantal plekken in het overzicht.

Image

Reacties (10)
29-06-2023, 17:37 door Anoniem
Geeft wel aan hoe droef het is gesteld met cybersecurity. Velen vinden het leuker om achter de bugs van anderen aan te jagen (pentesten, researchers, hackers) dan om de bron van de problemen aan te pakken. Ook bedrijven vinden dit niet sexy (kost tijd geld moeite) en als ze het wel sexy vinden, zitten ze in het vak en publiceren continue over het dreigingslandschap dat snel toeneemt. IT'ers vinden patches maken makkelijker dan sw goed uitleveren. Juist het feit dat patches bestaan maakt dat er minder goed geprogrammeerd en getest wordt. En IT komt ook niet met goede oplossingen (waarom gebruiken we nog steeds C, C++ en zijn SQL databases afhankelijk van de kennis van de programmeur, is een out-of-the-box oplossing niet mogelijk?)

Dus we zijn 20 jaar verder en weinig gebeurd. Over 20 jaar zie ik jullie weer.
30-06-2023, 08:18 door Anoniem
je zou verwachten dat de meeste zaken wel zouden kunnen aangepakt worden door de programmeertaal wat minder dom te maken, zonder ook meteen een hele dikke, zware belasting te worden. Ook het operating system zou wat intelligenter mogen worden.
Hoe moeilijk kan het zijn om een proces geen rechten te geven op plekken waar het niets te zoeken heeft?
En hoe moeilijk kan het zijn om sanitation te doen op input?
Als je alleen letters en/of cijfers hoeft te verwachten, dan is de rest toch foute input?

vul je geboortedatum in:
dan verwacht ik '04/07/1965' en niet johnny-drop-tables....
30-06-2023, 09:02 door Anoniem
Programmeertaal Rust zal iig de meeste memory fouten oplossen.
Dus er is een oplossing, al ik ook snap dat het herschrijven van oude software niet te doen is.
Valideren van input tja dat blijft toch de taak van de programmeur.
Met Rust type systeem zou je dat kunnen verbeteren door ongevalideerde data een andere datatype te geven.
Zodat het altijd eerst door een validatie functie heen moet voordat je het kan gebruiken in je functies.
30-06-2023, 10:48 door _R0N_
Door Anoniem: Programmeertaal Rust zal iig de meeste memory fouten oplossen.

Horen we dat soort beloftes niet iedere keer dat er een nieuwe programmeertaal geïntroduceerd wordt?
Over een jaar of 5 kijken we terug en hebben we de volgende taal weer die alle problemen zal oplossen. het probleem zit niet in de taal maar de ontwikkelaar die (menselijke) fouten maakt.
30-06-2023, 11:45 door Joep Lunaar
Door Anoniem:
...
Juist het feit dat patches bestaan maakt dat er minder goed geprogrammeerd en getest wordt.
...
Kletspraat (of ik begrijp je verkeerd). Goede programmatuur, goed ontworpen, komt tot stand en blijft goed middels een patches. Neem een willekeurig goed OSS project (met name Linux kernel, maar er zijn er vele van zeer hoge qualiteit) en zie dat de omvang van het aantal patches eerder indicatief is voor kwaliteit dan omgekeerd.
30-06-2023, 11:49 door Joep Lunaar
Door Anoniem:
...
Met Rust type systeem zou je dat kunnen verbeteren door ongevalideerde data een andere datatype te geven.
Zodat het altijd eerst door een validatie functie heen moet voordat je het kan gebruiken in je functies.
Goeie, dat zou dus met elke taal die "strong typed" moeten kunnen. Een dergelijke conventie maakt 't in elk geval mogelijk om statisch (build time) alle gevallen van (ongevalideerde) input te onderkennen.
30-06-2023, 14:07 door Anoniem
Als je binnen Windows alle mitigation opties aan zou zetten (mee compiled) dan zijn de meeste memory corruption vulns ook niet meer uit te buiten. Maar ja, dan mag je wel je hele applicatielandschap gaan testen. Gaat zeker wel iets stuk...

DLL hell binnen Windows is iets waar men wel steken laat vallen. Dan krijg je de dooddoener dat een aanvaller al op het systeem moet zitten. Tja dat is in de meeste bedrijfsomgevingen niet zo moeilijk te verwezelijken..

En dan hebben we nog slecht beheer zoals RDP met wachtwoord aan internet....

Over 20 jaar weer eenzelfde lijst. Althans dat is al zo sinds ik het volg begin jaren 90.
30-06-2023, 23:04 door Anoniem
Door Anoniem: Geeft wel aan hoe droef het is gesteld met cybersecurity. Velen vinden het leuker om achter de bugs van anderen aan te jagen (pentesten, researchers, hackers) dan om de bron van de problemen aan te pakken. Ook bedrijven vinden dit niet sexy (kost tijd geld moeite) en als ze het wel sexy vinden, zitten ze in het vak en publiceren continue over het dreigingslandschap dat snel toeneemt. IT'ers vinden patches maken makkelijker dan sw goed uitleveren. Juist het feit dat patches bestaan maakt dat er minder goed geprogrammeerd en getest wordt. En IT komt ook niet met goede oplossingen (waarom gebruiken we nog steeds C, C++ en zijn SQL databases afhankelijk van de kennis van de programmeur, is een out-of-the-box oplossing niet mogelijk?)

Dus we zijn 20 jaar verder en weinig gebeurd. Over 20 jaar zie ik jullie weer.

Van de reacties is deze degene waarin ik me het meest in kan vinden. Je ziet gewoon dat veel ontwikkelaars de verkeerde beslissingen nemen. Soms te belachelijk voor woorden. Ik zou het puur nalatigheid noemen. Het is niet zo dat ze het niet kunnen zien. Ze willen het gewoon niet zien.
02-07-2023, 07:31 door Anoniem
Ik denk niet dat ze het niet willen zien. Ontwikkelaar zijn ook net mensen. Als wij vanuit onze professie ze niet laten zien WAAR en HOE ze moeten kijken, gaan ze dat ook niet zomaar doen. Niet vergeten dat er een hele generatie ontwikkelaar rondloopt die in het vak gegroeid zijn. De jongens en meisjes die kersvers van de opleiding komen hebben vaak al wel secure development meegekregen. Voor de zittende populatie komt dat er "nog even" bij. Vanuit het security vak moeten we gewoon flink door blijven zenden over hoe je security by design, privacy by design en secure development aanpakt. Onder de dwang van wetgeving en steeds strenger wordende compliance vereisten zal die aanpak steeds belangrijker worden. Echter, net als elke verandering duurt het lang voordat het allemaal echt in de aanpak verweven is. Daarom moeten we vanuit ons vak blijven coachen en van kennis blijven voorzien. Als we alleen maar pessimistisch blijven en blijven mauwen dat het er niet en nooit beter op wordt, worden we als beroepsgroep nooit serieus genomen.

Vooral blijven kijken naar mogelijkheden zou ik zeggen ;)
03-07-2023, 14:41 door Anoniem
Door Anoniem:
En hoe moeilijk kan het zijn om sanitation te doen op input?
Als je alleen letters en/of cijfers hoeft te verwachten, dan is de rest toch foute input?

vul je geboortedatum in:
dan verwacht ik '04/07/1965' en niet johnny-drop-tables....

Klopt, alleen soms denkt de developer data sanitation op de client te kunnen regelen.
HTML Inspect Element... <input type="date" ...> change to <input type="text" ...>
Submit form
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.