Cisco Talos varnar för att en statlig grupp med kopplingar till Kina just nu utnyttjar två zero-days som återfinnes i Cisco ASA-produkter. De två sårbarheterna som utnyttjas sedan tidigt 2024 är enligt följande:
CVE-2024-20353
CVE-2024-20359
Dock har dessa CVE:er tyvärr inget att göra med initiala attackvektorn som fortfarande är okänd för Cisco.
Cisco har släppt ett kommando som man kan köra på sin Cisco ASA-enhet för att se om man har fått ett implantat inladdat:
show memory region | include lina
Och kontrollera följande:
Den övre delen av bilden ovan visar på flertalet adressrymder där Perm är r-xp och pathname /asa/bin/lina, detta indikerar på att det eventuellt finns en bakdörr i enheten.
Angriparna har också genomfört flertalet anti-forensiska åtgärder i bakdörren, vilket är intressant. En av dessa är bl.a. att se till att en krash-dump som genereras ej innehåller bakdörren.
Bakdörrarna går under namnen Line Runner och Line Dancer och hela kampanjen går under namnet ArcaneDoor av Cisco.
Rekommenderar även att läsa följande artikel som jag skrev på LinkedIn:
Cybersäkerhetsforskare vid Cisco Talos har identifierat ett nytt bakdörrsramverk vid namn Alchimist. Ramverket är skrivet i förenklad kinesiska och har även en malware-modul som fått namnet Insekt. Stöd för operativsystem såsom Windows, Mac och Linux återfinnes.
Insekt är skrivet i programspråket GoLang och exploits har identifierats för Linux Polkit (CVE-2021-4034). Talos skriver även att det finns vissa likheter med ett annat kinesiskt bakdörrsramverk vid namn Manjusaka.
Funktioner som implantatet har:
Kontrollera filstorlekar
Hämta OS-information
Kör godtyckliga kommandon via cmd[.]exe
Uppgradera det nuvarande Insekt-implantatet
Kör godtyckliga kommandon som en annan användare
Sov under tidsperioder som definieras av C2
Börja/sluta ta skärmdumpar
Även så kontrollerar implantet
För Linux så används den hårdkodade katalogen /tmp/Res/ samt ett statiskt TLS-certifikat för kommunikation:
En av de mer intressanta släppen under sommarens Blackhat-konferens i Las Vegas var den som handlade om att attackera SSL VPN:s.
Och varför är detta intressant? Jo det finns ett antal olika faktorer till att just detta är intressant och jag ska försöka beskriva dem nedan:
Underrättelsetjänster
NSA och andra underrättelsetjänster ser VPN:s som mål för att de används för att utbyta information. Med hjälp av passiv (och aktiv) avtappning så kan informationen ge fördelar, försprång och gynna den egna industrin:
Equation Group’s BENIGNCERTAIN tool – a remote exploit to extract Cisco VPN private keys.
Attackytan
Attackytan för specifikt SSL VPN:s är intressant då det mest troligt är en webbservern inblandad och denna kan innehålla sårbarheter. Webbservern måste hantera TLS, HTTP och underliggande protokoll. Vilket kan jämföras med exempelvis IKE och IPSEC.
En angripare som kan ta sig in i en VPN-enhet kan troligtvis också ta sig vidare in i nätverket eller modifiera kommunikationen (förutom att läsa av den).
Hårdvaran
När du köper ett SSL VPN så köper du troligtvis en låda av en leverantör som du inte vet så mycket om. Hur är det underliggande operativsystemet uppsäkrat? Vet du om den använder den ASLR + DEP? Och om den nu blir hackad, hur genomför du en forensisk undersökning av enheten?
Sårbarheterna
Följande sårbarheter har identifierats av Meh Chang (@mehqq_) och Orange Tsai (@orange_8361) i Fortigate SSL VPN:
CVE-2018-13379: Pre-auth arbitrary file reading
CVE-2018-13380: Pre-auth XSS
CVE-2018-13381: Pre-auth heap overflow
CVE-2018-13382: The magic backdoor
CVE-2018-13383: Post-auth heap overflow
Även har sårbarheter identifierats i Pulse Secure VPN, se mer här.
Även så har Palo Alto i all tysthet även patchat sin GlobalProtect, se mer här. Vad som också är skrämmande just nu är att två av ovan sårbarheter utnyttjas aktivt på internet av angripare vilket CERT-SE gick ut med en varning om.
Åtgärder
Sist men inte minst så tänkte jag ge några rekommendationer vad ni som organisation bör göra om ni har ett SSL VPN som är exponerat mot Internet.
Spara ner trafik framför och bakom SSL VPN:et. Så ni kan i efterhand undersöka vad som har hänt.
Uppdatera och se till att senaste säkerhetspatchar är installerade och att produkten inte är End-of-Life
Se till att loggar skickas från SSL VPN:et. Om möjligt alla typer av loggar såsom access-loggar på webbservern.
Begränsa tillgången till system som kan nås via VPN:et. Dvs ge inte full åtkomst till allt bara för att en användare ansluter via VPN.
Genomför en oberoende säkerhetsgranskning av uppsättningen
Er anslutningspunkt kanske inte bör vara vpn.företagsnamn.se
Följ upp anslutningar till och från Erat VPN. Har någon överfört 100 GB via VPN:et utan en koppling till en inloggad användare? Långa TCP-sessioner, beacons osv.
Policy över hantering av nya och användare som slutar samt regelbunden uppföljning
Försvåra password-spraying attacker genom att använda hårda/mjuka certifikat etc. Dator + användarcertifikat
Har ni eller har haft en sårbar version. Se till att byta samtliga lösenord
Sök av kontinuerligt med en sårbarhetsskanner
Har jag missat något ovan? Fyll gärna på i kommentarsfältet nedan.
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 ochDennis 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:
En ny sårbarhet har identifierats i Ciscos system för uppkopplade konferenser. Buggen har CVE-2018-0264 och är en RCE (fjärrexekvering av kod). Sårbarheten återfinnes i hanteringen av Advanced Recording Format (ARF) och denna kod återfinnes i både klienter och serverdelen i WebEx.
Sårbarheten har fått en CVSS Score på 9.6 vilket är nästan det högsta möjliga och är således en bugg som är lätt att utnyttja, men kräver dock användarinteraktion (någon klickar på en fil troligtvis).
Cisco WebEx Business Suite (WBS31) klienter före version T31.23.4
Cisco WebEx Business Suite (WBS32) klienter före version T32.12
Cisco WebEx Meetings med klienter före version T32.12
Cisco WebEx Meeting Server med versioner före 3.0 Patch 1
Detta är inte den enda buggen som på kort tid drabbat Ciscos WebEx-system, även CVE-2018-0112 som drabbade klienter som har WebEx installerat.
Amerikanska US-CERT gick i förrgår ut med en varning tillsammans med DHS, FBI och brittiska NCSC. Varningen gäller attacker som utförs mot Cisco-enheter som har funktionen Smart Install (SMI) aktiverad.
Enligt varningen så används verktyget Smart Install Exploitation Tool (SIET) som släpptes 2016 och som finns på Github. Även så pekas Ryssland ut som en aktör som står bakom dessa attacker mot amerikansk infrastruktur. Det som också är intressant är att SMI kan bl.a. användas för att ändra operativsystemet i Cisco-enheten, skapa GRE-tunnlar för mitm eller läsa av trafik.
SMI går på tcp port 4786 och så här ser statistik ut för skanningar:
Uppdatering 2: Leif Nixon visade på att det finns många enheter på Shodan i Sverige:
En felkonfiguration som utsatts för flera storskaliga attacker de senaste sex månaderna. Hur många av de här enheterna är redan hackade? Är det orealistiskt att förvänta sig att stora organisationer ska ha liiiite bättre koll på sina grejer? pic.twitter.com/dBgtwpMp8q
ROBOT är en ny intressant attack som använder sig av Bleichenbachers Oracle för att attackera tjänster som använder sig av TLS såsom https. Attacken går mot PKCSv1.5 som är en padding som används tillsammans med RSA. Genom att skicka ett antal olika krypterade meddelanden är det möjligt för en angripare att återskapa krypterat https-data.
För att få en uppfattning om hur omfattande problemet med ROBOT-attacken är så kan vi titta på den skanning som Dirk Wetter på testssl.sh projeketet genomfört mot Alexa Top 10k-listan.
Ovan visar alltså på att runt 15% av sajterna är sårbara.
Jag gillar även följande presentationsbild som är från Tibor Jager kurs på Paderborn Universitetet i Tyskland:
Samt så har den officiella sajten RobotAttack.org har sammanställt en lista över sårbara implementationer, där den som är mest anmärkningsvärd är Cisco ACE som tydligen används av många företag men Cisco ej kommer att patcha:
Cisco har via CIA Vault7-läckan identifierat en allvarlig sårbarhet i Cisco Cluster Management Protocol (CMP). Denna sårbarhet gör att en angripare kan fjärrmässigt tillförskaffa sig administrativa rättigheter på en Cisco-enhet.
Denna sårbarhet utnyttjas genom att en angripare skickar telnet-kommandon innehållandes specifika CMP-options (så kallade telnet option codes).
För att sårbarheten ska gå att utnyttja måste följande två förutsättningar vara uppfyllda:
CMP subsystem is present on the Cisco IOS XE software image running on the device, and
The device is configured to accept incoming Telnet connections.
Och för att se om just din enhet stödjer CMP kan du skriva kommandot: show subsys class protocol | include ^cmp
Cisco skriver på sin hemsida:
This vulnerability was found during the analysis of documents related to the Vault 7 disclosure
För att se hela listan med enheter som kan vara sårbara se Cisco.com
Cisco Talos har upptäckt en blind SQL-injection i McAfee ePolicy Orchestrator. ePolicy Orchestrator är en populär mjukvara i många enterprise-nätverk och något som jag ofta stöter på vid mina penetrationstester.
Sårbarheten har fått CVE-2016-8027 och gäller versioneravePolicy Orchestrator (ePO) 5.1.3 och äldre, ePO 5.3.2 och äldre.
McAfee ePolicy Orchestrator används för att centralt managera klienter som kör McAfee Antivirus. Klienterna pratar med servern över ett protokoll som heter SPIPE och servern har även en webbserver, Apache Tomcat som går på tcp port 8443.
Sårbarheten ligger i hur klientens GUID-värde (unika klient ID) skickas vidare in mot underliggande databas. På grund av en bristande filtrering så går detta värde direkt in mot databasen. Denna sårbarhet gäller dock enbart http post och inte SPIPE-kommunikationen, klienten kan prata med servern på båda protokoll.
För att förhindra denna sårbarhet bör klienter inte ha möjlighet att ansluta direkt på port 8443 till ePO-servern. Detta bör enbart administratörer ha behörighet att göra.
Det är oklart vad detta får för konsekvenser på klienter som använder servern om sårbarheten utnyttjas. Går det exempelvis att köra godtycklig kod på samtliga klienter?
CVSS3 (Common Vulnerability Scoring System) enligt följande:
EFF rapporterar att flertalet internetoperatörer (ISP:er) genomför nedgraderingsattacker mot E-posttrafik. När slutanvändaren försöker att koppla upp sig via SMTP och starta kryptering med STARTTLS så innehar operatören aktiv utrustning som då tar bort detta kommando.
Utrustning såsom Cisco PIX/ASA-brandväggen stödjer denna typ av aktiva attack och motiveringen anges vara att försöka stoppa spam.
Tyvärr innehåller STARTTLS åtskilliga sårbarheter som försöker åtgärdas, och EFF drar sitt strå till stacken genom projektet STARTTLS Everywhere som återfinnes på Github.
Förutom STARTTLS så kan E-post även krypteras direkt i klienten med S/MIME eller PGP (GnuPG).
Om du vill testa huruvida din operatör utför denna typ av nedgraderingsattack så kan du jämföra resultatet mot en server du vet stödjer kryptering:
Bild som förevisar en operatör som ej utför nedgraderingsattack.
Cisco Talos har upptäckt en blind SQL-injection i McAfee ePolicy Orchestrator. ePolicy Orchestrator är en populär mjukvara i många enterprise-nätverk och något som jag ofta stöter på vid mina 
För att förhindra denna sårbarhet bör klienter inte ha möjlighet att ansluta direkt på port 8443 till ePO-servern. Detta bör enbart administratörer ha behörighet att göra.