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.

TLS 1.3 är nu ute som RFC 8446

Jag har tidigare skrivit om nya versionen av TLS som kommer att bli version 1.3. Denna nya version har nu fått en RFC (Request for Comments) vilket kan anses av många som en standard på internet. Det är ungefär 10 år sedan TLS 1.2 släpptes.

En av anledningarna till att det tagit så lång tid att få ut denna RFC beror på middleboxes (mellanliggande utrustning på internet) som lägger sig i TLS-kommunikationen. Och för att undersöka detta så behövs det data från hur det ser ut ute i nätverken.

RFC 8446 är på 160 sidor och min favorit är Appendix E som beskriver säkerhetskomponenterna i TLS 1.3.

För att citera Facebook som använder sitt eget bibliotek Fizz:

More than 50 percent of our internet traffic is now secured with TLS 1.3

ISOC samt IETF har även skrivit om TLS 1.3:

 

PasswordsCon kommer till Stockholm

Norrmannen Per Thorsheim som anordnar konferensen PasswordsCon meddelade på Twitter att konferensen kommer att gå av stapeln i Stockholm. Det är i November under Internetdagarna som PasswordsCon blir ett av flertalet spår.

Call-for-papers är ute nu och har du något att berätta på 20-30 minuter så släng iväg ett mail till [email protected]

Vad priset för att gå på konferensen blir är dock ännu oklart eftersom det inte är möjligt att anmäla sig ännu till Internetdagarna men datumet blir 19-20 November, så boka in det i din kalender.

Videos från tidigare PasswordsCons hittar du på YouTube.

Läs mer på CFP-sidan här: passwordscon.org/cfp/

Reddit hackade

Reddit som är en av världens största webbsajter (plats 6 enligt Alexa) har hackats. Intrånget genomfördes via tvåfaktors-återställningskoder som skickas ut via SMS. Denna typ av tillvägagångssätt blir vanligare och vanligare vilket har fått NIST att ej längre rekommendera just 2FA-återställning via SMS, vilket jag skrev om 2016.

Antagonisten som hackade Reddit kom åt nya E-postadresser, gällande en sammanfattning som skickades ut. Samt en databas med användarnamn och lösenord från 2007.

Om du använder Reddit och har samma användarnamn och lösenord sedan 2007 så kommer Reddit att varna dig. Jag tycker dock att Reddit ändå bör skicka ut en varning till samtliga användare eftersom lösenord kan användas på flera sajter.

Reddit har även anställt en Head of Security samt söker personal till flertalet befattningar såsom:

Mer info hos Reddit i /announcements.