TLS/SSL-läget i Sverige

Företaget Kirei har nu lanserat en webbtjänst där de listar 788 svenska organisationer och deras tillhörande betyg från SSL Labs. Bakomliggande kod är öppen källkod och ligger på Github för den som vill komma med ändringar.

Generellt kan man se att det inte ser speciellt bra ut. Antalet organisationer som får sämsta betyg F är otroligt många och även antalet sajter som överhuvudtaget inte har TLS är ännu fler.

För den som vill erhålla högsta betyg, A+ så går det bl.a. att följa SSL Labs A+. Givetvis så saknar vi regeringen.se som tillhandahåller ett felaktigt certifikat via Akamai och som annars brukar vara bra att föregå med gott exempel:

Regeringen TLS Akamai

Skärmdump från TLS-kollen:

TLS/SSL i SverigeUppdatering: Emil Tullstedt tipsade mig på Twitter att en ny RFC har släppts som går ut på att fasa ut SSLv3: https://www.rfc-editor.org/rfc/rfc7568.txt

 

Så skapar du en digital sprängkista

digital sprängkista

Inom det militära har sprängkistor eller sprängtunnlar används för att i händelse av att främmande makt får övertag så ska det vara möjligt att förstöra exempelvis egen hamn eller bro på ett snabbt och effektivt sätt. Detta så att ej främmande makt kan nyttja hamnen eller bron för sin egna stridskraft.

Cornucopia skriver:

Skatteverkets data över inkomster, bankernas transaktionsdata, sjukvårdens journalsystem, partiernas medlemsdatabaser, tidningsredaktionernas e-post osv är alla utmärkta personregister för en ockupationsmakt att ta kontroll över. För att inte tala om svenskarnas e-postlådor. Eller Facebooks serverhallar.

Att använda sig av digitala sprängkistor eller kill-switch är något som nu är aktuellt inom cyberkrigsföring. För det är så att vi samlar på oss allt mer digital information som vi eventuellt snabbt behöver radera. Men hur raderar man stora mängder data på ett snabbt och effektivt sätt? Är det med hjälp av 8 gångers överskriving av hårddisken eller med elektromagnetisk puls (EMP)?

Förvisso så är båda alternativen ovan intressanta men bör användas tillsammans med en annan teknik. Nämligen att förstöra huvudnycklar till en krypterad hårddisk, och denna teknik finns och är implementerad i LUKS som ”nuke patch”. Det är precis på samma sätt som informationen raderas i din iPhone när du väljer att göra en fabriksåterställning.

För att aktivera panikläget och därmed radera krypteringsnycklarna så kan du använda dig av ett speciellt lösenord som du ställer in med:

# cryptsetup luksAddNuke /dev/sda5
Enter any existing passphrase:      (existing password)
Enter new passphrase for key slot:  (set the nuke password)

För säker radering titta även ATA Secure Erase samt kommandot luksErase. Vi skrev även 2012 om DBAN som kan användas för att radera data.

Svenska operatörer sparar i många fall trafikdata under flera år. Effekten blir att det är fritt fram för myndigheter – eller i värsta fall främmande makt – att botanisera bland känsliga uppgifter. Syftet med en ”kill switch”-rutin måste vara att i ett nödläge kunna genomföra ett slags digital sprängning som förstör data och skyddar medborgarna.

Skriver Jon Karlung. Läs även hela debattinlägget till SvD från Bahnhofs VD Jon Karlung om behovet av digitala sprängkistor här. Intressant också hur Bahnhof väljer att tekniskt implementera sina sprängkistor.

Uppdatering: Glöm inte heller att information eventuellt kan återskapas med hjälp av loggfiler eller backuper.

Omfattande läckage hos Telenor

Telenor_logoOperatören Telenor har utsatts för ett läckage av uppgifter gällande uppgifter innehållandes kundinformation såsom personnummer.

Post och Telestyrelsen (PTS) som är tillsynsmyndighet går ut med följande information:

Det handlar om ett kundregister hos operatören som olovligen kopierats. I kundregistret har det funnits information bland annat om personnummer och abonnemang.

Kundregistret har kopierats av en för detta anställd och har sedan använts för oetisk telefonmarknadsföring uppger Telenor.

Incidenten inträffade redan under 2012 och rapporterades till PTS för några veckor sedan. Polisen har även sedan tidigare inlett en förundersökning samt så har Telenor själva informerat PTS.

Telenor berättar även att de går ut och meddelar de kunder som berörs av incidenten.

Vidare så skriver även PTS:

PTS inleder nu en granskning av hur Telenor har hanterat incidenten och vilka åtgärder som bolaget vidtar för att detta inte ska hända igen.

Intressant är även myndighetens nya föreskrifter gällande krav på säkerhet som utkom 2014 som det står mer om här.

📱 Apple genomför säkerhetshöjande åtgärder

Apple säkerhet

Apple meddelande på det senaste WWDC-eventet att de nu avser att genomföra ett antal säkerhetshöjande åtgärder inom snar framtid eller i iOS 9 som nu är ute i beta-version.

Några av dessa åtgärder omfattar följande fyra:

1. HTTPS som standard i Appar – Appar nu måste specifikt be om tillstånd för att använda http. Detta är som ett led att få alla appar att köra krypterad kommunikation över https. Denna åtgärd gäller från och med iOS version 9.

2. Förbättrad PIN – Den som använder PIN-kod för att låsa sin iPhone etc måste nu använda minst 6 siffror i sin kod istället för 4 som var standard tidigare. Detta ökar sökrymden från 10000 till en miljon olika kombinationer för den som försöker forcera koden. Att använda siffror som PIN-kod kommer dock fortfarande inte att krävas.

Och för den som vill höja säkerheten mer bör stänga av funktionen ”enkelt lösenord” och istället använda ett lösenord bestående av både siffror och bokstäver. Läs även vad Anne-Marie Eklund-Löwinder skrev om hur man skapar ett bra lösenord här.

3. 2FA – Nytt gränssnitt för tvåfaktorsautentisering som kopplar inloggningen mot en fysisk plats för inloggningsgodkännande:

iCloud 2FA4. VPN API – Detta är en synnerligen intressant ny funktion. Med detta nya API för VPN-anslutningar så medges appar att skapa up VPN och krypterade proxyanslutningar vilket troligtvis öppnar upp för Tor och OpenVPN. Även så har OpenVPN fått förhandsåtkomst till detta API som nu öppnas upp för alla (se appen OpenVPN Connect).

Även så har Cisco AnyConnect använt detta odokumenterade API sedan många år.

 

🔧 Guide: Så gör du SSH säkrare

OpenSSHAtt SSH är en otroligt använd tjänst råder ingen tvekan om. Nästan alla som har någon form av server använder sig av SSH.

Denna guide börjar med klientsäkerhet för att sedan ge rekommendationer för server-sidans konfiguration. Vi kommer främst att fokusera på de algoritmer som används.

SSH klientsäkerhet

Först och främst ska du se till att du har en relativt ny SSH-klient som du ansluter med. Den som följer med Mac OS X är gammal och stödjer bara gamla krypton, så därför är det lämpligt att uppgradera till en nyare version med hjälp av brew.

Denna följer med Mac OS X Yosemite:

$ ssh -V
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011

Och för att installera en nyare version:

$ brew install openssh --with-brewed-openssl --with-keychain-support

Sedan så kontrollerar vi versionen igen:

$ ssh -V
OpenSSH_6.8p1, OpenSSL 1.0.2a 19 Mar 2015

Nu ser det betydligt bättre ut. Nästa steg är att generera nya Ed25519 nycklar som vi kan använda:

$ ssh-keygen -t ed25519 -C "min@epost" -a 100 -o

Om du i ovan steg får ett felmeddelande om att algoritmen inte stöds så har du fel sökväg till ssh-keygen binären. Testa då /usr/local/bin/ssh-keygen istället.

Glöm framförallt inte att använda ett lösenord för att skydda din privata nyckel.

Vi ska även ändra i vår klient-konfigurationsfil så vi enbart stödjer SSH version 2 samt ett antal algoritmer som vi litar mer på:

Host *
    PubkeyAuthentication yes
    Protocol 2
    HostKeyAlgorithms [email protected],[email protected],[email protected],ssh-ed25519,ssh-rsa
    Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
    MACs [email protected],[email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,[email protected]

Du hittar SSH-konfigurationsfilen i din hemkatalog och sedan .ssh/config

SSH serversäkerhet

Först och främst måste du se till att ha en relativt ny version av OpenSSH. Du bör ha minst version 6.5 som släpptes i  Januari, 2014.

Lägg in följande i /etc/ssh/sshd_config på rätt ställe:

MACs [email protected],[email protected],[email protected],[email protected],hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,[email protected]
Ciphers [email protected],[email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256

Samt se till att Protocol 2 enbart stöds. Samt kommentera bort stödet för HostKeys som ej är RSA eller ed25519:

HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

Du bör även se till att just ovan hostnycklar verkligen finns. Om någon ej skulle finnas så kan du skapa en ny med ssh-keygen:

$ ssh-keygen -t ed25519 -f ssh_host_ed25519_key

När det fungerar med inloggning via nycklar bör du ändra följande förutsatt att du inte använder någon funktion som de tillhandahåller:

ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no

Givetvis ska även root-logins stängas av med PermitRootLogin no. En annan bra sak är att ta bort kortare Diffie-Hellmanparameterar, följande kommando gör detta åt dig:

awk '$5 > 2000' /etc/ssh/moduli > "${HOME}/moduli"
wc -l "${HOME}/moduli" # se till att du har något kvar i filen
mv "${HOME}/moduli" /etc/ssh/moduli

Glöm inte att starta om openssh samt genomför tester så du inte stänger ute dig själv.

Givetvis finns det mängder med andra inställningar du kan göra för att höja säkerheten. Lämna gärna en kommentar med dina tips.

Uppdatering: För att försvåra brute-force attacker så bör du använda fail2ban eller sshguard. Tipstack till Jonas Thambert!

Tack till stribika

🔐 Microsoft gillar Forward Secrecy (PFS)

Microsoft

Nyligen så släppte Microsoft en relativt anonym säkerhetsuppdatering med nummer 3042058. Denna uppdatering kastar om ordningen samt lägger till nya krypteringsalgoritmer gällande Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, och Windows Server 2012 R2.

Att en så stor spelar som Microsoft gör denna ändring får så klart stora konsekvenser för IT-säkerheten i stort på internet, till det bättre om du frågar mig. För just Forward Secrecy (PFS) gör att temporära nycklar används för sessioner och således kan äldre information ej återskapas även om den privata nyckeln röjs som i fallet med Heartbleed-buggen. För TLS handlar det framförallt om Diffie-Hellman DHE och Diffie-Hellman med elliptiska kurvor, ECDHE.

Följande nya ciphersuites stödjer nu Microsofts ovan operativsystem (och framtida?):

  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256

Och i Microsofts fall så är de Schannel som har hand om SSL/TLS och ovan nya algoritmer. Du kan även manuellt ändra ordningen på följande sätt:

  1.  At a command prompt, type gpedit.msc, and then press Enter. The Local Group Policy Editor is displayed.
  2. Expand Computer Configuration, expand Administrative Templates, expand Network, and then click SSL Configuration Settings.
  3. Under SSL Configuration Settings, click SSL Cipher Suite Order.
  4. In the SSL Cipher Suite Order pane, scroll to the bottom.
  5. Follow the instructions that are labeled How to modify this setting.

Kommentar från Henrick Hellström på Streamsec:

– Uppdateringen är ”anonym” främst eftersom den inte kommer att bli tillgänglig via Windows Update förrän fjärde kvartalet. ”Microsoft is initially offering the 3042058 update via the Microsoft Download Center only in order to give customers the opportunity to test the new features before making them a default part of their environments; the update will be available via Microsoft Update and WSUS in Q4 2015.”

– Jag håller med om att PFS borde vara standard, men tycker att din motivering kanske är lite överförenklad. I praktiken skulle en läckt privat nyckel (genom heartbleed eller på annat sätt) nog inte skydda gammal data det minsta. Lyckas du komma in som administrator på en server (t ex genom en MITM följd av selektiv blockering mot Remote Desktop när administratören försöker logga in) kan du förmodligen ganska enkelt återskapa det mesta som hänt på den servern genom att analysera loggfiler och auditrecords i databasfilerna, utan att behöva dekryptera någon gammal SSL/TLS-trafik.

– Omvänt, det stora problemet om någon lyckas kopiera din privata nyckel, är att du högst sannolikt aldrig kommer att få reda på det. Även om all gammal trafik kommer att förbli konfidentiell, kommer all framtida trafik från den tidpunkten att kunna dekrypteras av angriparen.

Kodgranskning och säker utveckling

kodgranskning

Ett området som Triop AB bedriver verksamhet inom är säker utveckling och kodgranskning. Denna typ av granskningar är speciellt viktig inom system och produkter där hög assurans är av stor vikt.

Kodgranskningsuppdraget går ut på att identifiera sårbarheter och ge förslag på säkerhetshöjande åtgärder.

Ett urval av några kontrollpunkter vid en kodgranskning, manuellt samt automatiserat:

  • Används säkra funktioner framför osäkra
  • Hur hanteras användargenererad data från exempelvis nätverk
  • Blackboxtester där man hittar på hur slutprodukten används
  • Fuzztester
  • Minnesläckage
  • Exceptions eller returvärden som ej hanteras
  • Signed/unsigned-problem, off by-x, stränghantering
  • Kodens kvalitét i stort, såsom kommentarer och stil
  • Debugkod etc som ej ska förekomma i produktion
  • Tredjepartsbibliotek som inte är uppdaterade eller innehåller sårbarheter
  • Används säkra funktioner i systemet såsom chroot/setuid etc
  • Uppföljning mot CERT Secure Coding standards
  • Eventuella logiska fel/tankevurpor
  • Tidigare identifierade sårbarheter
  • Kompilatorflaggor
  • Unittester eller andra tester
  • Race conditions
  • Svaga  eller kryptografiska funktioner som används felaktigt
  • Loggning
  • Automatiska verktyg, se lista hos NIST
  • Överbelastningsattacker
  • Rena slarvfel

Givetvis är tillgång till källkod en mycket trevlig förutsättning men om det inte finns tillgänglig så kan många av ovan tester ändå genomföras med hjälp av reverse-engineering.

Att genomföra en kodgranskning är inget som genomförs på en eller två dagar utan tar vanligtvis åtskilliga veckor eller månader. Samt så bör även uppföljning genomföras efter exempelvis ett år eller några månader då eventuella förslag implementeras och sårbarheter åtgärdats.

En annan intressant fråga är hur mycket tid en kodgranskare ska lägga på att påvisa huruvida en sårbarhet går att exploitera av en antagonist. Jag rekommenderar så liten tid som möjligt och att alla uppdagade sårbarheter ska hanteras som kritiska och åtgärdas så snabbt som möjligt.

Kodkvalitén kan även bli högre bara av vetskapen av att kodgranskning genomförs och kvalité och säkerhet går oftast hand i hand.

17993_10155644842315206_673996664324591996_n

Facebook + PGP = ❤️

Facebook PGP

Facebook stödjer nu att du kan ladda upp din publika nyckel till din Facebook-profil. Då kommer Facebook att använda denna nyckel när de skickar ut meddelanden via E-post.

Och som ovan bild visar så förhindrar detta även om ditt E-postkonto skulle bli kapat (men du använder väl tvåfaktorsautentisering också?).

Behöver ditt företag hjälp med IT-säkerhet eller kryptering? Kontakta Triop AB >

Detta är så klart ett bra uppsving för hela PGP och web of trust och detta märks tydligt då flertalet nyckelservrar såsom pgp.mit.edu svarar långsamt idag eller är helt nere. En tydlig koppling mellan din Facebook-profil och nyckel stärker förtroendet, lite åt det håll som tjänsten Keybase är tänkt.

För att bekräfta att din publika PGP-nyckel så skickar Facebook även ut ett krypterat verifieringsmail med en länk som du måste klicka på för att funktionen ska aktiveras.

Om du vill ladda hem någons publika PGP-nyckel så kan du göra det enligt följande exempel på URL:

https://www.facebook.com/facebookalias/publickey/download

Facebook PGP

Här laddar du upp din publika nyckel:

https://www.facebook.com/me/about?section=contact-info

Facebook själva använder en nyckel med följande fingerprint:

31A7 0953 D8D5 90BA 1FAB 3776 2F38 98CE DEE9 58CF

och denna subkey fingerprint:

D8B1 153C 9BE9 C7FD B62F 7861 DBF4 E8A2 96FD E3D7

Och Facebook kommer att stödja RSA och ElGamal men undersöker huruvida de även kan stödja elliptiska kurvor (ECC). Obligatorisk XKCD:

XKCD PGP

Tips! Gillade du att läsa detta? Kolla även in: Facebook finns nu på Tor

Framtidssäkra krypteringen

Kryptoframtiden

Går det att sia in i framtiden om hur och vilka krypteringsalgoritmer som kommer att bestå?

Både Ja och Nej. Vi kan däremot titta i backspegeln och se vad vi har lärt oss av historien, vilka algoritmer som varit säkra och vilka som knäckts. För att jobba med krypton handlar om att alltid vara på tårna och följa vad som händer i omvärlden gällande nya rön, forskningsrapporter och best practices.

Det gäller att ha en plan för den dagen ett byte ska ske. Hur migrerar vi från SHA1 till SHA256? Kan vi byta hashfuktion på ett enkelt sätt eller blir vi kvar med MD5?

För de handlar inte enbart om att välja bra och trendiga algoritmer, det gäller även att bygga ett förtroende över tid.

Men skulle jag blicka framåt så är ChaCha20 + Poly1305 av Daniel J Bernstein (DJB), Peter Schwabe och Tanja Lange helt klart intressant som nu fått RFC-nummer 7539.

Så klart är elliptiska kurvor (ECC) intressant men titta innan framförallt på arbetet som DJB genomfört i samband med SafeCurves. Och när det gäller end-to-end kryptering så titta på axolotl (som nu WhatsApp använder).

krypto memeHåll Er borta från SHA1, 3DES, MD5 samt snake oil där utvecklare eller tillverkare skryter med löjligt stora nyckellängder eller oknäckbara system.

Och glöm framförallt inte att valet av algoritmer bara är en liten del av ett mycket större arbete som omfattar nyckelhantering, signering, kodgranskning, lökprincipen, patchning och uppsäkrade system och framförallt användare som ska använda systemet samt utbildas.

Hacka flygplan, går det?

Hacka flygplan - Bild CC Wikipedia

Sedan några veckor så har nyheten om att IT-säkerhetsexperten Chris Roberts ska ha hackat flygplan figurerat i media. Även så påstås att han fått flygplan att stiga och svänga genom att hacka sig in på Thrust Management Computer (TMC) via underhållningssystemet (IFE).

De källor som pekar på att han genomfört detta på flygplan skarpt är FBI:s egna anteckningar från förhör med honom. Han har blivit arresterad men senare släpptes han.

Troligtvis finns det möjlighet att penetrera ett flygplan via underhållningssystemets anslutningspunkter som återfinnes vid varje stol. Men sedan att besitta kompetensen att skriva över och modifiera flygplanets övriga komponenter tror jag är svårt samt så en koppling mellan systemen tror jag inte finns. Så ja, det går att hacka flygplan går, men inte som på film.

Roberts har hackat bilar och flygplan sedan 2010 då han först presenterade sin forskning på konferensen BSidesLV i Las Vegas.

Denna skämt-tweet fick FBI att se rött och förhöra honom: