Taggat med: chrome

Uppgradera Google Chrome omgående

Google släppte igår en säkerhetsuppdatering till webbläsaren Chrome på grund av aktivt utnyttjande av två nya zero-days som fått CVE-2021-37975 och CVE-2021-37976.

  • CVE-2021-37976 är en bugg som orsakar informationsläckage och underlättar utnyttjande av sårbarheten nedan. Upptäcktes av Clément Lecigne från Googles Threat Analysis Group (TAG) 
  • CVE-2021-37975 är en user-after-free sårbarhet i V8 JavaScript motorn. Och har klassificerats som mycket allvarlig.

Även så har följande sårbarhet identifierats som allvarlig men där inget aktivt utnyttjande identifierats:

  • CVE-2021-37974 är också en use after free i Safe Browsing.

Samt så har minst en till säkerhetsbugg åtgärdats där fuzzing-tester identifierat denna internt hos Google. Så totalt innehåller denna uppdatering fyra säkerhetsfixar.

Och det var inte så många dagar sedan som ytterligare två sårbarheter åtgärdades av Google där också dessa utnyttjades aktivt. Den gången rörde det sig om CVE-2021-30632 och CVE-2021-30633 där ena va dessa var en sårbarhet i IndexedDB API:et.

För att kontrollera om du har installerat senaste versionen av Chrome så kan du skriva in följande sökväg i adressfältet: chrome://settings/help och då bör du se något i stil med följande när du installerat senaste uppdateringen och blivit ombedd att starta om webbläsaren:

Den versionen som släpptes igår till Windows, Linux och macOS har versionsnummer 94.0.4606.71. Och vill du läsa mer om denna stable-channel update så kan du göra det här.

Patch-gapping

Patch-gapping är ett nytt ord på en gammal metod som successivt ökar: Nämligen att utnyttja sårbarheter som åtgärdats av leverantörer, eller är på väg att åtgärdats av leverantörer. Området är närbesläktat med zero-days och patch-gapping kan även gå under benämningen 1-days eller n-days sårbarheter.

Under tiden som leverantören åtgärdar säkerhetsbristen eller det att användare ej uppdaterat sina system eller mjukvaror så finns det ett fönster för att utföra angrepp.

Detta är så klart något som angripare tar till vara på och utvecklar exploits så snart som det finns information om sårbarheter eller säkerhetsfixar. Ett område där detta uppdagas löpande är attacker mot webbläsare.

En av de första att utnyttja och påvisa denna typ av sårbarheter var Halvar Flake som utvecklade BinDiff runt år 2004. BinDiff används framförallt för att granska patchar som släpps av Microsoft och således se vilken kod som ändrats:

Zynamics BinDiff

Mjukvaran BinDiff utvecklades av Halvars företag Zynamics som blev uppköpta av Google och numera kan du gratis ladda hem bindiff. Andra liknande mjukvaror är Diaphora, YaDiff, DarunGrim och TurboDiff.

Men oftast så behövs det inte avancerad binär diffing utan räcker med att läsa changelog samt kolla git-repot eller motsvarande. När det gäller öppen källkod framförallt.

Företaget Exodus Intelligence har skrivit om patch-gapping gällande Google Chrome några gånger.

Följande graf har några år på nacken men visar på det window of opportunity som angriparen har på sig innan användaren uppdaterar till en ny version, i detta fall Google Chrome:

Twitterstorm mot Yubico

Uppdatering: Markus har nu skrivit ett blogginlägg om händelsen. Tipstack till John

Uppdatering 2: Yubico har gjort en pudel och uppdaterat sin blogg.

En twitter-storm har uppstått på grund av att Yubico hävdas ha kopierat forskning som presenterats under konferensen Offensive Con av Markus Vervier samt antisnatchor.

Forskningen som presenterades under konferensen påvisar en eller flera svagheter i WebUSB som används av bl.a. 2FA nycklar såsom Yubikeys. Chrome stödjer WebUSB och delade ut en belöning på $5000 till Yubico som i sin tur donerade pengarna till Girls Who Code, här kan du hitta Yubicos advisory ”WebUSB Bypass of U2F Phishing Protection”.

Yubico hävdar dock att det säkerhetsproblem som upptäcktes av dem var mycket större än det som presenterades av Markus och antisnatchor:

Our own researchers quickly discovered there was a broader set of security concerns within WebUSB that affected the entire ecosystem of FIDO U2F authenticators

En av många twitterinlägg från upprörda personer:

Den som vill se presentationen från Offensive Con så finns den här:

Nyheterna i Transport Layer Security version 1.3 (TLS 1.3)

SSL och TLS har under lång tid säkrat upp en betydande del av den krypterade kommunikationen på Internet. Sedan SSL version 1.0 släpptes internt hos Netscape Communications år 1994 så har det hänt en hel del.

Den nya versionen som just nu håller på att utvecklas inom en arbetsgrupp hos IETF har versionsnumret 1.3 där målsättningen är högre prestanda samt tillhandahålla en ännu högre säkerhet. Man kan säga att designkriteriet för denna nya version är ”less is more” och det innebär att en hel del föråldrade krypton har fått stryka på foten:

  • RSA är borttaget – RSA tillhandahåller inte Forward Secrecy
  • Svaga Diffie-Hellman grupper kan inte användas (SSL_OP_SINGLE_DH_USE)
  • CBC är borta – Är orsaken till attacker såsom Lucky13 och BEAST
  • RC4 samt SHA1 får inte längre användas
  • Export-algoritmer (ansvarig för attacker såsom FREAK, LogJam etc)
  • Nytt är ChaCha-Poly1305 samt stöd för OCB-modes (tipstack till Joachim Strömbergson)
  • Algoritmen för RSA-padding är Probablilistic Signature Scheme (PSS)
  • Nytt meddelande av typen EncryptedExtension. Som nu är krypterat, tidigare skickades många okrypterat

När det gäller prestanda så har ett antal åtgärder införts:

  • 0-RTT samt 1-RTT

Genom att få ner antalet TCP-paket som måste skickas fram och tillbaka vid varje anslutning så kan snabbare TLS (och webbsidor etc) uppnås.

Här följer en bild hur 1-RTT ser ut där klienten skickar ett ClientHello direkt, samt så gissar klienten vilka krypton som kommer att användas:

När du sedan har en session etablerad så kan sedan 0-RTT användas vid senare tillfälle (Session Resumption) men detta möjliggör dock återuppspelningsattacker.

Vill du redan nu testa TLS 1.3 i Google Chrome så kan du göra följande:

  1. Skriv in ”chrome://flags/” i adressbaren och trycker enter
  2. Gå till ”Maximum TLS version enabled.” och välj ”TLS 1.3”
  3. Starta om Chrome

Och vill du testa med Firefox så behöver du ladda hem senaste nightly-build där TLS 1.3 är påslaget som standard.

Och nu när vi besöker kryptera.se och tar upp Developer Tools (DevTools) så synes följande:

Viktigt att tillägga är att TLS 1.3 inte är färdigt ännu och ändras löpande. Detta gör att mjukvara såsom OpenSSL är försiktiga med att göra förändringar. Den senaste uppdateringen till TLS 1.3 heter draft-19 och släpptes för cirka 2 veckor sedan.

För att exempelvis Nginx ska stödja TLS 1.3 så måste även OpenSSL stödja detta. Och OpenSSL kommer med stöd inom några veckor i version 1.1.1.

Uppdaterad 2017-12-27: Enligt Cloudflare är det bara %0.06 av webbläsarna som använder TLS 1.3 och detta beror främst på att många mellanlådor inte stödjer TLS 1.3.

Uppdaterad: 2017-06-06, användes internt hos Netscape. Inte Mozilla som grundades först många år senare.

Heartbleed dag sex

broken-heartbleedYtterligare ett antal dagar har nu passerat sedan OpenSSL-buggen Heartbleed offentliggjordes och det är dags att göra ett antal till reflektioner.

Det har visat sig att buggen går att nyttja till att erhålla den privata nyckeln, framförallt via Hearbleed Challenge.

The bad news is that [discovery] changes our recommendation from: reissue and revoke as a medium priority to reissue and revoke as a high priority.

Skrev Matthew Prince, CEO på CloudFlare till Ars Technica.

Akamai har släppt en patch för att säkra upp minnesallokeringen i OpenSSL. Deras implementation går under namnet secure_malloc (OpenSSL använder sig av OPENSSL_malloc). Läs även mer här av Alex Clemmer.

Även oklart huruvida denna sårbarhet nyttjas innan den blev offentligt känd. EFF hävdar dock att så är fallet och har bevis på detta.

Bra saker som händer efter Heartbleed

OpenSSL får mer donationer som går att granska kodbasen samt så kontrollerar generellt fler ögon OpenSSL efter buggar.

Revokeringen av certifikat ses över då exempelvis Chrome har revokeringskontroll avstängt som standard.

Forward-secrecy eller PFS som det också kallas blir mer använt.

Uppdatering: Bra blogginlägg av Einar Otto Stangvik om hur han gick till väga för att hitta den privata nyckeln.

Google lägger ner False Start SSL

Förra året i Maj så skrev vi om ett expriment som Google utförde vid namn False Start SSL där avsikten var att snabba upp SSL (https). Dock så visade det sig att False Start var inkompatibelt med ett antal SSL terminatorer och det Google gjorde då var att upprätta en svartlista med dessa men det visade sig vara ett hästjobb att hålla denna lista uppdaterad så nu lägger Google ner experimentet meddelar företaget.

Adam Langley som jobbar på Google skrev detta på sin privata blogg ImperialViolet:

The `servers’ with problems were nearly always SSL terminators. These hardware devices terminate SSL connections and proxy unencrypted data to backend HTTP servers. I believe that False Start intolerance is very simple to fix in the code and one vendor suggested that was the case. None the less, of the vendors who did issue an update, most failed to communicate that fact to their customers. (A pattern that has repeated with the BEAST fix.)

Dock så kommer Googles webbläsare Chrome stödja False Start mot servrar som stödjer TLS Next Protocol Negotiation (NPN).

MITM Attack mot Google-användare i Iran

En användare av webbläsaren Google Chrome har i Iran upptäckt ett felaktigt certifikat för Google-tjänster. Efter ytterligare undersökningar så visade det sig att någon på vägen mellan användaren i Iran och Google genomförde en såkallad man-i-mitten attack (man-in-the-middle /MITM ) mot krypterade anslutningar (https).

Att användaren i Iran kunde upptäcka attacken berodde på att Google lagt in fingerprints för dess tjänster hårdkodat i webbläsaren Chrome. Så oavsett om certifikatet ser ut att vara korrekt utfärdat för *.google.com så visas en varning till användaren.

En av bovarna i dramat är företaget DigiNotar som utfärdat ett certifikat felaktigt. Omfattningen av denna attack är i dagsläget oklar.

Google har gått ut med följande meddelande:

Today we received reports of attempted SSL man-in-the-middle (MITM) attacks against Google users, whereby someone tried to get between them and encrypted Google services. The people affected were primarily located in Iran. The attacker used a fraudulent SSL certificate issued by DigiNotar, a root certificate authority that should not issue certificates for Google (and has since revoked it).

Google Chrome users were protected from this attack because Chrome was able to detect the fraudulent certificate.

To further protect the safety and privacy of our users, we plan to disable the DigiNotar certificate authority in Chrome while investigations continue. Mozilla also moved quickly to protect its users. This means that Chrome and Firefox users will receive alerts if they try to visit websites that use DigiNotar certificates.

To help deter unwanted surveillance, we recommend that users, especially those in Iran, keep their web browsers and operating systems up to date and pay attention to web browser security warnings.

HTTPS Everywhere version 1.0

Webbläsarverktyget HTTPS Everywhere finns nu ute i version 1.0. HTTPS Everywhere är ett verktyg som gör att många av de vanligaste webbsajterna vi surfar till dagligen använder den krypterade versionen av webbsurf dvs https. I dagsläget så ligger runt 1000 sajter inlagda i verktyget att automatiskt gå över till https istället för http.

Tyvärr så fungerar HTTPS Everywhere enbart till Firefox i dagsläget. Begränsningar i API:t hos Safari och Chrome gör att det ej är möjligt att göra ett verktyg som HTTPS Everywhere. Vi hoppas så klart att både Apple och Google kommer att införa förändringar i dess webbläsare  som gör det möjligt att tvinga fram https.

HTTPS Everywhere kommer från frihetskämparorganisationen EFF som även står bakom verktyg såsom Tor.

Här kan du ladda hem verktyget: https://www.eff.org/https-everywhere

Snabbare https med SSL False Start

De smarta utvecklarna i Google Chrome teamet har skickat in en draft till IETF som beskriver en metod att snabba upp surfandet på krypterade https-sidor med hjälp av modifiering i SSL/TLS-protokollet.

Denna modifiering har fått namnet False Start av Google för att reflektera ändringarna som föreslagits i handskakningen. Googles tester visar på en ökning av hastigheten på upp till 30%.

IETF Draften kan hittas här: tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

Källa: Chrome Blog