En ny allvarlig sårbarhet har uppdagats i VMware vCenter som medger Remote Code Execution i standardinstallationen. Sårbarheten har blivit tilldelad CVE-2021-21972 och fått en CVSS-score på 9.8 av of 10, således mycket allvarlig.
Läser vi på om VMwares advisory så står det följande:
The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin
Den del av vCenter servern som är sårbar hanterar vCenter Server plugin for vRealize Operations (vROps) och är aktiverad standard även om du inte använder just den funktionen.
VMware har släppt en säkerhetspatch och uppgradering till version vCenter Server 6.5 U3n, 6.7 U3l, eller 7.0 U1c snarast är rekommenderat. Observera också att port 443 måste vara exponerad för att sårbarheten ska gå att utnyttja.
Sårbarheten uptäcktes av Mikhail Klyuchnikov på företaget Positive Technologies.
JARM är ett relativt nytt blue-teaming verktyg som bl.a. kan användas för att skapa fingerprints av Command and Control-servrar (C&C). Verktyget är skapat av ett team där John Althouse ingår som också är en av grundarna till JA3/JA3s och HASSH.
Jarm används för att skapa ett unikt fingeravtryck (fingerprint) av en specifik TLS-kapabel server såsom Apache, Nginx, Cobalt Strike eller Metasploit.
Genom att skicka 10 st olika ClientHello TLS-meddelanden så skapas denna unika fingerprint.
Kör man jarm.py mot exempelvis Metasploit så får man följande fingerprint:
Skärmdump när jag kör jarm mot en metasploit-lyssnare som använder sig av reverse_https-payloaden:
För fler signaturer se följande Github-repo: https://github.com/cedowens/C2-JARM och givetvis så stödjer Shodan jarm-fingerprints sedan November 2020:
We've added JARM fingerprinting and with it introduce a new "ssl.jarm" property/ filter/ facet. Here's a breakdown of the current values for JARM fingerprints in Shodan: https://t.co/njOLlE9uWR (h/t @4A4133 and @SalesforceEng)
Ett tips är att testa att kombinera jarm med Rita och aktivt skicka ut probes till de anslutningar som ser suspekta ut. Den fingerprint som jarm beräknar är på 62 tecken och är en form av hybrid fuzzy hash. Observera att jarm ej bryr sig om x509-certifikatinformation.
Även bra att notera att om man ställer sin C2-server såsom Cobalt Strike eller Metasploit bakom Nginx så kommer då Nginx-hashen att vara den som fingerprintas.
För oss som gillar homomorfisk kryptering (HE) så börjar det nu dyka upp användningsområden lite här och var. Kortfattat kan man säga att homomorfisk kryptering medger att du kan göra beräkningar på krypterad information. Något som kan vara mycket användbart när molntjänster nyttjas och du inte vill dela med dig av information till molnleverantören.
Microsoft är en leverantör som nu använder homomorfisk kryptering i dess mjukvara Edge för att kontrollera läckta lösenord, detta gör man via algoritmen Oblivious Pseudo-Random Function (OPRF). Tidigare har bl.a. Haveibeenpwned använt k-anonymity för att kontrollera lösenord mot läckta listor.
När vi ändå är inne på k-anonymitet så är det värt att nämna att det finns vissa problem och en beskrivning av Googles implementation hittar du här.
Vad som också är intressant är att Microsoft har släppt biblioteket för att göra detta som open-source och under MIT-licens. Biblioteket heter Microsoft SEAL och går att ladda hem här.
Bild som beskriver Microsofts Password Monitor Service och dess användning av OPRF:
En ny säkerhetsbrist har identifierats i mjukvaran sudo. Sudo som installeras som standard i många operativsystem är som standard setuid root. Det innebär att eventuella brister kan leda till att lokala användare kan erhålla root-behörigheter.
Med åren har också sudo blivit större och fler funktioner har tillkommit. Detta har bl.a. lett till att OpenBSD nu har ett alternativ som heter doas.
Igår så rapporterade det amerikanska säkerhetsföretaget Qualys att de identifierat en sårbarhet i sudo (CVE-2021-3156). Sårbarheten medger att en lokal användare kan utnyttja en heap-sårbarhet och således bli root. Buggen har funnits sedan 2011 och återfinnes i standardkonfigurationen. Att det just finns med i standardkonfigurationen är viktigt att poängtera eftersom många sårbarheter som uppdagats i sudo kräver speciella konfigurationer.
Sårbarheten återfinnes i funktionen set_cmnd() och kan enklast triggas enklast genom att använda sudoedit och följande kommando:
sudoedit -s '\' `perl -e 'print "A" x 65536'`
Och är du sårbar så får du en segfault. Observera att du behöver lokalt konto men inte medlem i sudoers eller motsvarande. Samt att alla installationer inte har sudoedit, såsom macOS.
Video från Qualys som förevisar sårbarheten:
Om du som jag undrar lite över sudos logotyp, så se XKCD här.
Googles grupp för avancerad säkerhetsforskning som går under namnet Threat Analysis Group (TAG) har precis släppt en nyhet gällande att fiktiva cybersäkerhetsforskare som angriper andra cybersäkerhetsforskare.
Kopplingar kan göras till Lazarus-grupperingen som har anslutningar till Nordkorea, visar bl.a på analys som Kaspersky och Google har genomfört.
Första delen av attacken använder sig av social engineering och ett antal olika kanaler såsom Twitter, Keybase, LinkedIn, Discord och Telegram. En initial kontakt tas med målet där en fråga ställs om denne vill samarbeta gällande undersökning/utveckling av en ny sårbarhet. Då skickas sedan ett Visual Studio-projekt som innehåller en DLL med bakdörr samt kod som exekveras när projektet byggs (<PreBuildEvent>).
Enligt uppgift från Google så utnyttjas även en 0-dagars sårbarhet i Windows 10 och Chrome om besökaren går till bloggen blog.br0vvnn[.]io. Även denna blogg länkas vidare i chattarna på ovan sociala medier. Google har dock inte identifierat vilken sårbarhet som utnyttjas, men sägs vara CVE-2020-15994 som är en use-after-free i V8.
Jag tycker dock det låter konstigt att bränna 0-dagars för att angripa andra säkerhetsforskare, men kanske uppsidan är större. Och just moduset att angripa andra säkerhetspersoner har hänt många gånger förr, speciellt att exploits innehåller bakdörrar.
En av de som kontaktats är bl.a svenska Joel Eriksson:
https://t.co/SiHqVYNnKV – Good thing I use dedicated VMs for vulndev, and Linux as the host OS. They seem to be targeting Windows specifically (using Chrome+Windows 0days to target researchers on their br0vvnn blog), so presumably unlikely they had a VM escape targeting Linux. pic.twitter.com/4ZoUIIFVu2
”Update: I’ve recovered and decrypted registry keys holding config and neutered the service, I’m RE’ing the driver. I have confirmed with colleagues that only visiting the blog was enough to get popped via Chrome/Brave. I’ve confirmed my machine connected to their C&C many times.”
DNSpooq är det fiffiga namnet på en ny cache-poisoning attack mot mjukvaran Dnsmasq. Dnsmasq är en liten cachande rekursiv resolver som vanligtvis finnes i olika typer av inbyggda enheter såsom mobiltelefoner, Cisco-enheter, brandväggar, Ubiquiti-produkter för att nämna några av de 40 olika tillverkarna som skeppar med dnsmasq. Företaget som ligger bakom attacken har räknat ut att det finns ungefär 1 miljon sårbara enheter som är direkt kopplade till internet och troligtvis många fler som inte går att nå från internet.
DNSpooq består av flertalet olika sårbarheter som identifierats och ser ut enligt följande:
Och kan sammanfattas med följande citat:
The vulnerabilities all reduce the entropy of identiers TXID (Transaction ID) and source port and their combination, which should consist of 32 non-predictable bits in total, according to [8]. The vulnerabilities need to be combined in order to produce a feasible attack.
En dnsspoof-attack kan visas på följande sätt:
Förutom cachespoofnings-attackerna som identifierats har även fyra buffer-overflow sårbarheter identifierats i hanteringen av DNSSEC i dnsmasq.
Alla versioner av dnsmasq före 2.83 är sårbara för dessa attacker. Och denna version släpps idag den 19:de Januari.
Rapporten från JSOF går att ladda hem som PDF här.
Listan med CVE:er är följande:
CVE-2020-25681: A heap-based buffer overflow in dnsmasq in the way it sorts RRSets before validating them with DNSSEC data in an unsolicited DNS response
CVE-2020-25682: A buffer overflow vulnerability in the way dnsmasq extract names from DNS packets before validating them with DNSSEC data
CVE-2020-25683: A heap-based buffer overflow in get_rdata subroutine of dnsmasq, when DNSSEC is enabled and before it validates the received DNS entries
CVE-2020-25687: A heap-based buffer overflow in sort_rrset subroutine of dnsmasq, when DNSSEC is enabled and before it validates the received DNS entries
CVE-2020-25684: Dnsmasq does not validate the combination of address/port and the query-id fields of DNS request when accepting DNS responses
CVE-2020-25685: Dnsmasq uses a weak hashing algorithm (CRC32) when compiled without DNSSEC to validate DNS responses
CVE-2020-25686: Dnsmasq does not check for an existing pending request for the same name and forwards a new request thus allowing an attacker to perform a ”Birthday Attack” scenario to forge replies and potentially poison the DNS cache
Igår fick jag ett mail om att amerikanska företaget Ubiquiti har blivit hackade. Ubiquiti är bl.a. en av världens största tillverkare av bas-enheter för WiFi-kommunikation. Mailet innehåller relativt lite information eftersom att företaget uppger att de inte känner till omfattningen ännu.
Även om det var länge sedan jag själv använde Ubiquitis molntjänst så antar jag att det är fullt möjligt att erhålla access till det lokala nätverket via Ubiquitis centrala tjänst, därav är detta extra allvarligt. Även kan jag tänka mig att DNS kan omkonfigureras, firmware kan ändras osv.
Det som framgår i mailet är att användarnamn, hashat lösenord, adress och telefonnummer kan ha läckt. Samt framgår det även att det rör sig om en tredjepartsleverantör där läckan ska ha skett.
Utskicket har även bekräftats av Ubiquiti själva, se forumtråd här (via Säkerhetsbubblan). Utskicket gick via Mailchimp och använde bl.a. tracking-länkar, vilket gjorde att det var initialt svårt att avgöra äktheten i mailet.
Nu finns den andra live-inspelningen på YouTube, Facebook och LinkedIn. Denna gång pratar jag med Christoffer Strömblad som driver cstromblad.com. Vi pratade nästan en timme om statliga cyberattacker, deras förmågor och konsekvenserna av statligt sponsrade cyberattacker:
Den tidigare live-inspelningen med Christian på Cybix om CTF:er (Capture The Flag) finns att beskåda här.
Uppdaterat 2020-12-15: SolarWinds har i sin 8-K anmälan till US Securities and Exchange Commission angett följande: ”SolarWinds currently believes the actual number of customers that may have had an installation of the Orion products that contained this vulnerability to be fewer than 18,000”. Detta kan betyda att 18000 installationer har genomförts med bakdörren.
Uppdatering 2020-12-16: Bra analys av bakdörren av Qeeqbox.
Uppdatering 2020-12-17: Jag glömde i en tidigare version av detta blogginlägg att länka till källan som bekräftar att det är via SolarWinds som angriparna tog sig in hos FireEye, den källan återfinner du här.
Sent igårkväll så släpptes information om hur FireEye hackades via en så kallad supply-chain attack. Allt tyder på att intrånget genomfördes av APT29, Cozy Bear som är en grupp som kopplas mot ryska staten samt att en mjukvara från SolarWinds användes som intrångsvektor. Förutom FireEye så kunde även APT29 läsa mail under några månader på amerikanska myndigheten U.S. Treasury and Commerce.
APT29 placerade en bakdörr i SolarWinds mjukvara Orion som används för nätverksövervakning någon gång under mars-juni 2020. Den mjukvaran kommunicerade hem till SolarWinds som vanligt men kunde även fjärrstyra datorn som hade bakdörren installerad. Troligtvis genomförds intrånget mot SolarWinds genom deras byggsystem eftersom bakdörren också var signerad med SolarWinds certifikat.
Bland SolarWinds kunder kan man hitta en intressant lista med organisationer:
Bland kunder listas Volvo, Ericsson och Telenor. Oklart om det är just Orion som används av dessa kunder eftersom SolarWinds är ett stort företag med många produkter.
Bakdörren återfanns i filen SolarWinds.Orion.Core.BusinessLayer.dll. Och bl.a. Microsoft Defender kan upptäcka denna bakdörr som Solorigate. Andra namn för bakdörren är även SUNBURST samt operation UNC2452.
Att bakdörren var oupptäckt enbart under några månader beror troligtvis på att angriparna blev giriga och ville komma åt mer information i fler system. När spåren började att nystas upp så pekade de på SolarWinds produkt Orion och att ge sig på FireEye som är specialister på att göra IT-forensiska utredningar är troligtvis en bidragande faktor till att bakdörren inte blev så långlivad.
Intressant i denna historia är också att lokala VPS-anslutningar (virtuella privata servrar) inom landet användes för att inte väcka misstanke mot trafik som går utom landet. Även framhäver FireEye följande som också är intressant:
After a dormant period of up to two weeks, the malware will attempt to resolve a subdomain of avsvmcloud[.]com. The DNS response will return a CNAME record that points to a Command and Control (C2) domain. The C2 traffic to the malicious domains is designed to mimic normal SolarWinds API communications
Kontrollera alltså dina PCAP-filer eller brandväggsloggar efter DNS-uppslag mot avsvmcloud[.]com, förslagsvis under hela 2020. Här är ett exempel när jag söker efter denna information i Moloch (numera Arkime):
FireEye som är ett av världens största säkerhetsföretag gick i förrgår ut med information om att dom blivit hackade. Enligt dem så har ingen information om kunduppgifter komprometterats vad de identifierat ännu men om så skulle vara fallet så har dessa kunder kontaktas direkt.
Att ge sig på och hacka säkerhetsföretag är ingen direkt nyhet och har hänt flertalet gånger tidigare. Bl.a. Kaspersky identifierade ett intrång 2015.
Det som däremot FireEye har gått ut och bekräftat som stulet (exfiltrerat) är deras verktyg som används vid penetrationstester och Red-Teaming. Inga zero-days har används eller blivit stulna, vilket är bra. Jag förvånas också över mängden verktyg, över 200 st som de blivit av med.
De som ligger bakom attacken är en avancerad angripare som kan mätas eller är en statlig aktör uppger företaget. FireEye som själva jobbar med att utreda intrång skriver att de aldrig sett denna typ av avancerade angreppsvektorer tidigare. Även FBI bekräftar denna bild som förmedlas. Följande kommentar var rätt intressant också:
Consistent with a nation-state cyber-espionage effort, the attacker primarily sought information related to certain government customers
Tyvärr verkar inte FireEye släppa några IOC:Er som hjälper att identifiera angriparna. Enligt bl.a Dave Kennedy så pekar på att det är Ryssland som ligger bakom attacken, bl.a baserat på att FireEye tidigare avslöjat ryska cyberoperationer. Utredningen pågår fortfarande och mer information kommer förhoppningsvis längre fram.
Kevin Mandia som är VD på FireEye kommenterar följande i press-releasen:
På GitHub har man lagt upp signaturer i form av IOC:er för att känna igen de verktyg som stulits och jag har kollat på verktygen och det ser ut att vara branschpraxis-verktyg såsom BloodHound (CoreHound), SafetyKatz (Mimikatz) och egna såsom Sharpersist och Sharpivot. Mycket är baserat på .Net men även så finns det Python, Rust och programspråket D.
Intressant också att det finns kod som heter matryoshka.rs (Rust) och just matryoshka kan ju vara rätt allmänt använt eftersom matryoshka är en rysk trädocka i flertalet dockor inuti. Men också namnet på en iransk hackinggrupps RAT, CopyKittens.
Här kan du ladda hem en sammanställning med verktygen i Yara-format:
