Facebook hackade

Facebook gick precis ut med nyheten att 50 miljoner Facebook-konton kan vara hackade. Intrången genomfördes via funktionen ”View as”, dvs den funktion som gör att du kan se hur din profilsida ser ut genom någon annans ögon.

Sårbarheten som utnyttjades är intressant på flertalet sätt. Facebook vet själva inte om omfattningen ännu men håller på att utreda detta.

Mark Zuckerberg skriver själv följande:

We do not yet know whether these accounts were misused but we are continuing to look into this and will update when we learn more.

Först och främst spelade det inte någon roll om du hade förstärkt din inloggning med tvåfaktorsautentisering. Sårbarheten introducerades Juli 2017 efter en ändring gällande video-uppladdning.

Angriparna hade möjligheten att erhålla en belöningssumma från Facebook ”bug bounty” som troligtvis var rätt hög. Facebook har nu åtgärdat sårbarheten och helt stängt av den funktion som var sårbar.

Det angriparna kom över var så kallade access token, dessa kan sedan användas till att komma åt det mesta på Facebook som en annan användare. Den felaktiga token genererades på viss information som låg på användarens Facebook-profil såsom videouppladdning i samband med födelsedagshälsning.

Om du har blivit drabbad så har du automatiskt blivit utloggad från Facebook samt när du loggar in så ska du presenteras av ett meddelande om vad som hänt. Facebook jobbar tillsammans med FBI för att utreda vem som ligger bakom denna attack. Vad dessa 50 miljoner konton som har gemensamt vet vi inte i dagsläget men flertalet svenskar skriver på Facebook att de blivit utloggade.

Säkerheten i nya macOS Mojave

Igår så släpptes Apples nya operativsystem macOS Mojave. Förutom att flertalet iOS applikationer nu går att köra på macOS så finns det även ett mörkt tema. Men vad som är ännu mer intressant är så klart alla säkerhetsproblem som åtgärdas i macOS Mojave (version 10.14).

✅ Stöd gärna Kryptera.se via Patreon >

Vad som också är intressant och integritetsfrämjande är att Mojave nu kräver att applikationer behöver tillstånd av användaren för att använda bl.a. mikrofon, kamera och backup. Samt så meddelande även Apple följande under WWDC2018 i Juni:

Apple is introducing enhanced runtime protections that will extend System Integrity Protection features to third-party apps, protecting them from code injection and other tampering.

Samt en ny process för att granska program som går in i macOS App Store som heter ”notarized”.

Följande säkerhetsproblem åtgärdas i Mojave:

  • An attacker in a privileged network position may be able to
    intercept Bluetooth traffic
  • A malicious application may be able to determine the Apple ID
    of the owner of the computer
  • A sandboxed process may be able to circumvent sandbox
    restrictions
  • A malicious application may be able to access local users
    AppleIDs
  • An application may be able to read restricted memory in Crash Reporter
  • An application may be able to execute arbitrary code with
    kernel privileges
  • An attacker may be able to exploit weaknesses in the RC4
    cryptographic algorithm

Även om Mojave höjer säkerheten så har redan Patrick Wardle påvisat hur man kan ta sig förbi det nya integritetsskyddet:

Granskning av MullvadVPN publicerad

Assured AB har tillsammans med tyska Cure53 publicerat en säkerhetsgranskning av VPN-tjänsten Mullvad. Granskningen gäller främst VPN-klienten som släppts i en ny utgåva som baseras på Electron-ramverket. Cure53 är även kända sedan tidigare för att publicera flertalet av sina granskningar publikt.

Jag tycker detta är ypperligt bra att publicera granskningsrapporten transparent på detta vis och något som jag efterfrågat gällande VPN-tjänster tidigare.

Rapporten innehåller en del smaskigheter där en identifierad brist har severity High och en Critical. Rapporten framhåller ändå att det är relativt få sårbarheter som identifierats och en av de troliga orsakerna är att mullvad-daemon är skriven i programspråket Rust.

Testerna tog 18 dagar att genomföra och tre av granskarna kom från Assured och fem från Cure53.

Här kan du läsa granskningsrapporten i sin helhet:

Cure53 och Assured AB granskning av MullvadVPN
Cure53 och Assured AB granskning av MullvadVPN

Nytt loggverktyg från Facebook: LogDevice

Facebook har precis släppt ett nytt loggverktyg som open-source. Verktyget går under namnet LogDevice och underlättar det moment som gäller att skriva loggar mot disk via ett kluster.

För att förstå lite bättre så kan följande bild förevisa konceptet:

Varje server i klustret har en lokal instans av LogsDB som bygger på RocksDB. Databasen är byggd på ett sådant sätt så minimalt med disk I/O används. Tekniken bygger på key-value LSM-träd.

Eller som Facebook skriver på sin Github-sida för projektet:

LogDevice is a scalable and fault tolerant distributed log system. While a file-system stores and serves data organized as files, a log system stores and delivers data organized as logs. The log can be viewed as a record-oriented, append-only, and trimmable file

Mer information finns på LogDevice.io samt en video från konferensen @Scale.

Ny version av Tor och Tails

Det händer mycket i Tor-lägret. Dels har en ny version av Tor-browser släppts som fått versionsnumret 8.0 och dels så har Tails version 3.9 släppts.

Den nya Tor-webbläsaren baseras på Firefox 60 ESR och har även fått en ny startsida som hjälper dig att surfa även om anonymiseringstjänster såsom Tor blockeras. Just detta förfarande går ut på att du kan göra en förfrågan efter Tor Bridges. Följande video visar hur det går till:

Från Tor FAQ:

Vad är bryggor?

Bryggor är Tor-reläer som hjälper dig kringgå censur.

Jag behöver ett alternativt sätt att skaffa bryggor på!

Ett annat sätt att få nya broar är att skicka e-post till [email protected]. Du måste skicka mailet från en adress hos någon av följande e-postleverantörer: Riseup, Gmail eller Yahoo.

Jag har även uppdaterat den Tor-fingerprint sida jag skapade, besök gärna den med Tor Browser 8.0 och rapportera om det fungerar:

Nyheter i Tails 3.9

Förutom en hel del buggfixar så stödjer Tails numera VeraCrypt och rekommenderas i flertalet fall framför LUKS. Läs mer här varför

Linux-kerneln har uppdaterats till 4.17 och åtgärd för Foreshadow-attacken är införd.

Säkerhetsuppdateringar till Joomla

Joomla är ett populärt open source (CMS) innehållshanteringssystem (öppen källkod) och används av 5.8% av alla sajter som använder någon form av CMS. Andra populära CMS:er är WordPress och Drupal.

Nu har version 3.8.12 av Joomla släppts som innehåller följande tre säkerhetsfixar:

  • Low Priority – Core –  Hardening the InputFilter for phar stubs (affecting Joomla 1.5.0 through 3.8.11) More information »
  • Low Priority – Core – Stored XSS vulnerability in the frontend profile (affecting Joomla 1.5.0 through 3.8.11) More information »
  • Low Priority – Core – ACL Violation in custom fields (affecting Joomla 3.7.0 through 3.8.11) More information »

Som du ser ovan så är ingen av dessa sårbarheter allvarliga men rekommendationen är ändå att uppgradera snarast. Standard så uppgraderas inte Joomla automatiskt utan du måste logga in och trycka på en knapp för att uppgraderas.

Google släpper nytt krypto-bibliotek: Tink

Tanken med Tink är att underlätta vardagliga programmeringsuppgifter som omfattar kryptering inom Google. Eftersom det är lätt att göra fel så ville man skapa ett bibliotek som minimerar risken för misstag samt göra det möjligt att använda biblioteket med flertalet programmeringsspråk och plattformar. Tink används redan i dagsläget i produktion inom Google i produkter såsom AdMob, Google Pay, Google Assistant, Firebase,  Android sök-App.

Google släppte för några veckor sedan version 1.2.0 som även stödjer iOS (Obj-C) och C++. Även finns numera stöd för Cloud KMS som är Googles nyckelhanteringstjänst.

För granskning av säkerheten i Tink har bl.a. Wycheproof används, ett verktyg utvecklat av Google för att identifiera kryptografiska brister i bibliotek.

Exempel på hur tink kan användas i Java med authenticated encryption with associated data (AEAD)

    import com.google.crypto.tink.Aead;
    import com.google.crypto.tink.KeysetHandle;
    import com.google.crypto.tink.aead.AeadFactory;
    import com.google.crypto.tink.aead.AeadKeyTemplates;

    // 1. Generate the key material.
    KeysetHandle keysetHandle = KeysetHandle.generateNew(
        AeadKeyTemplates.AES128_GCM);

    // 2. Get the primitive.
    Aead aead = AeadFactory.getPrimitive(keysetHandle);

    // 3. Use the primitive.
    byte[] ciphertext = aead.encrypt(plaintext, aad);

Vore mycket trevligt om du stödjer mitt bloggande via Patreon, från 9kr/månad. 

Sårbarhet i Episerver

Episploit - Klart Episerver sårbarheten ska ha en logo

För några månader sedan så upptäckte jag en sårbarhet i Episerver. Sårbarheten återfinnes i Episervers bloggmodul och är en så kallad blind (XXE) XML External Entity-sårbarhet. Jag rapporterade givetvis sårbarheten till företaget Episerver, och den finns åtgärdad från och med Episerver 7-patch 5.

Episerver används av mängder av företag och myndigheter såsom:

  • Försvarets materielverk (FMV)
  • Swedavia
  • Interflora
  • Vinnova
  • Smittskyddsinstitutet
  • Domstolsverket
  • Trafikverket
  • Myndigheten för samhällsskydd och beredskap, MSB

Buggen heter internt hos Episerver #128556 och jag har fått CVE registrerad som CVE-2017-17762.

Jag har även utvecklat en proof-of-concept kod i Python vid namn episploit.py som finns att hämta hem på Github Gist. Förutom att hämta hem en extern XML DTD som PoC:en jag har länkat, så går det även att detektera om en installation är sårbar genom att titta på DNS-förfrågningar ungefär som Burp Suite Collaborator gör. Att göra externa DNS-förfrågningar är effektivt eftersom många blockerar utgående TCP-anslutningar från sina webbservrar.

Det kan även vara möjligt att köra kod (Remote Code Execution, RCE) via en XXE. Se exempelvis följande blogginlägg där man använder sig av C#.

Och skärmdump som påvisar när en fil exfiltreras från en webbserver med hjälp av episploit:

Det är även möjligt att kontrollera huruvida en installation av Episerver är sårbar genom fingerprinting. Besök en sökväg som ser ut enligt följande:

  • https://www.domännamn.se/util/xmlrpc/Handler.ashx

Och där finner du längst ner på sidan vilken version som används. Jag är inte helt hundra på hur versionsummer ska utläsas men tror att alla som har version EPiServer.Blog 7.0.586 EPiServer.XmlRpc 7.0.586 samt lägre versioner är sårbara.

Åtgärder

Som en snabb åtgärd kan man blockera samtliga anrop till allt som börjar med en sökväg som är /util/xmlrpc. Även bör man blockera utgående trafik från webbservern och även DNS-förfrågningar.

Uppgradera till en senare version av Episerver och tyvärr så verkar det inte hjälpa att slå av bloggmodulen för denna bugg.

Tyvärr så listar inte Episerver säkerhetsuppdateringar på sin hemsida.

Tidslinje för offentliggörande (disclosure timeline)

  • 2017-12-12 Jag kontaktar CERT-SE som hänvisar till Episervers säkerhetschef
  • 2017-12-13 Får kontakt med Episervers säkerhetschef som hänvisar vidare inom organisationen
  • 2017-12-19 CVE-nummer reserveras
  • 2017-12-21 Episervers VP R&D bekräftar sårbarheten samt meddelar att buggen heter internt #128556 och åtgärdad från och med Episerver 7-patch 5
  • 2018-08-28 Info går ut till Kryptera.se-mailling-listan
  • 2018-08-29 Detta inlägg publiceras

Ny sårbarhet i IPSec

En ny sårbarhet har uppdagats som gör det möjligt att beräkna IPSec PSK-nycklar offline. Detta gäller både IKEv1 och IKEv2 samt main mode. Aggressive mode har sedan tidigare varit känt att det går att utföra offline forceringsattacker mot, och till viss del även main mode.

Då sårbarheten återfinnes i IKE-standarden så drabbas troligtvis samtliga leverantörer och följande CVE:er har blivit utfärdade än så länge:

  • Cisco – CVE-2018-0131
  • Huawei – CVE-2017-17305
  • ZyXEL – CVE-2018-9129
  • Clavister – CVE-2018-8753
  • Själva attacken har CVE-2018-5389

Attacken nyttjar Bleichenbachers attack och har och göra med hur RSA nonces används för autentisering och upptäcktes av Martin Grothe, Joerg Schwenk och Dennis Felsch.

Rekommendationen från teamet som identifierade sårbarheten är att patcha dina enheter samt om du måste använda PSK (pre-shared key) är att använda minst 19 slumpmässiga tecken som inte återfinnes i någon ordlista. Givetvis är certifikatbaserad inloggning säkrast när det gäller IPSEC.

Här nedan kan du ladda hem forskningsrapporten som presenterar attacken under USENIX konferensen:

Threat Hunting med osquery

Osquery är ett open-source projekt från Facebook som släpptes under år 2014. Osquery är ett verktyg för att ställa SQL-liknande frågor mot servrar och klienter. Detta är bra för att hålla koll på vad som händer i infrastrukturen. Ett axplock med några av de frågeställningar som osquery kan svara på:

  • Vilka processer körs på våra klienter?
  • Vilka TCP och UDP-portar lyssnar våra servrar på?
  • Vilka USB-minnen har varit anslutna till våra system?
  • Finns filen med namn eller checksumman XX någonstans?
  • Vilka processer kommunicerar ut på nätverket?

Osquery stödjer Windows, Linux, FreeBSD samt macOS. Dock kan funktionaliteten skilja sig mellan olika operativsystem.

Exempel på SQL-fråga som ställs via osqueryui:

I sin grundinstallation är osquery relativt avskalat och saknar mycket av den funktionalitet som man kan få med ett kommersiellt verktyg som kommer färdigt med avancerade rapporteringsfunktioner och signaturer. Därför kan du bygga stödfunktioner själv till osquery eller använda något av det som finns tillgängligt såsom Kolide, Doorman eller Uptycs som ser till att SQL-frågor kan ställas över nätverket. Loggningen från osquery kan med fördel hällas in i ELK-stacken eller Splunk.

När det gäller mallar för osquery för att titta på avvikelser eller anomalier så kan jag rekommendera Palantirs osquery-configuration, så kallade query packs.

Här är en skärmdump som visar på att jag 5 st query packs installerade i Kolide Fleet med fokus på Windows:

Det query pack som heter windows-attacks har 15 st SQL-frågor som går var 60:de sekund på 3 st klienter. Rapporter på utfall hamnar hamnar i filen osquery_result centralt på servern som kör Kolide Fleet, och filen ser ut ungefär enligt följande:

Och vill vi titta på hur just den SQL-frågan som genererade ovan JSON-loggrad så tittar vi bara på windows-pack/os-version som ser ut enligt följande:

SELECT * FROM os_version;

Eftersom action är added så är det första gången denna SQL-fråga kördes. Men du behöver inte köra frågor regelbundet utan kan även ställa vissa typer av realtidsfrågor beroende på operativsystem, se stödet i denna tabell (längst uppe i högra hörnet ser du en OS-symbol för varje tabell).

Fördelar med osquery 👍

Osquery gör att du kan inventera hela din infrastruktur och söka rätt på hot, så kallad Threat Hunting. Nästan allt är öppen källkod med bra licenser och gör det enkelt för organisationer med resurser att anpassa osquery till sina behov. För realtidsövervakning skulle jag dock komplettera med sysdig eller sysmon.

Du har även full insyn i samtliga regler och varför dessa larmar , vilket kan vara ett problem med många antivirus-mjukvaror då dessa ofta är stängda.

Nackdelar med osquery 👎

Du måste göra mycket själv och bör ha en god kännedom gällande open-source utveckling. Majoriteten av alla frågor är så kallade poll-baserade och gör att en angripare kan flyga under radarn. Precis som många andra skyddsfunktioner så kan en angripare stänga ner eller modifiera osquery.

Sammanfattning

Jobbar du med cybersäkerhet och inte har tittat på osquery efter att ha läst detta gör du tjänstefel. Undersök och labba själv på egen kammare med exempelvis DetectionLab.

Jag är även rätt säker på att osquery är en av de få säkerhetsrelaterade mjukvaror som snurrar på Mark Zuckerbergs Macbook.

Även kan Wazuh v3.5.0, uppföljaren till OSSEC kan stödja osquery sedan fem dagar tillbaka.

Stöd gärna mitt bloggande via Patreon.