Patch-gapping är ett nytt ord på en gammal metod som successivt ökar: Nämligen att utnyttja sårbarheter som åtgärdats av leverantörer, eller är på väg att åtgärdats av leverantörer. Området är närbesläktat med zero-days och patch-gapping kan även gå under benämningen 1-days eller n-days sårbarheter.
Under tiden som leverantören åtgärdar säkerhetsbristen eller det att användare ej uppdaterat sina system eller mjukvaror så finns det ett fönster för att utföra angrepp.
Detta är så klart något som angripare tar till vara på och utvecklar exploits så snart som det finns information om sårbarheter eller säkerhetsfixar. Ett område där detta uppdagas löpande är attacker mot webbläsare.
En av de första att utnyttja och påvisa denna typ av sårbarheter var Halvar Flake som utvecklade BinDiff runt år 2004. BinDiff används framförallt för att granska patchar som släpps av Microsoft och således se vilken kod som ändrats:
Men oftast så behövs det inte avancerad binär diffing utan räcker med att läsa changelog samt kolla git-repot eller motsvarande. När det gäller öppen källkod framförallt.
Företaget Exodus Intelligence har skrivit om patch-gapping gällande Google Chrome någragånger.
Följande graf har några år på nacken men visar på det window of opportunity som angriparen har på sig innan användaren uppdaterar till en ny version, i detta fall Google Chrome:
H1 är Googles säkerhetschip som återfinnes i Chromebooks. Andra smeknamn för Google H1 är Cr50 eller G Chip.
Säkerhetsbristen som återfinnes i H1 har och göra med ECDSA signaturgenerering och gör att enbart 64 bitar istället för 256 bitar entropi används för den privata nyckeln. Enligt Google gör detta att det är möjligt för en angripare att återskapa den privata nyckeln:
We confirmed that the incorrect generation of the secret value allows it to be recovered, which in turn allows the the underlying ECC private key to be obtained
Denna ECDSA-nyckel används för U2F-inloggning mot webbplatser som erbjuder multifaktorautentisering. Detta innebär således att:
Firmware måste uppdateras i H1-chippet. Detta görs automatiskt från och med ChromeOS 75 som släpptes 26:de Juni 2019
Samtliga nycklar måste bytas ut mot de sajter där U2F används för multifaktorautentisering (MFA)
Observera att detta enbart gäller om du använt Chromebookens strömknapp för inloggning samt MFA
Du kan även skriva in chrome://system i webbläsaren på din Chromebook och sedan titta efter cr50_version och RW-raden. Version 0.3.15 och senare innehåller ej denna sårbarhet.
Följande meddelande ”Internal security key requires reset” visas för användare som är drabbade av denna säkerhetsbrist:
Detta är så klart en pinsam miss av Google och något som bör fångas upp av tester. Men att denna typ av sårbarheter ökar är något som jag tror vi kommer att få se mer av, det var exempelvis inte länge sedan som Feitian Security Key hade en sårbarhet (på bild till höger).
Jag skrev detta inlägg på LinkedIn men tänkte dela med mig av denna information även här:
Zeroday-förmedlaren Zerodium har uppdaterat sin prislista. Intressant är att priserna kopplade till Android ökat samt Apple iOS minskat. Vad beror detta på? 🤔
Några av mina gissningar:
✅ Googles arbete med att höja säkerheten i Android har gett utdelning
✅ Större efterfrågan från Zerodiums kunder som vill ta sig in i Android-telefoner
✅ Fler typer av uppkopplade enheter använder Android. Inte bara mobiltelefoner
✅ Det finns redan många iOS-exploits på svarta marknaden
Googles Threat Analysis Group (TAG) har identifierat en ny watering hole attack som riktar sig mot iPhone-användare. Attacken är intressant på många sätt, bl.a. så uppger Google att attacken inriktas mot en viss typ av grupp samt att det faktum att fem olika exploit-kedjor används för att ta sig in i iPhones. För en säkerhetsforskare som tar fram en enda exploit-kedja och säljer den till företag såsom Zerodium kan ge upp mot 19 miljoner SEK enligt deras publika prislista.
Gällande exploit-kedjor så anger TAG följande:
seven for the iPhone’s web browser, five for the kernel and two separate sandbox escapes. Initial analysis indicated that at least one of the privilege escalation chains was still 0-day and unpatched at the time of discovery (CVE-2019-7287 & CVE-2019-7286)
När väl dessa sårbarheter utnyttjas så installeras sedan ett implantat som har möjlighet att läsa ut meddelanden ur end-to-end krypterade appar såsom iMessage, Whatsapp och Telegram. Även så kan detta implantat följa iPhone-användaren i realtid via GPS-koordinater som skickas till en Command and Control-server.
Just kommunikationen till C&C-servern går via HTTP och ej HTTPS vilket är annorlunda. Även kan dessa unika strängar användas för att identifiera kommunikation på nätverket:
9ff7172192b7
/list/suc?name=
Ovan två förfrågningar går över HTTP GET alternativt POST.
Spekulationer om vem som ligger bakom dessa avancerade attacker riktas mot Kina eller grupperingar kopplade till Kina främst på grund av de omfattande sårbarheterna som utnyttjas mot iPhone samt att företaget Tencent är ett företag vars appar kontrolleras:
com.yahoo.Aerogram
com.microsoft.Office.Outlook
com.netease.mailmaster
com.rebelvox.voxer-lite
com.viber
com.google.Gmail
ph.telegra.Telegraph
com.tencent.qqmail
com.atebits.Tweetie2
net.whatsapp.WhatsApp
com.skype.skype
com.facebook.Facebook
com.tencent.xin
Google har själva också varit sparsamma med information gällande implantatet som installeras exempelvis har ingen information om C&C-servrar publicerats. Detta troligtvis eftersom en större utredning pågår av amerikanska myndigheter.
Uppdatering: Enligt källor till TechCrunch är det Uigurer som är målet.
Det var länge sedan som det utannonserades att Python 2 kommer att nå end of life (EOL) 1:a Januari 2020. Men tyvärr så har många företag och organisationer en teknisk skuld och ligger efter med arbetet med att uppgradera till Python 3.
Brittiska National Cyber Security Centre gick ut med en varning tidigare i veckan gällande Python 2 samt tittade närmare på statistik när det gäller användningen av Python 2.
Så här ser användningen av några populära paket på PyPI gällande data från Juni 2019:
Paket
Python 2
Python 3
Okänd Version
Colorama
82.07%
17.71%
0.22%
botocore
72.86%
26.84%
0.30%
urllib3
64.14%
35.50%
0.37%
Requests
53.37%
46.02%
0.61%
scikit-learn
43.80%
55.90%
0.30%
NumPy
40.69%
58.70%
0.61%
Pillow
37.78%
61.31%
0.91%
TensorFlow
37.66%
61.25%
1.09%
Matplotlib
33.17%
66.34%
0.49%
Flask
31.28%
68.33%
0.39%
Men hur gör man för att uppgradera då? Först kontrollera att du har python3 installerat i ditt operativsystem:
Sen testar vi programmet vi har utvecklat för Python 2 som vi vill uppgradera till version 3:
Funkar dåligt. Så då tar vi och använder verktyget 2to3 samt anger argumentet -w för att skriva ändringarna direkt till filen:
$ 2to3 -w episploit.py
Och sedan är det bara att köra programmet om allt gick som det ska. Ibland kan manuell handpåläggning behövas.
Än så länge får Python 2 säkerhetsfixar men det gäller enbart tills den 1:a Januari 2020. Och för att citera NCSC:
By making the decision to continue using Python 2 past its end of life, you are accepting all the risks that come with using unsupported software, while knowing that a secure version is available.
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.
Att cyberattacker mot Supply Chains såsom rubygems blir vanligare och vanligare är vi många som har förutspått i flera år. Och igår så identifierades en bakdörr i ruby rest-client.
Bakdörren las in via ett hackat konto (mwmanning) och hämtade hem kod från pastebin som sedan exekverades. Liknande attacker har tidigare inträffat mot bl.a. JavaScript-biblioteket (npm) event-stream.
Just denna bakdörr som fanns i Ruby-gems gjorde ett antal olika saker såsom att skicka iväg miljövariabler till hostnamnet mironanoru.zzz.com.ua.
Även identifierades bakdörrar i många andra RubyGems såsom:
rest-client: 1.6.10 (downloaded 176 times since August 13, 2019), 1.6.11 (downloaded 2 times since August 14, 2019), 1.6.12 (downloaded 3 times since August 14, 2019), and 1.6.13 (downloaded 1,061 times since August 14, 2019)
bitcoin_vanity: 4.3.3 (downloaded 8 times since May 12, 2019 )
lita_coin: 0.0.3 (downloaded 210 times since July 17, 2019)
coming-soon: 0.2.8 (downloaded 211 times since July 17, 2019)
omniauth_amazon: 1.0.1 (downloaded 193 times since July 26, 2019)
cron_parser: 0.1.4 (downloaded 2 times since July 8, 2019), 1.0.12 (downloaded 3 times since July 8, 2019), and 1.0.13 (downloaded 248 times since July 8, 2019)
coin_base: 4.2.1 (downloaded 206 times since July 9, 2019) and 4.2.2 (downloaded 218 times since July 16, 2019)
blockchain_wallet: 0.0.6 (downloaded 201 times since July 10, 2019) and 0.0.7 (downloaded 222 times since July 16, 2019)
awesome-bot: 1.18.0 (downloaded 232 times since July 15, 2019)
doge-coin: 1.0.2 (downloaded 213 times since July 17, 2019)
capistrano-colors: 0.5.5 (downloaded 175 times since August 1, 2019)
Vad man man göra för att förhindra och försvåra för denna typ av attacker? Jo det finns ett antal saker:
Säkra upp utvecklarkonton
Kontot som hackades hade inte tvåfaktorsautentisering påslaget. Gör detta obligatoriskt för denna typ av behörighet. Vilket är något som nu RubyGems funderar på.
Granskning av kod
Precis som processen för att publicera appar i Apple App Store eller Google Google Play så bör kod exekveras i en sandlåda och observeras. Gör den konstiga saker såsom DNS-uppslagningar som inte fanns tidigare?
Givetvis är även manuell kontroll av kod som publiceras bra, men vid många ändringar och mycket kod är det inte alltid möjligt att manuellt granska all kod.
Signering
Se till att det finns ett flöde gällande signering, från exempelvis en hårdvarunyckel såsom YubiKey där en obruten kedja kan verifiera från utvecklaren till den person som installerar paketet.
Isolering
Precis som med all obetrodd källkod som du laddar ner och kör så bör denna isoleras i största möjliga mån. Alla servrar och klienter kanske inte bör ha direkt koppling mot Internet, alla anslutningar och uppslag bör loggas.
Håll nere antalet beroenden
Om du har möjlighet att själv utveckla och underhålla delar av källkoden så är detta att fördra. Men inte alltid möjligt då vi många gånger är beroenden av tredjepartskod såsom bibliotek. Reproducerbara byggen är också ett bra sätt att försvåra för bakdörrar.
RPKI står för Resource Public Key Infrastructure och är en metod för att kryptografiskt signera BGP-annonseringar.
BGP är det protokoll som används för routrar att berätta vilka IP-adresser (prefixes) som finns hos en viss operatör. Det är därför viktigt att ingen kan falskt annonsera ut någon annans nät. Standard så fungerar BGP så att vem som helst kan annonsera ut vilket nät som helst. BGP är en viktig del i internets infrastruktur.
Exempelvis kan mail kapas och TLS-certifikat utfärdas om routes felaktigt tar en annan väg på internet. Krypterad trafik kan spelas in och försöka knäckas direkt eller på längre sikt.
RPKI finns beskrivet i RFC6480 med titeln An Infrastructure to Support Secure Internet Routing. RPKI är också en del av det globala initiativet MANRS, Mutually Agreed Norms for Routing Security som bl.a. Internet Society (ISOC) ligger bakom.
Netnod som sköter flertalet knutpunkter i Norden kommer att stödja RKPI i sin route-server under H1 2019 meddelar Netnod i följande blogginlägg.
För att gå in på mer tekniska detaljer så används ROA-records för den som vill annonsera kryptografiskt verifierbara prefixes. Sedan kan dessa ROA-records verifieras med mjukvara såsom RIPE NCC’s RPKI Validator, NLNetLab’s Routinator 3000 eller OpenBSD:s rpki-client.
Nyligen så släpptes även verktyget BGPalerter av NTT ”Software to monitor streams of BGP data. Pre-configured for announcements, withdrawals, and hijacks real-time monitoring.”
Det kanske låter som ett skämt om att köra antivirus-mjukvara på sin TV men när man tänker efter så är det inte helt osannolikt att skadlig kod kan infektera din TV-apparat. Att infektera TV-apparater är nämligen något som bl.a. CIA pysslar med enligt Vault7-läckan (Weeping Angel).
Det som är nytt nu är att Samsung skrev på Twitter att om din Smart TV från dem är ansluten till WiFi så kommer din TV nu att automatiskt genomsöka efter skadlig kod varje vecka:
Nedan följer en skärmdump på hur det ser ut när man manuellt genomsöker efter virus (från videon ovan)
Frågan som kvarstår dock är om detta är enligt ett tidigare annonserat partnerskap mellan Samsung och McAfee om att köra MacAfees antivirus på Tizen OS.
Jag tänkte försöka sammanställa några kloksaker om sådant som jag lärt mig efter nästan 20 års erfarenhet av tekniska cybersäkerhetsgranskningar från min tid inom bl.a. FRA, Försvarsmakten och nu som egenföretagare.
Desto äldre jag blir desto mer tid lägger jag på att reflektera och dra slutsatser på ett övergripande och bredare plan.
Det låter eventuellt inte som viktigt men att försöka uppskatta och prioritera den tid du fått avsatt för uppdraget är viktigt. Att inte lägga för mycket tid på sådant som kan leda in i en återvändsgränd.
Beräkna tid
Låt verktygen arbeta för dig och automatisera så mycket du bara kan och på så sätt kan du lägga fokus på sådant som kräver manuellt arbete, såsom att förstå en bakomliggande logik i ett system eller mjukvara.
Lita dock inte enbart på automatiserade verktyg utan verifiera och dubbelkolla alltid resultatet.
Kommunikation
Att upprätta en bra leverabel såsom dokumentation (rapport) och ha förmåga att kommunicera denna leverabel till din uppdragsvidare är av stor vikt för framgång. Du kanske är jätteduktig teknisk men när uppdragsgivaren väl får din leverabel två veckor för sent så minskar värdet av din leverabel.
Vet du att du är mindre bra på att kommunicera och dokumentera men duktig på teknik se då till att ditt team innehåller en eller flera personer som kan kommunicera eller dokumentera.
Stödfunktioner och processer
Att ha bra processer och rutiner samt stödfunktioner som hjälper dig och höjer dig i ditt arbete så du kan leverera enligt din optimala förmåga är viktigt. Det kan röra sig om att du slipper gå på tråkiga möten där du kanske inte har något att göra eller minimera tidsrapportering. Eller att själv slippa installera om operativsystem, drivrutiner eller liknande.
Du kan i ditt arbete luta dig tillbaka till en bra grund när det gäller hur uppdrag kommer in, fördelas, prioriteras och sedan levereras. Samt efter avslutat uppdrag hur avdukning går till.
Tillgång till Internet kanske inte finns eller bör användas, därför måste du eller dina kollegor redan innan tänka till vad som kan behövas för offline-bruk. Jag brukar se till att ha många opensource-repon, indexerade digitala böcker (många förlag kan du köpa bulk billigt) samt deb-paket tillgängliga snabbt.
Här hittar du bristerna
Min erfarenhet säger mig att säkerhetsbristerna hittar du oftast på de ställen som:
Odokumenterade funktioner/gränssnitt/API:er
Ny eller gammal kod. Sök efter kod som hanterar gamla filformat eller protokoll exempelvis
Kod som parsar text eller andra komplexa funktioner
Funktioner som kan användas på andra sätt än vad utvecklaren hade tänkt på
Felaktig eller bristfällig separation mellan behörigheter eller användare
Ändringar mot grundsystemet. De flesta operativsystem nuförtiden är relativt säkra i sitt grundutförande, sök efter ändringar som genomförts.
Ställen där du kan nå långt in i systemet eller koden med extern indata
Finns givetvis en uppsjö till med saker där jag tittar, kanske kommer eventuellt i en bok framöver.
Spårbarhet
Att dokumentera dina findings under ditt uppdrag är av stor vikt. Speciellt eftersom att du troligtvis kan hitta ett eller annat guldkorn när du granskar exempelvis alla http-svar från webbservern eller all nätverkstrafik som du sparat undan i pcap-format.
Den efterföljande dokumentationen blir också otroligt mycket lättare om du sparat undan så mycket som möjligt. Även kan skärmdumpar eller liknande också vara bra som ett komplement till din löpande textdokumentation (krigsdagbok) eller rådata.
Glöm inte heller att du måste ha en process för att på ett säkert sätt radera all information efter avslutat uppdrag om så behövs, en del av Er OPSEC.
Tänk alltid ett steg längre
Du kanske är snabb på att skjuta iväg en ny exploit från Metasploit mot en sårbar server eller klient. Men tänk efter innan vad detta kan få för konsekvenser i ett andra eller tredje steg och ni behöver göra ett omfall.
Det kan vara så att säkerhetsövervakningen (SOC) upptäcker att ni håller på att genomföra en Red Teaming operation och då kanske ni behöver byta ip-adress, mac-adress eller liknande. Och då är det viktigt att redan innan veta hur detta går till.
Övrigt
Jag försöker även alltid ha möjlighet att göra saker på minst två olika sätt, det gör att jag kan verifiera och dubbelkolla vissa saker samt om ett verktyg eller metod skulle misslyckas kan jag alltid göra på något annat sätt. Öva är även viktigt så du och ditt team eller dina verktyg och metoder fungerar när det väl är skarp verksamhet eller ett uppdrag.
Se även till att du snabbt och enkelt kan sätta upp en miljö som efterliknar målsystemet eller den mjukvara som du granskar. Det gör att du kan hitta mer brister och inte behöver skicka alla dina tester över nätverket eller liknande.
Avslutande ord
Hoppas att detta kan leda till att du, din verksamhet eller ditt team kan bli bättre på just det ni gör inom cybersäkerhet. För jag tycker det är viktigt att vi delar med oss av våra lärdomar och kloksaker till varandra och på så sätt bygger vi säkrare infrastruktur, system och mjukvaror.
Se även till att utbilda din uppdragsgivare så denne blir en bra beställare, och hjälp till med krav och förväntningar samt förutsättningar.
