Posten op security? en daar advies vragen?

Product vervangen?
Als het OpenSource is zelf even code aanpassen?


Je hebt trouwens we veel van dit soort oneliners. Wat gaat je volgende worden?

Een OS nemen wat wel snel patched.

Ik heb in begin jaren 2000 beveiligingslekken gemeld aan [monopolist] die nog nooit zijn gepatcht. Ze vinden het geen beveiligingslek. Maar het is wel aantoonbaar een real world probleem. Gewoon het bedrijf erop aanspreken en een patch opeisen. Dat zou iedereen moeten doen, zo ontstaat er druk.

Overigens, heel veel beveiligingsmaatregelen voor bijvoorbeeld websites worden nauwelijks nageleefd, zelfs niet door partijen die iets te beschermen hebben, zoals banken.

Steker eruit trekken! Altijd de veiligste oplossing.

Ga na of er mitigating solutions zijn. Zo niet, kijk of je dat onderdeel waarin de CVE zit uit kunt schakelen. Anders, als het ernstig genoeg is voor jou(w organisatie), kijk of je over kunt stappen naar een ander product. Kan dat allemaal niet, heb je helaas gewoon pech.

Voldoende beschuldigen, nu nog het bewijs van jou hiervoor! Geen onderbuikreactie graag!

Maatregelen nemen op een ander niveau.
Is het een OS, dan misschien die service uitschakelen (als dat kan).
Kan er een firewall rule neergezet worden?
Kan er actieve logging/monitoring opgezet worden?
Of inderdaad, wat al geroepen werd, uitfaseren...

Wat bedoel je met beveiligingsmaatregelen?

Je moet leren "Zero day denken". Er zijn namelijk twee scenarios waar je bang voor bent:
- Er is een onbekende zeroday/bug die niet gepatched word want niemand kent hem tot het aangevallen word/is.
- Er is een vuln die nog niet "patchbaar" is of niet gepatched word want productie jada jada.

Er is geen "one r...fix to rule them all" verder:

Ga er van uit dat alles hackbaar is en stel zodoende genoeg segmentatie in op accounts systemen, netwerk compartementen etc etc. Plaats bijvoorbeeld bij voorbaat een webfacing application achter een WAF of een goede proxy en zorg voor goede detectie.

Verder is het afwachten tot het bedrijf de patch uitbrengt en jou automatische updates het doorvoeren. Maar:
- Sommige vulns of exploits hebben vaak een "quickfix" of handmatige patch waarin je een aantal lines code of een configuratie moet aanpassen als work around mitigatie. Controlleer de vendor en het advies van de "bug vinder/researcher" van de bug/exploit om te kijken of er oplossingen zijn.
- Als er een known critical vulnerabillity/exploit is zoals die niet patchbaar is.. Dan is offline halen of slikken een beetje de fix. Echter kan je er voor kiezen (want productie) om het online te houden en het te beschermen met een WAF/VPN. Denk maar aan dat gehele citrix probleem waar alle citrix instanties niet achter een VPN of WAF hingen.

En niet elke bug/vuln is een exploitable bug/vuln en niet elke hoge rating (vuln) is kritieker dan elke bug met een lage rating. Dit word vaak overschat.

Als iemand iets wil verbeteren of toelichten, go your game.

- RAMLETHAL

Met het toenemend aantal CVE's per tijdseenheid heb je steeds minder keuze. Bijv. in https://seclists.org/oss-sec/2020/q4/137 schreef Morten Linderud (van Arch Linux) op 17 november j.l. onder meer:

Die thread is overigens begonnen door Hanno Böck (https://seclists.org/oss-sec/2020/q4/122) waarin hij meldt dat een buffer overflow in libraptor in veel distro's na 3 jaar nog steeds niet was gepatched. Omdat LibreOffice, naar verluidt, op meedere distro's van libraptor gebruik zou maken, zou een gemanipuleerd .odt bestand op deze systemen bedoelde kwetsbaarheid kunnen uitbuiten.

M.a.w. los van dat niet alle CVE's in elk OS/distributie gepatched worden (ook doordat de betreffende kwetsbaarheden in statically linked libraries kunnen zitten - doorzoek binaries op een willekeurig systeem maar eens op oude OpenSSL code), krijgt ook niet elke kwetsbaarheid een CVE. Oorzaken daarvoor zijn o.a. misverstanden wie zo'n CVE mag/moet aanvragen, er (later) een onderliggend probleem en/of meerdere kwetsbaarheden aan ten grondslag blijken te liggen of een fix onvoldoende blijkt te werken.

Je kunt rustig stellen dat het een zootje is...

Nog een mooie cve is het op twitter zetten van een foto waarbij de toegang zichtbaar is, te kopieren en je zo ergens melden.

"het" kan je niet zo stellen. Die Morten Linderud zegt alleen dat hij een mankracht probleem heeft. Bedrijven als Redhat hebben het gewoon heel goed geregeld met ook zeer verzorgde documentatie. Daar kan geen Microsoft tegen op. Naarnaast gaat het niet om aantallen CVS's maar om CVE's die kritiek (en belangrijk) zijn. Daar schijnt vooral 1 specifiek veel gebruikte desktop erg last van te hebben.

Inderdaad. Voeg ook betrouwbaarheid nog maar toe, zodat je niet blijft zitten met een systeem wat niet meer opstart. Schijnt ook 1 OS erg last van te hebben gehad. Misschien dat dat nu is verbeterd? ik weet het niet. Ik gebruik het niet meer. Ik wil dat risico niet meer lopen.

Uiteraard is er geen disclosure van ongepatche beveiligingslekken. Het doel is beveiliging, niet het helpen van criminelen.

Als je wat wil leren over het coden van veilige web sites dan kun je kijken bij de observatory van Mozilla.

@14:59 door walmare - Bijgewerkt: Vandaag, 15:00
Bijvoorbeeld gebruik van DNSSEC, DANE, STS, cookies, anti-crosssitescripting maatregelen. De lijst is lang.

Een goed webframework gebruiken zoals django helpt wel.