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.
Intel gick nyligen ut med en mängd olika säkerhetsrelaterade uppdateringar som totalt berör 77 identifierade säkerhetsbrister. Dock är inte alla helt enkla att patcha och har gjort att flertalet operativsystem såsom FreeBSD släppt patchar för microcode. Minst en av buggarna är liknande Spectre och Meltdown som släpptes i Januari 2018.
Kör du Linux kan du se vilken version du har genom att köra något av följande kommandon:
Uppdateringar ska sedan installeras per automatik via paketet intel-microcode vid apt update.
Den sårbarhet med högst CVSS-score är CVE-2019-0169 med ett score på 9,6 som är kritiskt. Just den buggen är en remote heap-overflow som återfinnes i Intel CSME.
Sårbarhetsanalyser har över 20 år varit en hörnsten i ett bra IT-säkerhetsarbete. Allt fler organisationer stärker upp sin säkerhet. Då landskapet ändras snabbt växer behovet av kontinuerliga skanningar. Historiskt har många inte gjort skanningar alls, eller bara enstaka skanningar internt eller externt.
Marknaden har historiskt dominerats av ett par aktörer från USA såsom Nessus från Tenable, men nu finns en alternativ produkt från svenska Holm Security.
Genom att göra kontinuerliga och automatiserade skanningar upptäcker du t.ex. löpande utdaterad mjukvara, felkonfigureringar, bristfällig kryptering och svaga lösenord. Dessutom är det ett effektivt sätt att upptäcka det man kallar blank spots, alltså delar i er IT-miljö som kan vara förbisedda. Sårbarhetsanalyser ger dig bra kontroll på din IT-säkerhet och kombineras med fördel med mer traditionell penetrationstestning.
Skärmdump från Holm Securitys administrationsgränssnitt Security Center:
Holms backend bygger på två olika skannings-motorer som kan ses i gränssnittet ovan. En motor för webbskanningar och en för nätverksskanningar.
För den som gillar API:er och programnära gränssnitt så finns det ett REST API med exempelkod på Github här: https://github.com/holmsecurity/api-examples och dokumentation för API:et kan du hitta här.
När jag testade produkten så så körde jag tester mellan 2019-06-10 – 2019-07-06. Jag skannade en testmiljö med 37 IP-nummer och 1 st så kallad Damn Vulnerable Web Application/DVWA. Nätverksskanningen tog i snitt 13 minuter och webapplikationsskanningen 7 minuter. Rekommenderat är att köra automatiska scanningar så ofta som möjligt utan att det påverkar prestanda i applikationer eller nätverk.
Om du vill testa lokala nätverk innanför brandväggar eller liknande så finns det en Scanner Appliance (SA) som går att ladda hem som en virtuell server. Obegränsat med SA går att använda och prissättningen är satt utifrån antalet IP-adresser eller webbsajter/tjänster du vill skanna av.
Prisexempel:
Skanning av 100 IPn och 5 webbappar kostar 53 356 kr/år exkl moms.
En annan intressant produkt förutom intern och extern scanning är att du kan göra phishing-tester via E-post. Det finns ett antal standardmallar du kan använda och sedan skicka ut till organisationen och mäta statistik. Inga inviduella personer pekas därmed ut.
Skärmdump på assessments/riskanalys:
Riskanalys av användare för 250 e-postadresser kostar runt 21 000 kr/år exkl moms.
Bakom Holm Security står gänget som startade Stay Secure och som således till J2 Group år 2014. Och en annan sak de har lagt mycket krut på är onboarding-processen för nya organisationer, att det ska vara så snabbt och enkelt att komma igång.
Holm Security får 4/5 Enigmor:
Transparens: Jag sitter med i Advisory Board hos Holm Security samt äger en pytteliten andel i företaget.
Riksrevisionen släppte under morgonen en ny rapport där de har tittat på förekomsten av föråldrade IT-system hos cirka 60 större myndigheter.
Slutsatserna i rapporten är att det förekommer föråldrade IT-system i ett stort antal myndigheter samt att många myndigheter har dessutom ett eller flera verksamhetskritiska it-system som är föråldrade.
Givetvis är bristfällig cybersäkerhet en stor risk när det gäller föråldrade IT-system och 80 procent av myndigheterna uppger att man har svårigheter att upprätthålla eftersträvad nivå av informationssäkerhet.
Och när det gäller verksamhetskritiska system svarar 12 procent av myndigheterna att det är ett problem att upprätthålla eftersträvad nivå av informationssäkerhet för samtliga eller en majoritet av de verksamhetskritiska systemen.
Tittar vi på återkommande riskanalsyer så det också rätt dystert ut:
Men hur många verksamhetskritiska system finns det då hos våra myndigheter? Det varierar otroligt mycket mellan 2 och 800 där medelvärdet är 47 och en median på 11,5. Ett fåtal myndigheter har ett stort antal system och vanligtvis så är det 10–12 verksamhetskritiska it-system på myndigheterna.
Här kan du ladda hem rapporten:
Riksrevisionens rapport: Föråldrade it-system – hinder för en effektiv digitalisering.pdf
Totalförsvarets forskningsinstitut (FOI) har släppt en ny rapport om säkra leverantörskedjor för styrsystem. Rapporten visar på en ny trend när det gäller leverantörsskedjor som representeras av ett växande antal specialiserade leverantörer. Kedjan från leverantör till driftsatt industriellt informations- och kontrollsystem (ICS) blir då lång och komplex.
Rapporten går igenom olika regulatoriska krav såsom NIS-direktivet, Cyber Security Act och även branschpraxis samt rekommendationer från bl.a. ISO/IEC, MSB, FRA och CPNI.
Även intressanta saker såsom ansvarförhållanden och förtroendenivåer mellan operatörer och leverantörer tas upp i rapporten och hur dessa förhåller sig mellan olika standarder.
Rapporten är på 52 sidor och kan hittas här som PDF:
Säkra leverantörskedjor går under benämningen Supply Chain Cyber Security på engelska. Författare till rapporten är Erik Zouave och Margarita Jaitner.
Tidigare idag så släpptes det en ny exploit som fungerar till nästan alla iPhone-modeller: Från iPhone 4S upp till iPhone X och är enbart patchad i modeller som har A12 och A13 CPU:er från Apple.
Och senast en Boot ROM exploit släpptes publikt var George Hotz (geohot) som släppte en 2010.
Sårbarheten som utnyttjas återfinnes i iPhonens Boot Rom, även kallad Secure ROM och gör att en angripare med fysisk tillgång till telefonen kan utnyttja denna sårbarhet som går under namnet checkm8.
Detta är så klart inte bra för säkerheten men en glad nyhet för alla som gillar jailbreaks. Dock har Apple haft med denna typ av sårbarheter i boot-kedjan när de byggde Secure Enclave (SEP) och det är i dagsläget oklart hur SEP kan hjälpa mot checkm8-exploiten.
För att förmildra effekterna av denna sårbarhet så rekommenderas det att du använder alfanumeriska tecken och inte enbart siffror som kod för din telefon.
Denna sårbarhet gäller även iPads och ej enbart iPhones och går ej att åtgärda från Apples sida. Men sårbarheten måste troligtvis utnyttjas tillsammans med någon annan sårbarhet för att tillgång till data eller full kontroll över en mobiltelefon:
”Researchers and developers can use it to dump SecureROM, decrypt keybags with AES engine, and demote the device to enable JTAG. You still need additional hardware and software to use JTAG”Källa
