Så utvecklas ett cybervapen

Cybervapen i ett cyberkrig

Vad är det som skiljer vanlig skadlig kod mot ett avancerat cybervapen och hur utvecklas ett cybervapen?

🚀 Stöd mitt bloggande via Patreon: https://www.patreon.com/kryptera

Enligt många säkerhetsforskare var Stuxnet ett av de första och mest uppmärksammade cybervapnet. Resurserna som behövdes för att utveckla Stuxnet och dess olika delar är troligtvis något som enbart en nation har: Flertalet programspråk, mängder av moduler, flertalet zero-days, kunskap om urananrikningsanläggningen Natanz centrifuger och stulna certifikat för att nämna några delar som gör att det troligtvis ligger en stat bakom.

Leveransdelen

Denna del av cybervapenet gör att den träffar sitt mål. Eller når rätt klient, hårdvara eller nätverk. Leveransen kan ske via E-post, USB-minne, CD-skiva eller fysiskt ansluta mot den server, klient, TV eller liknande. Vilket bl.a Vault7 läckorna från CIA visade på. Inte helt ovanligt att HUMINT- och SIGINT -resurser nyttjas.

Leveransdelen kan också ske i form av ett implantat som installeras när utrustningen skickas ut till kund. För att nå sitt slutgiltiga mål som kanske är längre in i nätverket kan även zero-days användas eller kod för att detektera och ta sig förbi airgaps eller luftgap som det också kallas. Nätverk som är känsliga och inte anslutna till internet exempelvis.

Verkansdelen

Verkansdelen tillgodoser att målet med cybervapnet uppnås. Det kan vara att påverka en process i ett SCADA-system eller förstöra vitala delar i samhällskritiska system. Även kan detta vara att exfiltrera känslig information från målsystemet.

cybervapen

Kommunikationsdelen

Denna del är inte alltid nödvändig men gör det möjligt att via ett unikt ID ringa hem och meddela att cybervapnet har nått sitt mål eller utfört ett delmål. Kommunikationsdelen är också viktig om cybervapnet ligger dolt under en längre tid och ska aktivera verkansdelen på ett givet kommando.

För att försvåra upptäckt via nätverksforensik och IDS:er (intrångsdetekteringssystem) kan populära sajter såsom Dropbox, Twitter.com eller Instagram användas, givetvis krypterad med TLS.

Steganografi där meddelanden exfiltreras med hjälpa av bilder har även observerats samt kommunikation mot IP-adresser där satellitlänk används och antagonisten haft möjlighet att läsa av kommunikationen med hjälp av SIGINT (signalspaning) eller annan utrustning.

Om kommunikationsdelen använder redan befintlig infrastruktur för att uppdatera mjukvara eller kontrollera om nya versioner finns tillgängliga så är detta också svårt att detektera (se källa 4 nedan).

Kommunikationsdelen kan också användas för att ladda hem och aktivera nya moduler, droppers etc.

Stealth-mode

Det finns många sätt att försöka undgå upptäckt. Jag har tagit upp några sätt här på bloggen tidigare såsom ”Living-off-the-land” där komponenter som redan finnes i systemet återanvänds för andra syften.

En av de äldsta och vanligaste förekommande metoderna är obfuskering eller kryptering. Även kan relativt enkla saker såsom modularitet göra att det är svårt att se helheten i cybervapnet, exempelvis kan sniff-funktioner ligga i en modul, keylogger i en modul osv.

Även så finns det något som heter environmental keyed payloads där en modul kan vara krypterad med en nyckel som bara återfinnes i målnätverket eller systemet.

En annan viktig aspekt är OPSEC för de som utvecklar cybervapen. För allt lämnar spår och något som blir vanligare och vanligare är falskflaggning eller ”false flag”. Spåren kanske ser ut att peka mot ett land men kan i själva verket vara utvecklat av ett helt annat: Språk, tidzoner osv som kan ändras.

Persistens

Ibland så ligger verkansdelen enbart i enhetens RAM-minne och försvinner således om enheten krashar eller startar om. Men som vanligast så vill den som skapat cybervapnet att det ska ligga kvar under en längre tid och då finns det otroligt många sätt att gömma sig.

Jag gjorde denna video för ett tag sedan då jag går igenom 10 olika sätt att lägga in bakdörrar:

Propagering

En skillnad mellan exempelvis WannaCry och ett cybervapen är att cybervapnets målsättning enbart är att propagera inom ett mindre område. Det kan röra sig om en enskild organisation eller nätverk. Med en mindre spridning blir också en eventuell detektion svårare.

Propagering kan dock vara ett måste som jag skrev under leveransdelen så kanske det finns luftgap mellan processnätverket/hemliga nätverket och internet.

Upprensning

Den eller de aktörer som lägger resurser på att utveckla ett cybervapen vill gärna inte bli upptäckt. När uppdraget är slutfört ska vapnet radera sig själv, även kan det finnas en inbyggd räknare som automatiskt ser till att radering genomförs efter exempelvis 12 månader.

Ett cybervapen kan även innehålla zero-days som utnyttjar sårbarheter och dessa vill även antagonisten radera alla bevis om, för då kan de använda sårbarheten mot fler mål.

Gillar du detta blogginlägg? Bli gärna månadsgivare via Patreon:

Källor

  1. Turla malware
  2. Gauss payload
  3. Falskflaggning med CIA Marble framework
  4. M.E.Doc och C&C via uppdateringsservrar, NotPetya

Shodan Monitor

Shodan Monitor

Shodan är en onlinetjänst som har funnits sedan 2009 och söker kontinuerligt av hela internet med omfattande portskanningar. Tjänsten är omtyckt och ger bra statistik samt har en sökfunktion som visar sådant som organisationer exponerar mot internet.

För några veckor sedan så släppte Shodan en ny intressant funktion som går under namnet Shodan Monitor. Med hjälp av Monitor kan Er organisation övervaka den internet-exponering ni har och få notifieringar över händelser.

Även för mig som konsult kan detta vara intressant då jag kan övervaka mina kunder och meddela dem om något nytt suspekt dyker upp eller som ett OSINT-verktyg vid RedTeam och penetrationstester.

Det går att lägga upp nya nät och övervaka via webbgränssnittet som återfinnes på monitor.shodan.io eller direkt via CLI och det python-program som Shodan tillhandahåller (byt ut APIKEY mot din nyckel och ALERTID mot det ID som returneras)

sudo pip install shodan
shodan init APIKEY
shodan alert create "My Production Networks" 198.20.0.0/16 8.20.5.0/24
shodan alert triggers
shodan alert enable ALERTID malware

När du skriver shodan alert triggers så kan du se vilka larm du kan slå på eller av. Listan ser ut enligt följande:

Du kan även ange ”any” och då får du larm för samtliga ovan kategorier:

shodan alert enable ALERTID any

Innan du kan övervaka några IP-nummer så måste du först bli betalande medlem. Jag valde den nivå som heter Freelancer och gör att jag kan lägga upp övervakning 5120 IPs och kostar 59$ per månad (ca 560 kr). Övriga nivåer är enligt följande:

  • $299 /månad (2 865 sek) ger dig 65536 IPs
  • $899 /månad (8 614 sek) ger dig 300000 IPs

Efter några timmar dyker det första larmet upp i min E-post. Relativt ointressant men som tur var så finns det även en möjlighet att vitlista vissa portar, så här ser mailet ut:

Och längst ner så finns länken ”Ignore this event in the future”.

Andra användningsområden för Shodan Monitor kan också vara för nät som ingår i Bug Bounty-program. Du får även använda tjänsten i kommersiellt syfte.

Samtliga argument till shodan alert för den som kör med python-mjukvaran:

Det är även möjligt att erhålla realtidsdata via shodan stream på följande sätt:

Video med demo:

Aktiva attacker mot Oracle WebLogic

En ny säkerhetsbugg har identifierats i Oracle WebLogic och utnyttjas just nu av angripare på Internet för att installera kryptominers. Sårbarheten är ett serialiseringsproblem och har fått CVE nummer 2019-2725. CVSS base score ligger på hela 9.8.

Du bör uppgradera till version 10.3.6 (?) och en patch för version 12.1.3 kommer på måndag uppger Oracle.

SANS ISC som kör en Weblogic honeypot fick upp följande meddelande:

####<Apr 28, 2019 10:47:02 PM UTC> <Error> <HTTP> <0aa00a61ebfc> <AdminServer> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1556491622309> <BEA-101019> <[ServletContext@2141998910[app:bea_wls_internal module:bea_wls_internal.war path:/bea_wls_internal spec-version:null]] Servlet failed with IOException
java.io.IOException: Cannot run program "wget": java.io.IOException: error=2, No such file or directory

Angriparen försöker här köra wget, men wget finns inte installerat på systemet. Även finns det indikationer på att Muhstik Botnet samt Sodinokibi ransomware nyttjar säkerhetsbuggen.

ISC har även publicerat en PCAP-fil med denna förfrågan:

Threat Hunting med Maltrail

Maltrail är en open-source mjukvara för att upptäcka skadlig kod, skriven i programspråket python. Mjukvaran består av en serverdel och en klientdel som kan köras fristående.

Maltrail kan titta på nätverkstrafik och larma om något av följande matchar någon av de medföljande listorna:

  • HTTP Host Headers
  • DNS-uppslag
  • IP-adresser
  • URL
  • User-agent

För att installera Maltrail så klonar du bara hem Git-repot och installerar beroenden såsom python-pcapy. Jag kör dessa tester på en Raspberry Pi och det fungerar fint.

Och när du startar upp Maltrail för första gången så laddas 68 stycken olika publika listor hem med IOCer:

Förutom att sniffa nätverkstrafik direkt mot ett interface så kan köra sensor.py mot en pcap-fil på följande sätt:

$ sudo python sensor.py -i /data/pcap/trace_2018-12-15_14.54.33.pcap

Och vill du se vad som larmar direkt till konsollen kan du starta Maltrail på följande sätt med –console:

sudo python sensor.py -i /data/pcap/trace_2018-12-15_14.54.33.pcap --console

En annan sak som jag noterar är att dessa 68 st listor som laddas hem innehåller hela 1 396 712 st IOC:er.

Det pcap-filter som används som standard är enligt följande:

udp or icmp or (tcp and (tcp[tcpflags] == tcp-syn or port 80 or port 1080 or port 3128 or port 8000 or port 8080 or port 8118))

Vilket den observanta läsaren kan se att HTTPS tcp port 443 exempelvis inte finns med, dock all ICMP och UDP. Som standard kontrollerar inte maltrail http-host headern men detta kan snabbt ändras i maltrail.conf som du bör ta en titt på. Du kan även ändra pcap-filtret i konfigurationsfilen, men då tar analysen givetvis längre tid.

Att analysera en 2.2GB pcap-fil med min Raspberry Pi 3 Model B+ tog cirka 3 minuter. Då hade jag satt USE_HEURISTICS till false samt CHECK_HOST_DOMAINS till true, främst för att USE_HEURISTICS gav så många false-positives.

För den som gillar trevliga webb-gränssnitt så finns det även ett till Maltrail och startas upp med server.py:

Sedan är det bara att surfa till IP-adressen där du har Maltrail installerat och port 8838. Du måste även logga in med användarnamn och lösenord som är satt till admin/changeme! som standard. Går givetvis att ändra i konfigg-filen, och server.py stödjer även SSL/TLS.

Följande bild är en skärmdump på en dag där det identifierats 145 st threats:

Maltrail larm
src_ip och dst_ip är maskerade på bilden ovan

Majoriteten av larmen som dykt upp under mina tester är klassificerade som medium eller low. Och precis som vid Threat Hunting så är det viktigt att följa upp varför just dessa larm uppstår, jag rekommenderar att använda Moloch eller Argus-data för vidare analys. Vid denna vidare analys kan det vara intressant att kolla källan som framgår samt om du har rådata i pcap:ar kvar så bidrar även detta till större framgång.

Ett annat tips är att kolla datakällor såsom Zoomeye, Censys.io och Shodan där dessa IP-nummer eller domäner kan identifieras.

Docker Hub hackade

Inatt så hackades tjänsten Docker Hub. Enligt många var det bara en tidsfråga innan just Docker Hub skulle hackas. Det är nämligen så att de templates för operativsystem som den populära mjukvaran Docker använder hämtas hem från Docker hub. Sedan några år är Alpine Linux den standard Linux-dist som används av Docker.

Om en bakdörr skulle läggas in i något av de mer populära avbildningsfilerna såsom Alpine på Docker Hub så skulle troligtvis tusentals installera denna avbildning automatiskt.

I sitt utskick så meddelar Docker att mindre än 5% av kontona kan ha blivit röjda vilket rör sig om ungefär 190 000 konton. Även bör dessa konton återställa sina länkade Bitbucket samt GitHub-konton. Du kan nämligen länka dessa tredjepartstjänster mot ditt Docker Hub-konton via oauth, för automatiska byggen.

På HackerNews klagar många på hur just integrationen mot Github fungerar och att det krävs skriv samt läsrättigheter till hela kontot (om man inte använder Github Apps). Även så vore det trevligt om Alpine var ett reproducerbart bygge för att öka transparensen och göra det lättare att upptäcka bakdörrar. Dock finns det inget som tyder på att bakdörrar har lagts in i detta skede.

Meddelanet som skickades ut:

Facebook underlättar för whitehats

Facebook har nu infört en ändring i dess mobila appar som underlättar för den som vill inspektera trafiken från apparna till Facebooks servrar.

Tidigare har Facebook anammat strikt TLS-pinning och således försvårat för den som vill titta på underliggande protokoll och försöka identifiera säkerhetsbrister inom Facebooks Bug Bounty-program.

Men med denna nya inställning så kan du slå av pinning och tillåta egna TLS-certifikat. Även kan du tillåta att Facebooks förfrågningar går igenom en proxy, själv gillar jag Burp Suite.

Inställningarna gäller för Messenger, Facebook samt Instagram och hittas under menyn Settings och sedan Whitehat Settings:

Och så här ser det ut via webbläsare och Facebook.com där du först måste aktivera denna funktion:

Nationell handlingsplan för samhällets informations- och cybersäkerhet

Samverkansgruppen för informationssäkerhet (SAMFI) har nu släppt en nationell handlingsplan för samhällets informations- och cybersäkerhet. Handlingsplanen består av 77 förslag på åtgärder och kommer att uppdateras årligen under åren 2019 fram till 2022.

Följande myndigheter har varit med och tagit fram handlingsplanen:

  • Myndigheten för samhällsskydd och beredskap (MSB)
  • Försvarets radioanstalt (FRA)
  • Försvarets materielverk (FMV)
  • Försvarsmakten
  • Post- och telestyrelsen (PTS)
  • Säkerhetspolisen
  • Polismyndigheten

Dock ska rapporten inte ses som en komplett redovisning av alla de åtgärder som de olika myndigheterna avser att genomföra inom sina respektive verksamheter på informations- och cybersäkerhetsområdet.

De 77 förslag som presenteras i rapporten på åtgärder ansluter till Sveriges nationella strategi för samhällets informations- och cybersäkerhet (skr. 2016/17:213).

Strategin omfattar sex strategiska prioriteringar:

  • Säkerställa en systematisk och samlad ansats i arbetet med informations och cybersäkerhet
  • Öka säkerheten i nätverk, produkter och system
  • Stärka förmågan att förebygga, upptäcka och hantera cyberattacker och andra it-incidenter
  • Öka möjligheterna att förebygga och bekämpa it-relaterad brottslighet
  • Öka kunskapen och främja kompetensutvecklingen
  • Stärka det internationella samarbetet

Här kan du ladda hem handlingsplanen som PDF:

Test av OnionShare 2

För cirka ett år sedan så skrev jag om OnionShare som gör att du kan dela filer anonymt över Tor-nätverket. Det har nu kommit en ny version som innehåller en mängd nyheter och förbättringar som jag tänkte kolla närmare på.

Den största och kanske mest intressanta nyheten i OnionShare version 2 är att du nu kan ta emot filer. Du kan alltså starta upp en anonym webbserver på Tor-nätverket som kan ta emot filer från en eller flera personer. Den som skickar filer till dig kan exempelvis använda sig av Tor Browser.

OnionShare stödjer nu även nästa generations .onion-adresser även kallat v3 där SHA1/DH/RSA1024 är utbytt mot SHA3/ed25519/curve25519 samt andra säkerhetshöjande åtgärder.

Som standard när du delar ut filer så förutom .onion-adressen som temporärt genereras så genereras även en url-slug som består av 2 ord diceware (obligatorisk xkcd-länk). För att ingen ska kunna forcera dessa två ord så fanns det en räknare som kontrollerade hur många 404-not found som anropats.

Om denna räknare var mer än 20 st felaktiga URL:er (404:or) så stängdes utdelningen ner, och just detta kan vara ett problem om du har en utdelning som många ska kunna ta del av. Säg att du vill exempelvis vill dela något offentligt på Twitter utan att webbservern stänger ner. Därför finns det nu stöd för publika fildelningar, eller offentligt läge. Då stängs denna funktion av som stänger ner webbservern vid för många 404:or.

OnionShare finns nu också översatt till 12 språk där ett av dessa språk är svenska. OnionShare stödjer inte https, men det gör inte så mycket eftersom Tor är end-to-end krypterat så länge trafiken håller sig inom nätverket och inte går ut via en exit-nod.

Become a Patron!

Än så länge finns inte OnionShare version 2 med i Tails, men det kommer nog så småningom. Värt att notera är att OnionShare inte ska ses som ett alternativ till SecureDrop, även om du kan köra OnionShare headless.

OnionShare är utvecklat i Python och använder sig av webbramverket Flask.

Så här ser OnionShare 2 ut på macOS och på svenska vid en uppstart:

Väljer jag sedan att dela ut en fil så ser det ut enligt följande:

Och för den som besöker ovan URL med Tor Browser så ser det ut så här:

När du startar upp en anonym mottagningstjänst för filer ser det ut så här efter jag tagit emot testssl.sh:

Och för den som laddar upp filer via Tor Browser ser det ut så här:

Allvarlig RCE-sårbarhet i Drupal

computer code and system attacks. Conceptual online security background

Populära open-source CMS:en Drupal släppte precis ett antal kritiska säkerhetspatchar som gäller RCE (Remote Code Execution).

Bristen gäller enbart om något av följande är uppfyllt:

  • The Drupal 8 core RESTful Web Services (rest) module enabled and allow PATCH or POST requests, or
  • Another web services module enabled, like JSON:API in Drupal 8, or Services or RESTful Web Services in Drupal 7.

Uppgradera snarast till version 8.6.10 eller 8.5.11 där fix för denna sårbarhet finnes. Observera att versioner före 8.5.x är end-of-life och ej erhåller säkerhetsfixar.

Sårbarheten har fått CVE-2019-6340 och mer information finnes på Drupal.org.

Analys av 1177-läckan

1177 vårdguiden

Igår så tipsade en anonym person sajten Computer Sweden att miljontals inspelade samtal till vårdupplysningstjänsten med telefonnummer 1177 låg tillgängliga för allmänheten på en webbserver. Denna server har används som backup-server av företag som upphandlats av tre landsting.

Servern är en gammal Apache-server som bland annat verkade ha mjukvaran ownCloud och går under namnet NAS, Network Attached Storage. ownCloud gör att du kan sätta upp din egen molntjänst on-prem (hos dig själv).

Vid upphandlingen av leverantören så ställdes ett antal krav hur denna känsliga information skulle vara tillgänglig. Bl.a. skulle SITHS-kort användas för att komma åt informationen (se länkar nedan).

Men trots dessa krav på leverantören, hur kunde det går fel? Jag gissar på att ingen följt upp och kontrollerat kraven med hjälp av tillsyn. Skulle återkommande penetrationstester eller automatisk sårbarhetsskanning genomföras så skulle det inte troligtvis inte ha hänt. Något som bl.a. kreditkortsstandarden PCI-DSS ställer krav på.

Även så rekommenderar vi som jobbar med säkerhet både hängslen och livrem. Det som har hänt här är att företaget troligtvis kopplat något fel eller genomfört en felaktig konfiguration, jag tror inte heller att filerna legat uppe sedan 2013. Utan att misstaget genomfördes någon gång förra året under 2016. Men ett enda misstag ska inte få denna typ av konsekvenser, därav bör det finnas mer skydd exempelvis kryptering på filnivå. I detta fall kan hårddisken varit krypterad men det spelar ingen roll när webbservern visar katalogerna och gör filerna tillgängliga för nedladdning.

Har någon laddat hem filerna och lyssnat? Givetvis. Minst två personer, den som tipsade Computer Sweden samt journalisten. Även finns det stor chans att filerna cachats på diverse ställen ute på Internet. Dock kan loggfiler finnas kvar och gör det möjligt att spåra nedladdningar.

Sådana här läckor är givetvis otroligt allvarliga och kan leda till fara för liv och lem.

Tyvärr är nog detta enbart toppen av ett isberg när det gäller cybersäkerhet inom vårdsektorn.

Källor:

Uppdatering: Vi vet nu lite mer och servern verkar ha varit online sedan 2016 då någon ”stoppade in internetkabeln”.