Lek in OpenSSL maakte afluisteren verbindingen mogelijk
De ontwikkelaars van OpenSSL, de software die massaal op internet wordt gebruikt voor het opzetten van versleutelde verbindingen, hebben een nieuwe versie uitgebracht die verschillende lekken verhelpt, waardoor aanvallers kwaadaardige code konden uitvoeren of internetverkeer konden afluisteren.
In totaal zijn er vijf kwetsbaarheden in de nieuwe OpenSSL-versies verholpen, waarvan er twee opvallen. Het gaat om een man-in-the-middle-kwetsbaarheid die op 1 mei van dit jaar aan de ontwikkelaars was gemeld, maar zou volgens de ontdekker al sinds de eerste versie van 16 jaar geleden aanwezig zijn. Door dit lek kon een aanvaller die zich tussen de aangevallen gebruiker en server plaatst het verkeer aanpassen of ontsleutelen. De aanval werkt echter alleen als zowel de client als de server kwetsbaar zijn.
Het lek is in alle OpenSSL-clients aanwezig. Servers zijn alleen kwetsbaar als ze OpenSSL 1.0.1 en 1.0.2-beta1 draaien. Beheerders van een OpenSSL-server die versies voor 1.0.1 draaien krijgen het advies om uit voorzorg toch te upgraden.
Buffer overrun
Het tweede grote probleem betreft een buffer overrun-aanval die het mogelijk maakte om willekeurige code op een kwetsbare client of server uit te voeren. Alleen applicaties die OpenSSL als een DTLS-client of server gebruiken lopen risico. Dit probleem werd op 24 april bij de ontwikkelaars gemeld. De overige drie verholpen problemen konden door een aanvaller worden gebruikt om een Denial of Service te veroorzaken. Meer informatie over kwetsbare versies is in de advisory te vinden.
Begin april van dit jaar werd de zeer ernstige Heartbleed-kwetsbaarheid in OpenSSL ontdekt. Hierdoor was het mogelijk voor een aanvaller om informatie uit het geheugen van webservers te stelen, zoals wachtwoorden en sessiecookies. De nu verholpen problemen zijn minder ernstig van aard. Om de veiligheid van OpenSSL te verbeteren besloten verschillende IT-giganten, zoals IBM, Intel, Microsoft, Google en Facebook, om OpenSSL een miljoeneninjectie te geven.
Dan weten de exploit boys precies waar ze wezen moeten...., welke diensten er kwetsbaar zijn of wat er gedraaid wordt.
Je moet voorstellen dat niet alle kwetsbaarheden gemeld worden of openbaar zijn, bij het weggeven van welke scripts waarop draaien is het wel erg makkelijk de kwetsbaarheid toe te passen
Ik denk dat zo'n lijst alleen meer ellende zou veroorzaken.
En welke alternatieve software is dan wel veilig? Ze hebben allemaal hun bugs en features die eerst ontdekt moeten worden en dan hopenlijk veilig disclosed en gerepareerd worden.
En jij garandeert mij dat polarssl veiliger is dan openssl? En dat onbekende bugs/features bij het ontdekken gelijk gemeld worden? Dus jij garandeert dan ook aan je klanten dat al zijn problemen als sneeuw voor de zon verdwijnen mits hij overstapt op polarssl? Dat ga je vast niet zo heel lang volhouden denk je niet? (hoor je al die aannames hier?)
Even realistisch alle software kent bugs/features en zolang deze onder de pet blijven is dat een risico. Blind overstappen op een andere leverancier is geen enkele garantie voor veiligheid. Het enige wat jouw opmerking doet is onnodig paniek zaaien en dat zal vast je intentie niet geweest zijn maar denk in het vervolg even na voordat je iets roept.
Ik ben zeker geinteresseerd in PolarSSL, wat moet ik doen naast apt-get install polarssl om te zorgen dat nginx, opensmtpd en evt andere services automatisch gebruik maken van de polarssl libraries en niet de openssl libraries?
Simpelweg ja op een reactie roepen is mij niet overtuigend genoeg.... doe mij eens een vergelijking dan? Gefundeerde beweringen in plaats van: "Maar iets roepen"
Ik ben zeker geinteresseerd in PolarSSL, wat moet ik doen naast apt-get install polarssl om te zorgen dat nginx, opensmtpd en evt andere services automatisch gebruik maken van de polarssl libraries en niet de openssl libraries?
Simpelweg ja op een reactie roepen is mij niet overtuigend genoeg.... doe mij eens een vergelijking dan? Gefundeerde beweringen in plaats van: "Maar iets roepen"
OpenSSL 0.x: http://secunia.com/advisories/product/253/?task=statistics
OpenSSL 1.x: http://secunia.com/advisories/product/30216/?task=statistics
PolarSSL 1.x: http://secunia.com/advisories/product/40977/?task=statistics
En als je het verschil echt wil weten, schrijf dan met beide libraries maar eens een applicatie. Dan merk je het verschil pas echt.
Ik ben zeker geinteresseerd in PolarSSL, wat moet ik doen naast apt-get install polarssl om te zorgen dat nginx, opensmtpd en evt andere services automatisch gebruik maken van de polarssl libraries en niet de openssl libraries?
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.
