Taggat med: CloudFlare

Tips för att höja cybersäkerheten

Tips för att höja cybersäkerheten

Med anledning av senaste tidens händelser och en ökad hotbild på cyberarenan så tänkte jag passa på att skriva ner några bra tips och råd på hur Er organisation kan höja cybersäkerheten.

Cyberresiliens och överbelastningsattacker

Er hemsida kan utsättas för överbelastningsattacker eller DDoS som det också brukar kallas. Antagonisten kommer att försöka identifiera kritiska punkter och skicka anrop om och om igen till dessa. Därför är det viktigt att se över hela den exponering som återfinnes mot Internet. Glöm inte API:er, subdomäner, DNS, SMTP osv.

Se till att ha en nödsajt samt alternativa vägar för att kommunicera inom Er organisation. Om internetförbindelsen går ner till Er organisation eller om tjänster såsom Slack går ner på grund av ökad belastning, hur kan ni då kommunicera? Om ni använder tjänster såsom Cloudfront, Akamai eller Cloudflare, se då till att den bakomliggande infrastrukturen inte går att nås via utanför dessa tjänster.

Internetexponering

Att veta hur organisationen ser ut från internet är otroligt viktigt. För det är just på dessa exponerade punkter som antagonisten kommer att fokusera först på. Kontrollera därför Er domän eller IP-adresser mot följande tjänster:

360PassiveDNS, ARIN, Ahrefs, AlienVault, AnubisDB, BinaryEdge, BGPView, BufferOver, BuiltWith, C99, Chaos, CIRCL, Censys, CommonCrawl, DNSdumpster, DNSDB, DNSlytics, DNSRepo, Detectify, FOFA, FullHunt, GitHub, GitLab, Greynoise, HackerTarget, Hunter, IntelX, IPdata, IPinfo, Maltiverse, Mnemonic, N45HT, NetworksDB, ONYPHE, PassiveTotal, PentestTools, Quake, RADb, Robtex, SecurityTrails, ShadowServer, Shodan, SonarSearch, Spamhaus, Spyse, Sublist3rAPI, TeamCymru, ThreatBook, ThreatCrowd, ThreatMiner, Twitter, Umbrella, URLScan, VirusTotal, WhoisXMLAPI, ZETAlytics, ZoomEye.

Eller använd OAWSP amass som gör det automatiskt. Använd DNS Anycast och försök att fronta via CDN och WAF. Även om jag inte är ett stort fan av Web Application Firewalls så kan det vinna Er några timmar.

Autentisering

Denna punkt har också att göra med ovan punkt. Dvs identifiera alla exponerade delar mot internet där en användare kan autentisera sig. Här är det otroligt viktigt att använda flera lager av skydd, jag rekommenderar att använda VPN som omslutning för allt. Och se till att också använda tvåfaktorsautentisering med hårdvaru-tokens såsom Yubikeys och certifikat.

Så kortfattat: Exponera inget mot internet som går att köra över VPN. Se till att den som ansluter via VPN inte kommer åt mer än nödvändigt, tänk zero-trust arkitektur.

Patchning och uppdatering

Om möjligt, se till att systemen uppdaterar sig själva automatiskt med nya säkerhetspatchar. Men var också medveten om att det finns möjlighet för bakdörrar att sig sig in den vägen. Dvs gör ett noga övervägande om för respektive nackdelar med automatiskt säkerhetspatchning. För majoriteten så är detta rätt väg att gå men inte något för alla.

Patcha inte bara mjukvaror, glöm inte heller switchar, skrivare, firmware och annat som också måste uppdatera. Och håll koll på om produkter eller system börjar närma sig End-of-Life och vad ni har för möjligheter då.

Har ni system som är äldre och som inte går att uppdatera men som ni ändå är beroende av, se till att isolera dessa extra noga. Exempelvis ett eget segment i nätverket där allt är filtrerat in och ut samt en speciell jump-host måste användas för att komma åt detta gamla system.

Härda systemen och se till att enbart mjukvaror som används exponeras eller är påslagna.

Övervaka, öva och testa

Testa säkerheten kontinuerligt med automatiska testverktyg såsom Holm Security, Detectify eller Nessus. Anlita konsulter som gör återkommande manuella penetrationstester samt genomför kodgranskning löpande om ni utvecklar mjukvara.

Öva på att återställa backup och se till att backuperna lagras offline eller på annat sätt icke åtkomliga från den ordinarie IT-infrastrukturen.

En komprometterad klient kan snabbt leda till att hela Er Windows AD-miljö blir övertagen. Se därför till att ni snabbt kan detektera om en klient börjar att bete sig suspekt. Har ni inte förmågan själva så se till att anlita ett företag som är experter på SIEM/SOC. Och vad gör ni när ni upptäcker något suspekt eller blivit utsatta för intrång, då är det bra att redan ha upparbetade kontaktvägar eller plan hur delar ska isoleras för att begränsa skada.

Glöm inte att allt ni ansluter kan producera loggfiler och hjälpa till att upptäcka intrång, syslog har funnits med länge och går att slå på och använda på nästan allt som kopplas upp.

Sammanfattning

Sist men inte minst, det ni inte känner till kan ni inte heller skydda. Se därför till att inventera och ha en god koll på vilken utrustning ni har, såväl mobiltelefoner, servrar, laptops och annat.

Administrativa konton bör användas ytterst begränsas och om möjligt med dubbelhandsfattning, tidsbegränsat eller liknande. Inventera dessa konton kontinuerligt.

Se också över beroendet gällande leverantörer, underleverantörer och tredjepartsberoenden. Upprätta en SBOM eller liknande. Jobba långsiktigt och systematiskt med cybersäkerheten och genomför omvärldsbevakning löpande, jag själv använder Twitter som en källa.

FRA FMV Försvarsmakten Säkerhetspolisen Polisen Post och Telestyrelsen MSB

Relevanta myndighetsdokument att läsa vidare:

Krypterad SNI i TLS 1.3

Server Name Indication (SNI) är den del av TLS som berättar för servern till vilken webbserver du vill besöka. Detta behövs om din webbserver bara har en IP-adress men flertalet certifikat. Detta fält går i klartext och gör att någon som kan se din nätverkstrafik också kan se vilken webbserver du besöker.

För att göra det svårare har bl.a. Domain Fronting används av såväl Tor som skadlig kod för att försvåra analys av nätverkstrafik men detta är något som flertalet leverantörer såsom CloudFlare nu stängt ner.

Följande bild förevisar bra där server_name skickas i klartext under handskakningsprocessen:

Firefox släppte precis stöd för ESNI (encrypted SNI) i sin nightly build. Du kan testa att ESNI fungerar genom att surfa till följande URL. Och glöm inte att slå på DoH:

Att ta fram en lösning som krypterar SNI var inte helt trivialt eftersom det rör sig om ett ”hönan eller ägget”-problem. Men för att lösa detta problem så används en ny nyckel hos klienten samt en ESNIKeys-structure som placeras i DNS:

Givetvis bör krypterad DNS också användas:

Moreover, as noted in the introduction, SNI encryption is
less useful without encryption of DNS queries in transit via DoH or DPRIVE mechanisms.

För mer matnyttig läsning rekommenderas följande IETF-draft:

 

OWASP Topp 10 snart ute i en ny 2017 års utgåva

Nyligen så släpptes förutgåva nummer 1 av den nya OWASP Top 10 listan. Den fristående och oberoende organisationen OWASP vill nu ha in åsikter om denna nya version. OWASP Top 10-listan skulle jag säga är så nära en standard man kan komma, den refereras i mängder olika dokument såsom PCI DSS och diverse upphandlingar.

Senaste ändringen i OWASP Top 10 var år 2013 och det har hänt en del på webbsäkerhetsfronten, så därför är det lägligt att det kommer en ny version inom kort.

Det nya versionen innehåller två nya kategorier som är följande:

  • A7 Insufficient Attack Protection
  • A10 Underprotected APIs

Och de tidigare kategorierna A7 och A4 har lagts in i A4. Tidigare kategorin A10 har tagits bort helt:

Jag tycker att A7 är mycket intressant och sätter fingret på en viktig punkt. För det är så att vi är relativt bra på att validera indata nuförtiden, bl.a. för att det är standard i många webbramverk. Men vi är desto sämre på att patcha, separera våra system och logga. Loggning är exempelvis otroligt viktigt vid incidenthantering och för att försöka lista ut hur ett intrång gick till.

Att använda en WAF (Web Application Firewall) känns också något som är en självklarhet år 2017. För detta finns exempelvis inbyggt i CloudFlare samt ingår i system från många brandväggsleverantörer. Men detta kan även ge en falsk säkerhet eftersom många WAF:ar går att kringgå.

Även den nya kategorin gällande oskyddade API:er är intressant, för detta är något som jag ser när jag exempelvis genomför reverse-engineering och penetrationstestar API:er. Många tror att bara för att ett API används så kan ingen ta reda på hur det fungerar och även ibland bygger in behörighetskontroll etc helt i klienten.

Här kan du läsa mer om tankarna bakom denna nya 2017 års version av OWASP Top 10:

OWASP Top 10 2017

CloudBleed – Allvarligt minnesläckage från CloudFlare

CloudFlare (CF) är numera en vital och central del av internet. CF tillhandahåller CDN (Content Delivery Network), DNS och WAF (Web Application Firewall) för att nämna några funktioner.

För några dagar sedan så kontaktade Tavis Ormandy CF gällande att han sett saker i Googles sökresultat som inte hör hemma där. När sedan CF undersökte så hittade man en parser-bugg som gör att minne från deras servrar kunde skickas ut felaktigt.

Ungefär 0.00003% av samtliga http-förfrågningar som gick genom CF drabbades av denna bugg. Och vid undersökningar i Googles cache så identifierades 700 fall där minne läckt och cachats av Google.

Turligt nog så påverkas inte privata (TLS) SSL-nycklar eftersom viss uppdelning finns mellan processerna i CF:s servrar.

För en mer komplett lista över sajter som ligger hos CF se här:

Uppdatering 1: Nu har CF skickat ut ett mail till samtliga kunder. De skriver bl.a. följande:

”To date, we have yet to find any instance of the bug being exploited, but we recommend if you are concerned that you invalidate and reissue any persistent secrets, such as long lived session identifiers, tokens or keys. Due to the nature of the bug, customer SSL keys were not exposed and do not need to be rotated.”

Uppdatering 2: Svenska betaltjänst-leverantören Mondido samt Kraken har återställt samtliga lösenord. Jag hoppas att fler följer efter som använder CF.

Uppdatering 3: Cloudbleed kan även ha och göra med att Google själva nollställt samtliga inloggningar mot Googles egna tjänster. Så här kommenterar Tavis:

”Hi Tavis, could you tell us why a lot of people had to re-authenticate their Google accounts on their devices all of the sudden? It may not have been related, but Google definitely did something that had us all re-authenticate.”

”I couldn’t tell you, this is not the correct place to ask.”

Uppdatering 4: Har nu laddat hem .se-zonen och kontrollerat hur många som använder CF:s namnservrar vilket ger en fingervisning om hur många .se-domäner som kan potentiellt läckt information:

$ grep cloudflare se.zone |awk ’{print $1}’|sort|uniq|wc -l
7827

Det kan även vara åt andra hållet. Dvs CF:s dyrare abonnemang så kan du köra med en egen namnserver men ändå nyttja CF:s tjänster.

Sajter som är sårbara för LuckyNegative20 CVE-2016-2107

LuckyNegative20

En av de sårbarheter vi skrev om i förrgår går under CVE-2016-2107 eller LuckyNegative20. Filippo Varsoda är en av de som genomfört en analys av buggen samt lagt upp en sajt för att testa om man är sårbar. Buggen återfinnes i en tidigare fix i biblioteket OpenSSL.

Så här skriver Filippo om buggen på CloudFlares blogg:

a skilled MitM attacker can recover at least 16 bytes of anything it can get the client to send repeatedly just before attacker-controlled data (like HTTP Cookies, using JavaScript cross-origin requests).

A more skilled attacker than me might also be able to decrypt more than 16 bytes, but no one has shown that it’s possible yet.

Vi har genomfört en skanning på några svenska sajter, och många är sårbara. Men som ovan skriver så kräver det att du kan sitta i mitten för att utnyttja attacken.

Listan med sajter

  • aftonbladet.se
  • bankomat.se
  • bth.se
  • cert.se
  • coresec.se
  • detectify.com
  • di.se
  • dn.se
  • expressen.se
  • forsakringskassan.se
  • fxm.se
  • halon.se
  • hd.se
  • kau.se
  • liu.se
  • mdh.se
  • metro.se
  • migrationsverket.se
  • nwt.se
  • oru.se
  • ownit.se
  • privataaffarer.se
  • romab.com
  • sectra.com
  • sentor.se
  • specialfastigheter.se
  • spp.se
  • svtplay.se
  • svt.se
  • tre.se
  • volvofinans.se
  • www3.skatteverket.se (används av Skatteverkets App)

Listan ovan baseras på denna.

DDoS-attack mot mediasajter

Igår Lördag strax innan kl 20 på kvällen så genomförde någon en DDoS-attack mot flertalet stora svenska mediasajter. Sajter såsom Aftonbladet gick inte att nå på över en timme, och det är ännu oklart exakt vilka sajter som stod som mål.

Attacken var tydlig på de grafer som är publikt tillgängliga från Netnod. Och det vi ser nedan är datatrafik som kommer från ryska internetoperatörer:

Netnod DDoS
Sammanställning av @SandraForesti

Att hyra någon att utföra DDoS-attack är inte speciellt dyrt och det som händer är att operatören troligtvis börjat att filtrera trafiken. Tittar vi via Telias looking-glass i Moskva så går det inte att nå Aftonbladet just nu via Telia i Ryssland.

Priserna för att hyra en DDoS-attack på svarta marknaden varierar en hel del men här är några exempelpriser:

booter-prices

 

Bakom attacker står troligtvis servrar med bra kapacitet som blivit hackade via WordPress, standardlösenord eller forcerade lösenord. Attacker tidigare mot bl.a. Regeringen använde JS LOIC men inte troligt i detta fall.

Med hjälp av trafikinspelning i PCAP-format exempelvis så skulle det gå relativt snabbt att ta reda på hur attacken utfördes. Även kan det vara möjligt att skapa motverkansmedel mot attacken om man vet i detalj hur den fungerar.

Reklam: Anlita Triop AB för att analysera DDoS-attacker

Sist men inte minst så är det också viktigt att skriva något hur mediasajters webb är uppbyggd. För att stå emot en attack som denna så bör DNS anycast samt web-anycast användas, och det finns flera leverantörer såsom Akamai, CloudFlare och Amazon CloudFront som kan leverera detta.

Även kan följande skrift vara bra att läsa med jämna mellanrum:

MSB Att hantera överbelastningsattacker
MSB Att hantera överbelastningsattacker