Flertalet säkerhetsuppdateringar från Cisco

Cisco släppte precis en stor mängd säkerhetsuppdateringar till en mängd olika produkter såsom Cisco Email Security Appliance, Cisco Identity Services Engine och Cisco IP Interoperability and Collaboration System.

us-certÄven så har amerikanska US CERT gått ut och varnat för att flertalet av dessa säkerhetsfixar åtgärdar problem som kan utnyttjas av en antagonist över nätverk (såsom Internet).

Följande säkerhetsuppdateringar rör det sig om:

Myndighetssajter låg nere efter överbelastningsattack

DDoS DNS

Igår låg flertalet myndighetssajter nere såsom Krisinformation.se, Regeringen.se och MSB.se, men även flertalet internationella tjänster såsom Github, Spotify och Twitter. Anledningen till att de låg nere var en överbelastningsattack mot dess DNS-leverantör Dyn.

Ända sedan 2012 är det känt att flertalet svenska myndigheter har lagt alla ägg i samma korg och valt leverantören Dyn för DNS (eller indirekt via företaget Excedo). Dyn är ett amerikanskt företag som inte har några DNS-servrar i Sverige samt har alla DNS-servrar ett och samma AS (Autonomous System).

Stephan Lagerholm på Secure64 och Torbjörn Eklöv, Interlan skrev redan 2012 ett brev och ifrågasatte valet av leverantör för DNS.

Och som Cornucopia påpekade 2013 så ligger ansvaret för psykologiskt skydd hos MSB. Och om en utländsk leverantör handhar DNS:erna så har dessa även möjlighet att modifiera innehållet på myndigheternas webbsidor genom att helt enkelt peka om.

Brev till regeringen, Kustbevakningen och MSB finns här:

Som tur var så verkar MSB eller dess leverantör Excedo ändrat tjänsteleverantör för DNS till svenska Netnod och Dnsnode.

Men vem eller vad stog bakom den stora överbetlastningsattacken? Troligtvis så användes Mirai-bottnätet som utnyttjar svagheter i Internet of Things-enheter såsom övervakningskameror. Dessa svagheter som utnyttjas är bl.a. användarnamn och lösenord som är lätta att gissa eller hårdkodade, dock så väntar vi fortfarande på en djupara analys från Dyn.

Och att Myndigheten för samhällsskydd och beredskap, Regeringen etc var nere beror så klart på collateral damage (sidoskada) då målet troligtvis var något helt annat.

IIS dnscheck är ett bra verktyg för att se några av de vanligt förekommande felen. Här är för MSB.se:

Uppdatering: En observant läsare påpekade att med anledning av flytten för MSB.se så försvann DNSSEC. Även så använder man sig fortfarande enbart av en leverantör.

Uppdatering 2: En annan intressant kedjereaktion på DDoS mot DNS är att DKIM och SPF misslyckas att verifieras vilket får till följd att mängder av E-post hamnar i spam-korgar.

Uppdatering 3: Nu har även DN skrivit om att flertalet experter påpekade detta problem redan 2012.

Ny allvarlig sårbarhet i Linux: DirtyCow

dirtycow

En allvarlig sårbarhet har uppdagats i Linux-kerneln. Sårbarheten har fått namnet DirtyCow eftersom sårbarheten återfinnes i Linux-kernelns  hantering av copy-on-write (COW). Sårbarheten har fått CVE-2016-5195 och redan nu har det rapporterats att säkerhetsbuggen utnyttjas av aktörer. Observera att detta enbart är en lokal såbarhet.

Ko-buggen introducerades i kernel-version 2.6.22 (som släpptes 2007) och åtgärdades 18:de oktober 2016. Även så har Linus Torvalds försökt att åtgärda buggen tidigare men misslyckats och de flesta Linux-distarna har nu uppdateringar.

På Github går det att ladda hem en PoC (proof-of-concept) exploit-kod som utnyttjar denna sårbarhet: https://github.com/dirtycow/dirtycow.github.io/blob/master/dirtyc0w.c oklart vem som skapat PoC:en men säkerhetsbristen identifierades av Phil Oester.

Denna sårbarhet fungerar enbart på Linux-distar som gör /proc/self/mem skrivbar för användaren. RedHat Enterprise Linux 5 och 6 gör inte det och är således inte sårbar. Buggen beror på ett race-condition som kan triggas och få kerneln att felaktigt skriva till en fil och möjliggör för en angripare att exempelvis skriva till en suid-binär.

Uppdatering: Med hjälp av ptrace så går det att bygga en exploit och då behöver inte /proc/self/mem vara skrivbar.

Givetvis kan du även köpa en fin mugg med DirtyCow-loggan på för 13400 SEK:

dirtycow-mugg

Demo på ytterligare en poc:

blasty

IT-säkerhetsgranskning av VeraCrypt

veracrypt granskning

Det franska cybersäkerhetsföretaget QuarksLab har utfört en publik it-säkerhetsgranskning av VeraCrypt. VeraCrypt är en populär uppföljare till det numera nedlagda projektet TrueCrypt. Granskningen har bekostats av organisationen OSTIF och backas upp finansiellt av bl.a. DuckDuckGo och VikingVPN.

Granskningen fokuserar på sådant som inte granskas av tidigare projekt såsom den som NCC Group utförde av TrueCrypt (jag skrev om det här). Och sådant nytt som granskningen inkluderar är:

  • DCS EFI Bootloader 1.18 (UEFI)
  • Camellia, Kuznyechik, GOST 28147-89, Streebog
  • Stöd för att expandera volymer
  • Stöd för Unicode på Windows
  • StrSafe istället för string.h
  • Musrörelser för att öka på entropi

Sådant som ej granskats är följande: Mac OS X/Sierra stödet, Linux-stöd samt diagonstik-verktyget.

För oss som jobbar med IT-säkerhetsgranskningar är det alltid intressant att läsa denna typ av rapport och det finns alltid något att lära av. Granskningen uppdagade följande sårbarheter:

  • 8 kritiska sårbarheter
  • 3 medium-klassade sårbarheter
  • 15 lågt klassade eller info-läckage

Sådant som uppdagats av granskningen är åtgärdat i version 1.19 av VeraCrypt. Och några av åtgärderna som genomfördes av VeraCrypto-projektet är följande:

  • Stöd för att skapa nya volymer med GOST 28147-89 är borttaget.
  • Biblioteken för  XZip och XUnzip var ej uppdaterade och är nu borttagna och har ändrats till libzip.
  • Åtgärd för att en angripare kan avgöra lösenordets längd i bootloader. Även åtgärder för att försöka säkerställa att lösenord raderats från UEFI har genomförts.
  • Fix för att förhindra minnesöverskrivning när återställningsdisk läses in.

Här nedan kan du ladda hem den 44-sidiga granskningsrapporten i sin helhet i PDF-format. Granskningen tog 32 arbetsdagar för två personer:

veracrypt-granskning

Facebook Messenger blir krypterat

Facebook börjar nu sakta men säkert att rulla ut kryptering direkt mellan användare, så kallad end-to-end kryptering. Tidigare har enbart meddelanden mellan användaren och Facebooks servrar varit krypterade (med MQTT + över TLS?).

Enligt en källa till Wired så baseras den nya krypteringstekniken på Signal-protokollet som är utvecklat av Moxie Marlinspike och Open Whisper Systems.

Tyvärr så måste användaren själv göra ett aktivt val för varje konversation att End-to-end kryptering ska användas.

Men självklart ett steg i rätt riktning för Facebook Messengers alla 900 miljoner användare. Även så släppte Google sin nya app Allo som fungerar på liknande sätt där Google mixar end-to-end kryptering i en och samma app vilket kan göra det svårt för användare att urskilja om kryptering verkligen används.

Att Facebook väljer att göra det till ett val för användaren att slå på kryptering beror troligtvis på att företaget inte vill ha problem med amerikanska myndigheter.

Nätaktivisten och säkerhetsforskaren Christopher Soghoian skriver på Twitter:

Ny GPU-instans från Amazons molntjänst EC2

amazon-web-servicesAmazon har en molnjänst vid namn EC2 där du kan hyra datorkapacitet per timme. De har nu lanserat en ny GPU-instans som gör att du kan knäcka lösenord ännu snabbare, något som vi som jobbar med IT-säkerhet gillar.

Den nya instansen heter p2.16xlarge och har 16 st GPU-kärnor och körs med ett Nvidia Tesla K80-grafikkort. Det går så klart inte att jämföra med exempelvis Nvidia Titan X men du slipper springa iväg till affären och köpa ett grafikkort eller en häftig Sagitta Brutalis. Kostnaden för en instans av p2.16xlarge ligger på$14.4 vilket är ca 123 SEK/h.

Här kommer några färska prestandasiffror som jag just hämtade in från en instans som jag startade upp och konfigurerade på under 10 minuter:

$ ./hashcat64.bin -b
hashcat (v3.10) starting in benchmark-mode...

OpenCL Platform #1: NVIDIA Corporation
======================================
- Device #1: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #2: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #3: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #4: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #5: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #6: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #7: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #8: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #9: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #10: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #11: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #12: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #13: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #14: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #15: Tesla K80, 2859/11439 MB allocatable, 13MCU
- Device #16: Tesla K80, 2859/11439 MB allocatable, 13MCU

Hashtype: MD5

Speed.Dev.#1: 4232.2 MH/s (93.96ms)
Speed.Dev.#2: 4228.3 MH/s (94.21ms)
Speed.Dev.#3: 4179.4 MH/s (95.75ms)
Speed.Dev.#4: 4246.1 MH/s (96.86ms)
Speed.Dev.#5: 4488.8 MH/s (92.94ms)
Speed.Dev.#6: 4460.2 MH/s (91.24ms)
Speed.Dev.#7: 4314.4 MH/s (94.73ms)
Speed.Dev.#8: 4569.5 MH/s (88.65ms)
Speed.Dev.#9: 4465.4 MH/s (90.92ms)
Speed.Dev.#10: 4147.8 MH/s (95.67ms)
Speed.Dev.#11: 4426.8 MH/s (93.48ms)
Speed.Dev.#12: 4078.0 MH/s (98.75ms)
Speed.Dev.#13: 4339.8 MH/s (94.58ms)
Speed.Dev.#14: 4459.1 MH/s (91.09ms)
Speed.Dev.#15: 4263.1 MH/s (94.88ms)
Speed.Dev.#16: 4221.2 MH/s (93.16ms)
Speed.Dev.#*.: 69120.1 MH/s

Och med den GPU-instansen hos Amazon som var snabbast tidigare så såg det ut så här när det gäller MD5:

Hashtype: MD5

Speed.Dev.#1.: 1714.1 MH/s (95.69ms)
Speed.Dev.#2.: 1705.1 MH/s (96.22ms)
Speed.Dev.#3.: 1714.5 MH/s (95.36ms)
Speed.Dev.#4.: 1726.3 MH/s (95.01ms)
Speed.Dev.#*.: 6860.0 MH/s

Så en klart förbättring.

Så lagrar Dropbox ditt lösenord

Att Dropbox blev hackade och samtliga lösenord hamnade på vift 2012 är något som är välkänt. Av analys visade det sig att hälften av lösenorden var SHA1-hashade och andra hälften använde sig av bcrypt-hash. Detta troligtvis pga en pågående övergång från SHA1 till bcrypt.

Det har hänt en hel del sedan 2012 och Dropbox avslöjade nyligen hur de lagrar sina lösenord på ett säkert sätt.

Först och främst använder Dropbox precis som Facebook (se nedan) flertalet lager, som en lök. Att använda SHA512 före bcrypt är främst av två anledningar: överbelastningsattack om långa lösenord används samt att vissa implementationer av bcrypt kortar ner lösenordet till 72 bytes.

bcrypt används med en cost på 10 (arbetsfaktor/work factor) samt en unik salt för varje användare. Detta steg tar ungefär 100ms på Dropbox servrar.

Sista steget är AES256 med en global nyckel som är samma för alla hashar. Detta är för att om hela databasen blir snodd eller servern där lösenorden lagras så finns det ett extra skydd med en nyckel som är svår att hitta.

Dropbox lösenord

Även Facebook använder flertalet lager för sina lösenord (läs mer här):

Facebook lösenord

Dropbox har sedan tidigare utvecklat zxcvbn som ser till att användarna väljer bra lösenord först och främst. Även så kan vi anta att Dropbox kontinuerligt bevakar läckage av lösenord på nätet och informerar användare om just deras lösenord finns med eller går att knäcka.

Givetvis kan man alltid argumentera att det nu finns säkrare alternativ till bcrypt såsom argon2 och scrypt. Men bcrypt har bra stöd i många programbibliotek och har funnits ända sedan 1999. Dock uppger Dropbox att de har mer erfarenhet av bcrypt men kommer troligtvis att uppgradera till argon2.

Även uppger Dropbox att de kommer i framtiden att överväga att använda en HSM (kanske CrypTech?) för att lagra den globala nyckeln. Denna nyckel roteras också regelbundet uppger de på sin blogg.

MQTT-tjänster står oskyddade på internet

CERT-SE som är en del av Myndigheten för samhällsskydd och beredskap (MSB) går ut och varnar för att flertalet MQTT-tjänster står oskyddade direkt mot internet i Sverige.

Efter att Lucas Lundgren på IT-säkerhetskonferenser såsom Defcon och SEC-T berättat om MQTT-protokollet samt sökt av hela internet efter sårbara tjänster med masscan så var resultatet häpnadsväckande. Tusentals servrar stod helt vidöppna för vem som helst att ansluta till dessa och läsa av all information som flödade via dem (subscribe).

MQTT används som en realtids-förmedlare och är ett mycket lättviktigt protokoll vilket gör det lämpligt att användas för små enheter inom IoT (Internet of Things) exempelvis.

Många tjänster använder också MQTT för att publicera data på webbsidor helt ofiltrerat vilket öppnar upp för olika typer av injektionsattacker såsom XSS (cross site scripting).

Det finns en säkrare version av MQTT som använder TLS och går under benämningen secure-mqtt och använder TCP port 8883. Givetvis ger dmqttetta också en extra overhead och ökar antalet paket och paketstorleken.

Lucas har försett CERT-SE med datat från sina skanningar. Och myndigheten kan då konstatera att ingen av de oskyddade svenska servrarna tillhör CERT-SE:s prioriterade aktörer (myndigheter, kommuner och vissa företag).

Förutom MQTT så finns det andra protokoll som bör kontrolleras och som CERT-SE lyfter upp som möjliga orsaker till problem: OPC UA, HTTP (REST/JSON), CoAP, DDS och AMQP.

Här kan du ladda hem Lucas presentation som PDF:

mqtt defcon

 

SCADA/ICS-säkerhetskonferens 4SICS

Om några veckor är det dags för årets upplaga av den internationella konferensen om IT-säkerhet i cyberfysiska system (SCADA). Konferensen går under namnet 4SICS (four-six dvs landskoden till Sverige) och hålls på Nalen mitt i Stockholm.

Erik Johansson som tillsammans med Robert Malmgren står bakom konferensen berättar att  ämnen som kommer att behandlas på konferensen i år är cyberattackerna mot Ukraina i slutet av december 2015. Då drabbades flera elbolag i Ukraina av samordnade IT-attacker som slog ut elförsörjningen för mer än en kvarts miljon abonnenter. De Ukrainska elbolagen utsattes för en så kallad APT (Advanced Persistent Threat) då en grupp sofistikerade angripare under lång tid planerade, beredde sig tillgång till, och från insidan studerade elbolagens IT-miljöer. I över ett halvårs tid planterades skadlig kod, öppnades nya bakvägar och stals information i olika förberedelsesteg inför det att man den 23:e december mörklade delar av Ukraina.

Robert M. Lee, expert på säkerhet i SCADA-system och en av de som bistod Ukrainska myndigheter med utredningen, är en av de internationella specialister som bjudits in som talare på konferensen.

Lee berättar:

IT-attacken på det ukrainska kraftnätet var den första i sitt slag. Många detaljer kring attacken har kommit till allmän kännedom, men på 4SICS kommer de som deltog i analysen av attacken att samlas och belysa detaljer och erfarenheter på ett sätt som inte gjorts tidigare.

Andra inbjudna specialister är Anton Cherepanov & Robert Lipovsky från antivirusföretaget ESET som kommer att göra en djupare genomgång av vad man egentligen vet om den skadliga koden vid namn BlackEnergy som bland annat användes mot elbolagen i Ukraina.

Erik berättar även att presentationerna kommer att avslutas med rundabordssamtal där tekniska specialister och myndighetsföreträdare kommer diskutera tekniska brister, tillvägagångssätt, konsekvenser samt IT som vapen i olika konflikter. Innan konferensen finns det även möjlighet att gå flertalet kurser inom säkerhet i cyberfysiska system.

Ett axplock av övriga talare är: Jens Zerbst, CIO på Vattenfall, som kommer beskriva hur man uppnår försvar på djupet i en tid när det finns APT. Maik Brüggemann, säkerhetsforskaren som påvisat hur skadlig kod kan sprida sig direkt mellan olika PLC:er.

Margrete Raaum, CEO vid norska KraftCERT, med egna erfarenheter från härom året då Norge utsattes för cyberattacker och vet hur man bör hantera incidenter.

Konferensen och kurserna går under datumet 25-27 Oktober 2016, läs mer här: https://4sics.se

500 miljoner Yahoo-konton stulna

Yahoo meddelade precis att företaget har blivit av med uppgifter om 500 miljoner konton. Bland dessa uppgifter återfinnes bl.a. bcrypt-hashade lösenord (till största delen) samt telefonnummer och födelsedata. Och även i vissa fall krypterade och icke krypterade frågor och svar för lösenordsåterställning.

Det som kanske är mest spektakulärt är att intrånget skedde i slutet av 2014 och att Yahoo hävdar att det är statsunderstött.

Yahoo meddelar även att de just nu håller på att informera samtliga som är drabbade av detta omfattande läckage men många frågor är fortfarande obesvarade såsom:

  • Har Yahoo känt till detta intrång sedan 2014 eller upptäcktes det först nu?
  • Hur kan de hävda att en statsunderstödd angripare ligger bakom?

Och hur säkert är bcrypt som användes på majoriteten av lösenorden? Det beror helt på vilka inställningar Yahoo använde för sin ”work factor”, om de använde 12 som inställning så tar det runt 0,5 sek att testa ett lösenord. Men troligtvis använde Yahoo 10 som work-factor som var standard för några år sedan och då kan angriparen testa att forcera minst 10 lösenord i sekunden. Vilket förvisso är otroligt bra jämfört med exempelvis osaltad MD5.

Läs mer hos Yahoo här.