Taggat med: google chrome

Ny sårbarhet i Zoom medger Remote Code Execution (RCE)

Under tävlingen Pwn2Own som anordnas av Zero Day Initiative så har en ny sårbarhet identifierats i Zoom-klienten för Windows och macOS. Zero Day Initiative är en tävling där lag eller personer kan tävla om att identifiera och utnyttja sårbarheter i ett antal olika mjukvaror.

Tävlingen pågick mellan datumen 6-8 April och förutom en ny sårbarhet i Zoom så har även sårbarheter utnyttjats i Microsoft Exchange, Windows 10, Ubuntu Desktop, Parallels Desktop och Google Chrome.

Tweet med gif-animation när calc.exe poppas med hjälp av sårbarheten i Zoom:

Daan Keuper och Thijs Alkemade utnyttjade totalt tre olika buggar för att lyckas poppa calc i Zoom samt erhöll 1.7M SEK ($200,000) för detta.

För mer information se ZDI. Sårbarheten har ännu inte patchats av Zoom.

Test av Recorded Future Express

Svensk-grundade företaget Recorded Future har släppt ett browser-plugin som låter dig söka igenom IOC:er (Indicators of Compromise) på webbsidor.

Det kan först låta lite konstigt att man skulle vilja söka igenom webbsidor efter IOC:er men många SIEM-system i dagsläget såsom Moloch och Maltrail (som jag bloggat om tidigare) har webbgränssnitt.

Pluginet finns till Google Chrome, Edge samt Mozilla Firefox och för att använda det måste du registrera dig med en E-post och sedan erhålla en licensnyckel. Denna licensnyckel används sedan för att göra slagningar mot Recorded Futures databas över IOC:er såsom:

  • Checksummer över skadlig kod
  • Kolla upp CVE-nummer och prioritera sårbarheter
  • Domännamn som används för skadliga syften
  • Suspekta E-postadresser (kollar domänerna)

Pluginet är gratis att använda men viss data samlas in av Recorded Future (se nedan). Och har du en betalversion såsom Core eller Advanced så kan du länkas direkt vidare till din dashboard hos Recorded Future.

Nedan skärmdump visar på hur malware-kampanjen vid namn Gamaredon larmar på flertalet IOC:er:

Recorded Future Express
Källa: MalCrawler

Jag upplever det som om det mesta finns med hos Recorded Future och att täckningen är väl över 90% av alla kända IOC:er jag har kollat på.

Dock så finns ett antal URL:er inte med som IOC:er hos Recorded Future såsom denna:

  • message-office.ddns.net

Vilken uppenbarligen finns med på Maltrails IOC-lista över APT Gamaredon (pterodo, primitive bear). Tyvärr identifieras inte heller CVE 2017-0199 på sidan ovan hos MalCrawler. Men på en annan test-sida så identifieras CVE-2017-11882 korrekt (kanske har med bindestreck att göra?).

Här nedan är ett exempel där Checkpoint kollat på flertalet kampanjer och RF Express fångar upp alla IOC:er utmärkt. Du ser en röd eller gul prick till höger om checksumman som Chrome pluginet lägger till.

Här kan du testa Express:

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:

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.

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.

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