Nieuw TLS/SSL-lek raakt Android- en Apple-gebruikers
Onderzoekers hebben een nieuw lek in TLS/SSL ontdekt waardoor aanvallers de versleutelde verbindingen van Android- en Apple-gebruikers kunnen aanvallen. Het probleem, dat de naam "FREAK Attack" heeft gekregen, is in sommige TLS/SSL-servers en clients aanwezig en laat een aanvaller die zich tussen het doelwit en het internet zit de beveiliging van de TLS-verbinding naar een zwakke encryptie kan downgraden. Vervolgens kan deze encryptie worden aangevallen en de inhoud van het beveiligde verkeer worden bekeken.
De kwetsbaarheid wordt veroorzaakt door het Amerikaanse exportbeleid uit de beginjaren 1990, waardoor sterke encryptie niet mocht worden geëxporteerd. In plaats daarvan mocht er alleen "export-grade" RSA-encryptie worden geleverd. De encryptiesleutels mochten in dit geval slechts 512-bits groot zijn. Volgens cryptografieprofessor Matthew Green was de 512-bit export-grade-encryptie een afweging tussen "dom en dommer". "In theorie was het ontwikkeld om ervoor te zorgen dat de NSA communicatie kon benaderen, terwijl er ook kon worden beweerd dat de cryptografie "goed genoeg" was voor commercieel gebruik."
Volgens Green leidde de noodzaak om export-grade-encryptie te ondersteunen tot technische uitdagingen. Amerikaanse servers moesten namelijk zowel sterke als zwakke encryptie ondersteunen. De SSL-ontwikkelaars gebruikten hiervoor een mechanisme dat bij het opzetten van een beveiligde verbinding tussen twee partijen de sterkste encryptie kiest die beide partijen ondersteunen . In theorie zouden Amerikaanse gebruikers met Amerikaanse servers dan van sterke encryptie gebruik kunnen maken, terwijl ook buitenlandse clients met zwakke encryptie werden ondersteund.
De meeste moderne clients, zoals browsers, zouden bij het opzetten van een versleutelde verbinding geen export-grade-encryptie meer aanbieden. Daarnaast werd er vanuit gegaan dat de meeste servers ook geen export-grade-encryptie meer zouden aanbieden. Verder zou een aanvaller in het geval er toch export-grade-encryptie voor de versleutelde verbinding werd gebruikt een 512-bit RSA-sleutel moeten berekenen.
Onderzoek
Onderzoekers van Microsoft Research, INRIA en IMDEA ontdekten dat sommige moderne TLS-clients, waaronder Apple's Secure Transport en OpenSSL, een kwetsbaarheid bevatten. Daardoor accepteren ze RSA export-grade-encryptie, ook al hebben ze hier niet om gevraagd. Volgens Green heeft deze bug grote gevolgen, omdat een aanvaller hierdoor de verbinding kan downgraden. Wel moet de client in kwestie kwetsbaar zijn en de server export-grade RSA ondersteunen. In tegenstelling tot wat veel mensen dachten is export-grade RSA nog steeds in gebruik. 36,7% van de 14 miljoen onderzochte websites bleken het te ondersteunen.
"We dachten dat mensen het niet meer gebruikten", zegt Karthikeyan Bhargavan, een onderzoeker van het Franse computerlaboratorium INRIA tegenover de Washington Post. Het team van Bhargavan ontdekte het probleem tijdens het testen van encryptiesystemen. Volgens Nadia Heninger, een cryptograaf aan de Universiteit van Pennsylvania, hebben we hier eigenlijk met een "zombie uit de jaren 1990" te maken. Heninger stelt dat ze de export-grade-encryptie via de Amazon Web Services in 7 uur kan kraken.
Oplossing
De kwetsbaarheid werd in januari van dit jaar al in OpenSSL gepatcht. Apple zou inmiddels aan een update werken die volgende week verschijnt en verschillende internetpartijen zijn bezig om export-grade-encryptie uit te faseren. Google zou inmiddels ook een patch onder leveranciers hebben uitgerold. Het is echter aan deze partijen om de Android-update ook onder hun gebruikers uit te rollen. Android-gebruikers krijgen dan ook het advies om een andere browser te gebruiken dan degene die standaard wordt meegeleverd.
Deze bug heeft niets te maken met servers die OpenSSL gebruiken. Het probleem is dat er ontzettend veel servers slecht geconfigureerd zijn door o.a. nog EXPORT ciphers te ondersteunen. Dat is eenvoudig te testen via https://www.ssllabs.com/ssltest/ of door zelf tools zoals SSLyze te draaien (https://github.com/nabla-c0d3/sslyze).
Door de OpenSSL client bug is de volgende MitM (Man-in-the-Middle) aanvalsscenario mogelijk: hoewel de client niet aangeeft EXPORT ciphers te ondersteunen, manipuleert de aanvaller het netwerkpakketje zodanig dat het lijkt of de client uitsluitend EXPORT ciphers ondersteunt, en stuurt dat door naar de server. Indien de server die ook ondersteunt, stuurt de server een bewust korte RSA publieke sleutel van 512 bits lengte naar de client. Een probleem daarbij is dat Apache tijdens opstarten eenmalig zo'n sleutel (feitelijk sleutelpaar) genereert, en dat blijft hergebruiken. Zodra de aanvaller die sleutel gekraakt heeft, kan hij wellicht meerdere sessies ontsleutelen.
Interessant is dat o.a. "svenvNL" op Tweakers.net meldt dat ook Windows Phone 10 beta kwetsbaar zou zijn, zie de screenshot waarnaar verwezen wordt in https://tweakers.net/nieuws/101697/android-en-apple-gebruikers-kwetsbaar-door-oude-backdoor-in-ssl.html?showReaction=7544147#r_7544147. Belangrijk om op te merken is dat het hierbij ook om een false positive zou kunnen gaan van de testsite https://freakattack.com/.
Aanvulling 04-03-2015, 13:00: op 20 februari 2015 blijkt https://tools.ietf.org/html/rfc7465 te zijn gepubliceerd (bron: http://www.heise.de/security/meldung/IETF-verbietet-RC4-Verschluesselung-in-TLS-2556520.html). RFC 7465 laat er geen misverstand over bestaan dat de RC4 stream cipher niet meer gebruikt hoort te worden.
Aanvulling 04-03-2015, 13:02: beschrijving MitM aanval iets verduidelijkt.
Zo'n lang artikel met uitleg geschreven zonder ook maar één keer de naam van de browser te laten vallen waar het om gaat, Safari !
En alhoewel de meeste mensen op Mac's vermoedelijk Safari gebruiken,.. niet iedereen, en dat lijkt te helpen.
Aanvalsmethode
De aanvals methode van de onderzoekers gaat daarnaast met gebruikmaking van een 3rd party Javascript als "the Facebook JavaScript SDK (loaded in most sites that use Facebook's Like or Login button)" en met behulp van een XSS attack.
Hoewel het in de basis lastig (onmogelijk?) is om de downgrade mogelijkheid in Safari zelf uit te schakelen omdat die gebruik maakt van de Apple systeem certificaten (in de keychain) kan je denk ik wel op andere wijze de attack wat tegen proberen te gaan (idee/aanname)
Oplossingen (?)
a) Browsen met een andere browser.
Firefox of een mozilla variant daarvan bijvoorbeeld (heeft een eigen certificaatbeheer 'los' van het Apple systeem)..
Een must als je Safari browser ook niet meer door Apple wordt supported, voor degenen die nog werken met een OS X versie die inmiddels buiten de Apple support boot valt (OS X 10.7 en ouder).
b) De attack vector bemoeilijken of managen,
Namelijk het gebruik van Cross Site Scripting (XSS), bekende Third party Javascripts, third party (tracking/reclame/beeld) elementen op websites zoveel mogelijk tegengaan.
Mocht je dat niet al doen dan kan dat alsnog met wat extra addons en extensies:
- Een javascript 'manager' tegen XSS en voor het managen van Javascripts als "Noscript" of voor Safari "Javascript Blocker" (niet gratis geloof ik / trial version van 60 dagen?) .
- Een "Adblocker" met de juiste blokkeer abonnementen tegen 3rd party elementen en scripts (anti duimpje abonnement erbij?), bijvoorbeeld Adblock Plus
- Een addon/extensie die 3rd party tracking tegengaat als bijvoorbeeld "Ghostery" (scripts en elementen)
(Hier genoemd de meeste bekende addon/extensie merken, er zijn wel meer addons en extensies met vergelijkbare functionaliteit : kijk, lees en vergelijk.)
Schoner browsen met meer privacy
Wanneer Apple binnenkort een update voor deze downgrade attack zal hebben uitgebracht (OS X 10.8 / 10.9 / 10.10) dan is in ieder geval de blijvende winst dat je met gebruik van de bovenstaande addons een wat schonere browser ervaring hebt met meer privacy.
Zo af en toe heeft een (tijdelijk) nadeel ook een (lange termijn) voordeel; in dit geval bewustwording en het ondernemen van uitgestelde actie?
(als ik er heel erg naast zit met deze analyse en bedachte oplossing hoor ik dat graag!)
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.
