Apple har släppt dokumentet Apple Platform Security, Fall 2019. Dokumentet är på totalt 157 sidor och beskriver ingående Apples olika initiativ gällande säkerhet.
Dokumentet omfattar följande avsnitt:
Hårdvarusäkerhet och biometri. Secure Enclave, AES-motorn, Touch ID och Face ID
Systemsäkerhet såsom säker uppstart, slumptal (CPRNG) och uppdateringar
Kryptering och skydd av information
Säkerhet och ekosystemet runt appar
Säkerheten runt Apples tjänster som tillhandahåller funktioner såsom Hitta iPhone osv samt kommunikation hem till moderskeppet.
Nätverkssäkerhet
Utvecklarsäkerhet
Säker hantering av enheter såsom remote wipe
Certifieringar såsom ISO, Common Criteria och Commercial Solutions for Classified (CSfC)
En av de saker som jag gillar mest av de olika säkerhetssatsningar som Apple har är deras Secure Enclave som kan ses som en variant på Trusted Platform Module (TPM):
Secure Enclave återfinnes i följande enheter:
iPhone 5s (och senare)
iPad Air (och senare)
Mac-datorer som har Apples T2 Security Chip
Apple TV generation 4 (eller senare)
Apple Watch Series 1 (eller senare)
HomePod
Även intressant är att mikrofonen stängs av i hårdvara när luckan fälls ihop på en Macbook Pro och Macbook Air (som har T2-chippet). Inte ens kerneln, root eller T2-chippet kan påverka denna funktion.
Uppdatering 2020-12-10: Idag torsdag så beslutar regeringen om införandet av detta nya cybersäkerhetscenter.
Under September 2019 gav Regeringen myndigheterna FRA, Försvarsmakten, MSB och Säkerhetspolisen ett uppdrag som gick ut på att dessa myndigheter skulle lämna förslag på hur ett nytt nationellt cybersäkerhetscenter ska utformas.
Nu har svaret skickas till Regeringen och jag har sammanfattat det nedan:
Lokaliseringen ska till början vara hos MSB i deras nya lokaler i Solna. Dock med egna konferensrum, reception etc.
20-30 personer kommer att initialt ingå från FRA och MSB men på lång sikt kommer upp till 250 personer att tjänstgöra på cybersäkerhetscentret
Försvarsmakten kommer att bidra med samverkansresurer samt analytiker och avser att rekrytera upp 10 personer för detta
Centret kommer att vara en naturlig plats för samverkansgrupper såsom Samverkansgruppen för informationssäkerhet (SAMFI).
Och tittar vi närmare på fördelarna med att inrätta ett cybersäkerhetscenter så lyfts följande delar upp:
Kortare ledtider från detektion till åtgärd.
Bättre analysresultat med ett större utbyte av information.
Ökad tydlighet i budskap och rekommendationer.
Ökad tillgänglighet till de ingående myndigheterna för såväl privata som offentliga målgrupper.
Stärkt privat-offentlig samverkan.
Ett ensat nationellt cybersäkerhetsarbete samt harmonisering av föreskrifter och skyddsåtgärder.
Effektivare användning av statens resurser.
Övriga myndigheter som är delaktiga i upprättandet av centret är PTS, FMV och Polismyndigheten.
Organisationen kommer att se ut enligt följande på en övergripande nivå:
Min egna bedömning är att jag tror att detta är mycket bra och min erfarenhet visar på mycket bra synergieffekter bara genom att vara samlokaliserade på ett och samma ställe. Dock så är det olika myndigheter med olika kulturer och mål som ska komma överens vilket kommer att ta ett tag. Även tror jag det blir svårt att rekrytera till detta center eftersom specialister inom detta område är mycket efterfrågade.
Jag tycker även att det är bra att samverkan med näringslivet tas upp i svaret och att det finns möjlighet att sprida information och samverka mot privata aktörer genom exempelvis olika Forum för informationsdelning (FIDI).
FRA besitter en unik förmåga att upptäcka avancerade cyberattacker och detta center kan troligtvis hjälpa att stärka det Svenska cyberförsvaret.
Jag tog ett snack med Jens Bogarve som är produktchef på svenska säkerhetsföretaget Advenica om deras nya lilla datadiod DD1G. Denna nya datadiod ingår i serien SecuriCDS och jag har tidigare bloggat om den större versionen som heter DD1000A. Storleken på denna mindre datadiod är 130x20x150/163 mm.
1. Vad är skillnaden mellan DD1G och de större modellerna som ni säljer exempelvis DD1000A som jag bloggade om tidigare?
Det är samma datadiodsteknik i Advenicas DD1G som DD1000A och DD1000i, prestandan är oförändrad. Skillnaden ligger förutom storleken främst i hur strömförsörjningen hanteras, i D1000A finns det möjlighet att använda separerad kraft medan i DD1G är det redundant kraft.
2. Hur ser efterfrågan ut gällande dessa. Tänkte mig att det finns ett behov av dessa mindre datadioder
Platsbrist är ett problem i flera tillämpningar, en mindre datadiod har varit önskvärt hos flera av våra kunder. Priset har också varit en faktor för våra kunder som nu ser att dom kan utnyttja datadiodens säkerhet där det tidigare inte gått på grund av ekonomiska skäl.
Vi ser också att datadioder behövs i industriellmiljö, till exempel i SCADA-nätverk, därav att vi har tagit fram en modell för DIN-skenemontage. Datadioderna blir mer och mer anpassade för den miljö dom är tänkta att verka i.
3. Kan du säga något om priset eller om hur mycket billigare denna version är jämfört med de större modellerna?
Listpriset för denna enhet är 31 448 SEK (€2995).
4. Förutom själva datadioden, vilka funktioner är det som efterfrågas som dioden ska lösa? Överföring av loggar? Patchar? Video?
Överföring av loggar och video är bra exempel på vad Advenicas DD1G kan användas till. Genom att använda någon form av proxy-server kan andra protokoll tillgodoses. DD1G agerar på Ethernet Layer 2 vilket innebär att omgivande system måste vara anpassade för enkelriktad kommunikation, till exempel genom att använda UDP.
Advenicas datadiod DD1000i har inbyggda proxy-servrar för att hantera filöverföring, email, tid och loggar.
5. Vilka branscher är det som börjar få upp ögonen för datadioder, tänker mig att organisationer inom försvarsindustri alltid varit kunder men att dioder kan användas inom många andra branscher såsom sjukvård och kryptovalutor?
Försvarsmakter hos olika länder och myndigheter är fortfarande de största användarna av datadioder. Transport, eldistribution och V/A, men även finansiella och industriella företag, ser numera fördelarna med datadioder ur ett säkerhets och ackrediteringsperspektiv.
Det är ofta branscher som berörs av säkerhetsskyddslagen som behöver bevisa enkelriktningen i informationsflödet och segmenteringen mellan olika nätverk. Största fördelen med att använda en datadiod är att den inte går att konfigurera fel så att information läcker i fel riktning, därmed blir ackrediteringsarbetet betydligt enklare.
En datadiod säkerställer att data enbart kan skickas i ena riktningen. Detta behövs när information ska skickas mellan nätverk i olika säkerhetszoner eller säkerhetsklasser.
Skiss från en presentation som FRA höll för några år sedan:
Facebook har släppt ett intressant nytt implantat (bakdörr) vid namn WEASEL. Mjukvaran är skriven i Python3 och utnyttjar DNS samt AAAA-records för att skicka och ta emot beacons. Den behöver inte heller några externa beroenden och kan således köras under de flesta operativsystem.
Ett implantat är en typ av mjukvara som används av angripare för att utföra olika uppgifter och kommunicera in och ut ur nätverk. WEASELs klientdel har inga direkta inbyggda funktioner förutom att sköta kommunikationskanalen, självradering och intervall för kommunikation. Vill du ha mer funktioner så får du själv bygga till det eftersom WEASEL stödjer exekvering (eval) av Python3-kod.
Fokus vid utvecklingen av WEASEL har varit på att försöka försvåra IT-forensiska undersökningar och därför finns ej stöd för persistens. Mjukvaran stödjer inte heller att flertalet operatörer jobbar mot samma instans.
För kryptering av data över DNS så används AES-128 i CTR mode samt Diffie-Hellman för nycklar. Oklart hur stödet för Windows ser ut men går säkert att åstadkomma med Pyinstaller.
De senaste dagarna så har det publicerats två intressanta sårbarheter som jag tänkte skriva några rader om, den första är en ”VPN bugg” som påverkar många olika typer av VPN-anslutningar och den andra handlar om en miss i operativsystemet OpenBSD som medger att flertalet autentiseringsmekanismer går att kringgå.
OpenBSD
Denna sårbarhet har CVE 2019-19521 och upptäcktes av säkerhetsföretaget Qualys. Även så finns det ett antal relaterade sårbarheter enligt följande:
CVE-2019-19520: Local privilege escalation via xlock
CVE-2019-19522: Local privilege escalation via S/Key and YubiKey
CVE-2019-19519: Local privilege escalation via su
Men den allvarligaste medger att du över nätverket (remote) kan kringgå autentiseringen i flertalet program såsom smtpd, ldapd och radiusd.
Det är nämligen så att programmet login_passwd anropas vid autentisering. Och om informationen som skickas vidare till login_passwd innehåller -schallenge som argument så returneras lyckad inloggning, se följande exempel:
Denna sårbarhet går under CVE 2019-14899 och medger att en angripare kan injicera data i en VPN-tunnel eller lista ut vilken IP som blivit tilldelad inne i en tunnel. Denna sårbarhet påverkar flertalet Linux OS, FreeeBSD, OpenBSD, Android och macOS.
Kortfattat kan man säga många operativsystem som etablerar VPN-tunnlar inte bryr sig om vilket gränssnitt som data kommer in på. Så om du har ett tunnel-gränssnitt och data helt plötsligt kommer in på ett annat gränssnitt så funkar det lika bra.
Och Colm MacCárthaigh som jobbar på Amazon meddelar att Amazon Linux inte påverkas men att attacken kan bli ännu mer allvarlig om DNS kan påverkas inne i VPN-tunneln:
Hijacking traffic via DNS is usually much more powerful than payload injection; for example an attacker can observe all connections but choose to target only connections that do not use TLS. This is more flexible and helps evade detection.
Mer omfattande information hittar du i följande PDF samt följande två intressanta patchar till OpenBSD:
Det har precis släppts en ny version av Kali Linux som går under namnet 2019.4 och är således den fjärde upplagan i år.
Jag testade att uppgradera min Vagrant-installation genom att köra:
vagrant box update
Och sedan köra en vagrant destroy samt vagrant up så lirade allt. Givetvis går det även att uppgradera genom att köra apt dist-upgrade.
Jag stöter dock på en hel del strul: Första gången jag startar webbläsaren så krashar den virtuella maskinen. Samt när skärmsläckaren går igång så låser sig hela VM:en, vet inte om detta är relaterat till VirtualBox.
Nyheter i Kali Linux 2019.4 inkluderar följande:
Ny skrivbordshanterare: Xfce
Nytt GTK3-tema
Nytt läge för “Kali Undercover”
Nytt dokumentationssystem som använder git
Public Packaging – getting your tools into Kali
Kali NetHunter KeX – Fullständig Kali desktop på Android-baserade enheter
Att man gått bort från Gnome till fördel för Xfce beror bl.a på prestandaförbättringar och att Xfce nu kan köras på flertalet plattformar som Kali stödjer såsom ARM.
Skärmdump från nya fönsterhanteraren Xfce:
Inloggningsfönstret:
Stöd för nytt ”Undercover mode” som gör att du som vill använda Kali på mer publika miljöer inte ska sticka ut allt för mycket:
Kali Linux Undercover Mode
Gillar det du läser? Stöd mig gärna via Patreon, alla bidrag hjälper.
Jag testade även att installera Microsoft PowerShell version 6.2.2 genom att köra:
apt install powershell
Och sedan testade jag att ladda hem en fil efter att ha startat ett PowerShell Shell med pwsh:
Oskar Sjöberg delade en intressant write-up om en incident i Facebook-gruppen Kodapor. Jag frågade om lov och fick delge den här nedan:
—
En kort liten write-up om en incident i en av våra kunders miljöer som jag hoppas kan vecka diskussion och/eller eftertanke.
Det hela börjar med att en av våra utvecklare reagerar på ett Javaskriptfel i sin utvecklingsmiljö i en äldre webbläsare som vi väldigt sällan testar. Skriptfelet ser ut att ha att göra något med att hämta GPS-positionering att göra. WTF. Vi har väl inte någon sådan funktion i vår kodbas?
Efter lite letande kommer vi fram till att koden dessutom ligger i en <script>-tag, i en SVG fil och är inte i närheten av att likna något av koden vi skriver. Kryptiska identifierare, koden ser ut att försöka injicera sig själv in i andra dokument. Oj. Den koden ligger i produktion också. Gulp. Något är väldigt skumt.
Har vi blivit utsatta för en attack? Snabbt konstaterar vi att SVG filen i fråga har koden i sig incheckad i vårt repo sedan en tid tillbaka. Hur i h…? Någon minut senare kan vi konstatera att en utvecklare har checkat in filen med scriptet i. Snabbt söka igenom alla SVG filer med <script>-taggar. Skönt, det var bara den. Snabbt ut med ny version av systemet med fixad SVG-fil.
Hur fick vi in den koden i en av våra SVG-filer? Jag söker på nätet och hittar en issue på Github som klagar på att verktyget SVGOMG (online verktyg för optimering av SVG filer) smittar ner SVG med liknande kod som den vi har sett. SVGOMG används mycket riktigt av utvecklaren. Issuen är dock stängd med en kommentar om att problemet ligger i ExpressVPN.
Jag frågar utvecklaren om han har ExpressVPN installerat, det har han. Det verkar alltså som att VPN tjänsten ExpressVPNs Chrome-extension patchar DOMen med Javascriptkod som injicerar sig själv. Eftersom SVGOMG jobbar helt i browsern med att optimera SVG så injiceras även koden i det optimerade resultatet.
Jag kan inte enkelt avgöra om ExpressVPNs beteende är ondskefullt eller om det är en defekt i deras mjukvara. För mig är det här verkligen en ögonöppnare över hur relativt lätt det går att smyga in obetrodd kod i någon annans produktionsmiljö via något så oskyldigt som lite grafik.
Jag bifogar länken till koden som i mångt och mycket liknar koden som dök upp i vår produktionsmiljö.
I takt med att allt mer datatrafik på våra nätverk blir krypterad så ställs större krav på möjlighet att inspektera den krypterade nätverkstrafiken antingen via TLS-inspektion (TLSI) eller på ändpunkterna. Men det går fortfarande att utläsa en hel del från att granska krypterad nätverkstrafik.
Google uppger att 93% av all inkommande E-post är krypterad med STARTTLS för att ge en siffra på hur mycket som är krypterad E-post. Hittar tyvärr ingen statistik hur förhållandet mellan https och http ser ut.
När det gäller analys av krypterad datatrafik så finns det flertalet saker man kan titta på, främst följande punkter:
Protokollinformation – Varje krypterat protokoll har som oftast någon form av handskakning som avslöjar information om både klient och server. Det kan röra sig om vilka algoritmer som supportas eller publika nycklar.
Om du inte vet vilket protokoll det rör sig om kan du även titta på sekvenser som förekommer i den session du kollar på och sedan jämföra den med andra (om du har tillgång till andra).
Informationsmängd – Hur mycket datatrafik skickas och åt vilket håll skickas detta. Kan det röra sig om en större filöverföring, och hur stor är dessa filer? Kan det röra sig om överföring av tangentbordsinmatningar, tal eller skärmuppdateringar? Entropi kan också avslöja information om innehållet.
Tidpunkt – Kommunicerar detta krypterade protokoll enbart vissa tider eller veckodagar. Eller är det vid speciella händelser som inträffar som data skickas.
Ändpunkter – Vem kommunicerar med vem? Vilka är källorna och vilka är destinationerna. Om det är en publik VPN-tjänst så kanske det räcker med enkel OSINT för att identifiera vilken typ av VPN-tjänst det är. Det kan även vara så att DNS har nyttjats för att göra en uppslagning innan sessionen etableras.
Omförhandlingar – Sker det någon form av byte av nycklar eller liknande efter en viss tidpunkt eller informationsmängd? Hur långa är sessionerna?
TCP/UDP och portnummer – Har ett nytt portnummer slumpats fram eller är det en välkänd port med tillhörande protokoll, används TCP eller UDP.
Fel(injektioner) – Hur reagerar anslutningen om olika typer av fel introduceras. Passiva eller aktiva där data skickas direkt till ändpunkterna eller om paket tappas.
Övrig kommunikation – Går det kommunikation till och från enheten som kan avslöja information om vilken typ av krypterad anslutning som förekommer. Det kanske är så att vissa anrop går över http och vissa över https. Då kan exempelvis en User-Agent http-header avslöja något om källan.
Antalet paket och paketstorlekar kan också vara relevant att titta på.
Verktyg för analys av krypterad kommunikation
Det viktiga här är att poängtera att det inte finns ett verktyg som löser alla frågor som jag listat ovan. Oftast får du kombinera flertalet verktyg för att ta reda på svaret. Men följande produkter/verktyg hjälper dig en lång väg på traven:
Zeek (bro) – Har ett stort ekosystem samt inbyggt stöd för flertalet intressanta analyser. Kan exempelvis kontrollera revokering av certifikat, algoritmer och mycket mer.
Wireshark/tshark – Förstår flertalet protokoll och underlättar analyser av specifik metadata. Men tyvärr så fort ett standardprotokoll går på en avvikande port så blir det problem för Wireshark. Men detta är något som bl.a. Network Miners Port Independent Protocol Identification (PIPI) fixar.
Tcpdump – Snabbt verktyg och gör mycket av grovjobbet. Gör att du enklare kan göra en första filtrering på källa/destination eller port.
Viktigt också och nämna följande verktyg:
HASSH – Gör fingerprints på ssh-klienter och servrar
JA3/JA3S och JA3ER – Gör fingerprints på SSL/TLS klienter och servrar. Och JA3ER är en databas för dessa fingeravtryck
Amerikanska säkerhetsmyndigheten NSA går nu ut och varnar för Transport Layer Security Inspection (TLSI). Anledningen till att NSA nu varnar för TLSI är för att metoden att granska nätverkstrafik som går in och ut ur organisationer blir allt vanligare samt att denna metod även medför ett antal olika säkerhetsrisker.
Några anledningar till att TLSI blir allt vanligare är för att kontrollera att nätverkstrafiken inte innehåller någon form av skadlig kod eller att klienter kommunicerar med skadliga webbplatser eller Command and Control-servrar (C&C). Denna form av inspektion kan också förekomma i enheter såsom Deep Packet Inspection (DPI) eller NIDS/IDS, Network Intrusion Detection Software.
Exempel på hur det kan se ut med och utan TLS-inspektion:
Bild från NSA
Problemen som NSA pekar på
Men vilka problem är det då som kan uppstå med denna set-up? Jo det finns flertalet problem som jag tänkte gå igenom här:
Validering av certifikat – Tidigare undersökningar visar på att certifikatvalideringen i TLSI-enheter inte varit 100%-ig och detta ökar risken för bl.a. man-i-mitten attacker.
Algoritmer och SSL/TLS-versioner – Precis som förra punkten så kan brister i SSL/TLS-handskakningen eller val av algoritmer påverka säkerheten såsom nedgraderingsattacker.
Tillgången till klartext – Det finns en punkt i organisationen där någon kan läsa och modifiera klartexttrafik. Detta är ett problem ur säkerhetssynpunkt men även integritet. Ett intrång kan även leda till att klartexttrafik kan läsas.
Insiderhotet – En person som har tillgång till trafiken kan läsa ut lösenord. Se till att ha en särskild granskningsroll som kan se vad TLSI-administratörerna gör för något.
Observera också att en TLSI kan användas både för utgående trafik från klienter men även inkommande (reverse proxy) för exempelvis webbsajter. Värt att nämna här är även den sårbarhet i F5:s produkter som Christoffer Jerkeby hittade. Vill du själv testa TLSI så kan jag rekommendera Erik Hjelmviks PolarProxy.
En annan sak som NSA lyfter i rapporten är även att du bör undvika att bädda in flertalet produkter där din klartext flödar. Försök att hålla ner komplexiteten för riskerna ökar med antalet produkter samt så försvåras felsökning. Certifikatspinning kan också bli ett problem samt så påpekas att HTTP Strict Transport Security (HSTS) inkluderar stöd för att binda en TLS-session(?).
Rapporten från NSA kan du hitta i sin helhet här:
MANAGING RISK FROM TRANSPORT LAYER SECURITY INSPECTION
Dokument från amerikanska justitiedepartementet visar på hur flertalet insiders tagit jobb hos företag Twitter för att spionera på dissidenter via plattformen.
Information om kritiska konton såsom E-postadress och telefonnummer har troligtvis stulits och skickats vidare till kungadömet i Saudiarabien.
De två personerna Mr. Alzabarah och Mr. Abouammo har nu efterlysts av FBI och finns nu med på deras lista med följande förklaring:
Ali Hamad A Alzabarah is wanted for failing to register as an agent of a foreign government as required by United States law. In 2015, Alzabarah allegedly took part in a scheme to steal proprietary and confidential user data from a U.S. company, Twitter, for the benefit of the Kingdom of Saudi Arabia.
The stolen data included email addresses, telephone numbers and internet protocol addresses of Saudi dissidents and critics of the Saudi government, among others. A federal arrest warrant was issued for Alzabarah in the United States District Court, Northern District of California, on November 5, 2019, after he was charged with acting as an unregistered agent of a foreign government.
Den person som först approcherade och lyckades rekrytera dessa två Twitter-anställda som agenter jobbade med en täckmantel under organisationen MiSK Foundation.
Information om cirka 6000 konton har läckt från Twitter uppger en källa till New York Times. Detta inträffade under 2015 och personerna fick efter ett tag lämna Twitter.
Det modus operandi som Saudiarabien följt här är eg ”by the book” och inget som är speciellt konstigt. De lyckades rekrytera två insiders som hade behörigheter att göra sökningar i Twitters databaser.
