Taggat med: dnssec

DNStapir – Robust DNS

Jag tog ett snack under sommaren Olle E Johansson som är en av initiativtagarna bakom projektet DNSTapir. Olle berättar mer om projektet:

Fokus vad gäller DNS har varit mycket på hur man kan skydda sina frågor från insyn och hur vi kan lita på svaren. Vi såg att det finns mycket information i loggarna från DNS resolvers, dom som förmedlar svar, som är värd att analysera. Det görs idag, men i många fall av utländska aktörer som förser oss med gratis resolvertjänster. Vi vill se till att loggarna anonymiseras och att vi kan analysera data och se vad som händer, inte minst ur cybersäkerhetssynpunkt.

Med stöd av Sunet/Vetenskapsrådet bildade vi projektet Robust DNS som nu fått projektmedel av Post- och Telestyrelsen. Organisation: Vi är nu i en uppstartsfas av ett utvecklingsprojekt och ett Open Source-projekt. All utveckling kommer att ske öppet i vårt projekt ”DNStapir” på Github. Dagens gäng är initiativtagarna – däribland Lars Johan Liman på Netnod, Johan Stenstam på Internetstiftelsen, Jakob Schlyter på Kirei och Mikael Kullberg på Cat Herd. Leif Johansson på Sunet satte oss i samma rum och har fått igång projektet.

DNSTapir Robust DNS

Vi har också resurser från Sunet i projektet och kommer att utvidga vårt nätverk och bygga en långsiktig organisation. Jag har en sammahållande funktion i det hela.  Partners bakom projektet är idag PTS, Sunet/Vetenskapsrådet, Netnod och Internetstiftelsen. Vi kommer att söka samarbete med fler organisationer, både i näringslivet och i offentlig sektor. Framtidsplaner: Vi jobbar nu med steg 1: Utveckling av arkitektur och programvara.

Samtidigt planerar vi för kommande steg som innebär att bygga för drift och ge oss en stabil grund för vidare utveckling. Idéerna sprudlar och vi har många roliga diskussioner i arbetsgruppen. Målet är att vi ska bygga en plattform som olika operatörer – såväl privata som i offentlig sektor – har förtroende för. För att lyckas krävs ett samarbete, inte minst med Sveriges internetoperatörer. Vad gäller DNS generellt så är jag nog inte rätt person att svara, men har ju expertisen i projektet. Det pågår ju mycket arbete i IETF för att öka privacy i DNS och stärka infrastrukturen. Ett problem jag ser är ju att DNSSec inte har acceptans i alla kretsar och i viss mån motarbetas.

Personligen är jag ju intresserad av att förankra klient- och server-certifikat i DNS, vilket förutsätter DNSsec. Jag är med i arbetsgruppen DANCE som jobbar med klient-cert. Den lösningen handlar mer om TLS och applikationer än själva DNS, men förutsätter DNSsec.

Kontaktuppgifter: Om man har frågor får man gärna kontakta mig direkt. Som sagt, vi bygger upp en organisation inklusive web sajt och kommer att synas mer under hösten. Projektet DNStapir finns redan på GitHub och där kommer det löpande komma mer kod och ges möjlighet att medverka.

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.

Granskning av TV-leaks

För några veckor sedan så startade SVT sajten TV-leaks för att underlätta för visselblåsare (skvallrare) att kontakta journalister krypterat. Teknisk leverantör av tjänsten är Bahnhof tillsammans med Wikileaks (källa).

Vi kommer i denna granskning redovisa ett antal olika brister i tjänsten. Önskar du läsa sammanfattningen kan du gå längst ned.

SVT uppger på sin hemsida följande:

Tjänsten består av ett webbformulär där det går att posta dokument, filmer eller bilder. På SVT finns två mottagardatorer, inlåsta i skåp som endast utvalda medarbetare har tillgång till. Servrarna ligger i ett skyddat bergrum och informationen är hårt krypterad.

Tittar vi mer noggrant så återfinnes tjänsten under domännamnet tvleaks.se och går att nå via http eller https. Vi rekommenderar att enbart https används, för http-versionen öppnar upp för angrepp.

Så här ser det ut med omredigeringen om vi besöker tjänsten okrypterat via http:

TV-LEAKS

Analys av https på tv-leaks

tvleaks https A-

Om vi kör tvleaks.se genom testet som SSL Labs tillhandahåller så får tjänsten betyget A-. Att man ej får fullt betyg (A) är för att tvleaks ej använder sig av PFS (forward secrecy) när det gäller referenswebbläsararen som SSL Labs använder sig av.

Vad betyder detta säkerhetsmässigt då? Jo, om någon kan komma över privata nyckeln genom fysisk tillgång till servern eller via intrång så är det möjligt att återskapa den krypterade informationen i efterhand.

Utfärdare av SSL-certifikatet är thawte och man använder sig av ett s.k. Extended Validation (EV) certifikat vilket kan inbringa mer förtroende.

Servern använder 2048 bitars RSA-nyckel och är giltigt från fredag 13 december 2013 kl. 01:00:00 till måndag 14 december 2015 kl. 00:59:59.

Traceroute

Enligt traceroute så är servern troligtvis placerad i Stockholm:

  • mmo-cr1.sto-cr1.bahnhof.net (85.24.151.155)
  • sto-cr1.thu-dr1.bahnhof.net (85.24.151.207)
  • h-253-14.a139.corp.bahnhof.se (5.150.253.14)

Och IP-adressen tillhör av Bahnhof:

Screen Shot 2014-02-24 at 13.22.47

Domännamnet tvleaks.se

Ägare av domännamnet tvleaks är Thomas P. hos SVT och som registrar används Groth & Co. Tittar vi med .SE DNScheck så ger kontrollen varningar. Namnet registrerades 2013-09-17 och använder sig av tre namnservrar:

  • nserver: ns3.groth.se
  • nserver: ns2.groth.se
  • nserver: ns1.groth.se

Tyvärr har man ej registrerat tv-leaks.se, svtleaks.se eller liknande samt så använder tvleaks ej DNSSEC.

Information som skickas till tvleaks

OpenPGPjsGenom att titta på källkoden på webbsidan så hittar vi en publik PGP-nyckel som skapats med BCPG C# v1.6.1.0. Att just  BCPG använts för att skapa den publika PGP-nyckeln är troligtvis för att SVT utvecklat en egen programmvara i språket C# och som använder programmeringsbiblioteket Bouncy Castle för PGP-dekryptering.

Denna egenutvecklade programmvara används troligtvis på två inlåsta datorer hos SVT (läs ovan).

Den publika PGP-nyckel som används är följande:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: BCPG C# v1.6.1.0

mQENBFJgF40BCACo55jBfaiPg9L8YdFTurB1INum85ia/MP2WsCYaPShltM0qKS/
2UNmv/bXp0Nq7SgYvrs4xYRM2A71AONdXnyzMz7zCB5H3i/U3qF7D0eMMyQAhCPK
bMEXxpo96bOhlWyHnjPFVvXUwS/w1xDNRVrYetc9vAPM1kIOOcuABY8LpHLviVTZ
m+RIQ7akOhUmGekdo4vHGAlPJjOE0hJUh34ZG79Vp9vVDMd6O+CAZQMhO/dpp7zg
Y6TsL37q44vX6dyJuRLqPjvWfQLjJXDii/6LHz1+S+ETDC1RXtkJOCOkuvAl7S+T
/Bmu+nrEHDW5KvvlmfS5L8F7hTnVcwYtozkHABEBAAG0AIkBHAQQAQIABgUCUmAX
jQAKCRDQoJAgkU0kul56B/oCDRFETr9GFOi0ur6hsRfzJ9pD6FL+2ZcDFudPLlxH
pG80wbJf6SRkC6xK6KCrph6NBaE4FFMIXtO9fVX9nqrmCENwynv8Um+epXLDZUNU
J9YBzwnQ4l9+KDJ5lpIC0LrzHrZmUvg0/zeqOM9k5fLnHZTGQKSSX7vrEKwi/V49
TerDrPot2uNw+fs7rSyD17egCqIMK/0HVQcR4/IF/W1GWor8MxGnn7J57y+5fBN7
4AlT8TLEpmH4eZdwikUwgIBb9MPVId1v5RRBtf/gA0J5BBZvzFpe8f+ai+Qg6AYS
kbxcu3GCCDepEPj6NMxUeuIMM3Nzt2RMjsmR5x2KJf36
=CwA4
-----END PGP PUBLIC KEY BLOCK-----

Meddeladen som sedan skickas via formuläret på hemsidan ska krypteras med ovan nyckel och OpenPGP.js, exempel på ett krypterat meddelande:

-----BEGIN PGP MESSAGE-----
Version: OpenPGP.js v.1.20130712
Comment: http://openpgpjs.org

wcBMA9CgkCCRTSS6AQf8CyJZUxF+x+VKOW663mIk6ku12kdocg85k/LT2jRa
QoMwOZVVyEQdzT0ihuOM7MMBYoLunlBBgiBbs828fhZP07UN+EkDN8aYudeM
pvMmxOhGdWCjX2xa1THJreHDKw7q+NCAkrR95oXr82JZqkLeghYpOMrJSdD8
AESqKfpljhPMLh+CQT3WIDFZ7l6vuXegcxeaviGUu2cqP2Rl0Acus1HxhPaw
RV1BJfUxZnCvSPdz4A7D/yti1k++Ab4H7A20TjeMzYX4koguzxO85yqXqf3u
cxKGvGOU2r+5WhdK27YwSY1Xb38ehHhd6G9TZRRqEkOgTwjv9m8LtQrrmYqa
3tKOAbfyQnL3Po5uCJQApLRVYTWrKQfC6VF0VvrlQA4OLdo+SvxhHdxAF3jj
2ABSOOQ3XtKANMtJ+7O0M6p2HJCWAAw8LbmIQmpxUzd5gSayNuVw5nQ2BslT
v8TLWBVEukc2r539kXHQRaqXR1aiv6f/Jhg4XFM6FE+rCxFfNO0RPcoUfWx4
ay8UWrxi0RqXTQ==
=JFg1
-----END PGP MESSAGE-----

När informationen sedan skickas vidare från webbläsaren till servern hos Bahnhof så skickas tyvärr informationen ej krypterad med denna PGP-nyckel som SVT uppger på sidan:

”Meddelanderutan samt dina kontaktuppgifter i formuläret krypteras direkt i webbläsaren.”

Men i verkligheten så krypteras ej kontaktuppgifter till uppgiftslämnaren samt ämnet direkt i webbläsaren, se följande skärmdump då vi testar att skicka över ett meddelande med ”Mitt ämne” som ämne samt ”Mitt namn” som namn:

tv-leaks leaks

Hur kan det ha blivit så här fel? Troligtvis för att enctype=”multipart/form-data” används i formuläret då det finns möjlighet att skicka filer. Webbläsaren skickar då med helt formuläret till servern (testat med Mac OS X och Google Chrome version 32).

PGP-nyckel

Skapades Thu Oct 17 16:59:57 UTC 2013 och är 2048 bitar samt ser bra ut i övrigt (exempelvis RSA exponenten är 65537):

Old: Public Key Packet(tag 6)(269 bytes)
        Ver 4 - new
        Public key creation time - Thu Oct 17 16:59:57 UTC 2013
        Pub alg - RSA Encrypt or Sign(pub 1)
        RSA n(2048 bits) - a8 e7 98 c1 7d a8 8f 83 d2 fc 61 d1 53 ba b0 75 20 db a6 f3 98 9a fc c3 f6 5a c0 98 68 f4 a1 96 d3 34 a8 a4 bf d9 43 66 bf f6 d7 a7 43 6a ed 28 18 be bb 38 c5 84 4c d8 0e f5 00 e3 5d 5e 7c b3 33 3e f3 08 1e 47 de 2f d4 de a1 7b 0f 47 8c 33 24 00 84 23 ca 6c c1 17 c6 9a 3d e9 b3 a1 95 6c 87 9e 33 c5 56 f5 d4 c1 2f f0 d7 10 cd 45 5a d8 7a d7 3d bc 03 cc d6 42 0e 39 cb 80 05 8f 0b a4 72 ef 89 54 d9 9b e4 48 43 b6 a4 3a 15 26 19 e9 1d a3 8b c7 18 09 4f 26 33 84 d2 12 54 87 7e 19 1b bf 55 a7 db d5 0c c7 7a 3b e0 80 65 03 21 3b f7 69 a7 bc e0 63 a4 ec 2f 7e ea e3 8b d7 e9 dc 89 b9 12 ea 3e 3b d6 7d 02 e3 25 70 e2 8b fe 8b 1f 3d 7e 4b e1 13 0c 2d 51 5e d9 09 38 23 a4 ba f0 25 ed 2f 93 fc 19 ae fa 7a c4 1c 35 b9 2a fb e5 99 f4 b9 2f c1 7b 85 39 d5 73 06 2d a3 39 07 
        RSA e(17 bits) - 01 00 01 
Old: User ID Packet(tag 13)(0 bytes)
        User ID - 
Old: Signature Packet(tag 2)(284 bytes)
        Ver 4 - new
        Sig type - Generic certification of a User ID and Public Key packet(0x10).
        Pub alg - RSA Encrypt or Sign(pub 1)
        Hash alg - SHA1(hash 2)
        Hashed Sub: signature creation time(sub 2)(4 bytes)
                Time - Thu Oct 17 16:59:57 UTC 2013
        Sub: issuer key ID(sub 16)(8 bytes)
                Key ID - 0xD0A09020914D24BA
        Hash left 2 bytes - 5e 7a 
        RSA m^d mod n(2042 bits) - 02 0d 11 44 4e bf 46 14 e8 b4 ba be a1 b1 17 f3 27 da 43 e8 52 fe d9 97 03 16 e7 4f 2e 5c 47 a4 6f 34 c1 b2 5f e9 24 64 0b ac 4a e8 a0 ab a6 1e 8d 05 a1 38 14 53 08 5e d3 bd 7d 55 fd 9e aa e6 08 43 70 ca 7b fc 52 6f 9e a5 72 c3 65 43 54 27 d6 01 cf 09 d0 e2 5f 7e 28 32 79 96 92 02 d0 ba f3 1e b6 66 52 f8 34 ff 37 aa 38 cf 64 e5 f2 e7 1d 94 c6 40 a4 92 5f bb eb 10 ac 22 fd 5e 3d 4d ea c3 ac fa 2d da e3 70 f9 fb 3b ad 2c 83 d7 b7 a0 0a a2 0c 2b fd 07 55 07 11 e3 f2 05 fd 6d 46 5a 8a fc 33 11 a7 9f b2 79 ef 2f b9 7c 13 7b e0 09 53 f1 32 c4 a6 61 f8 79 97 70 8a 45 30 80 80 5b f4 c3 d5 21 dd 6f e5 14 41 b5 ff e0 03 42 79 04 16 6f cc 5a 5e f1 ff 9a 8b e4 20 e8 06 12 91 bc 5c bb 71 82 08 37 a9 10 f8 fa 34 cc 54 7a e2 0c 33 73 73 b7 64 4c 8e c9 91 e7 1d 8a 25 fd fa 
                -> PKCS-1

Övrigt

Länken för att läsa mer om tjänsten fungerar ej, den länkar till svt.se/tvleaks och ger ett 404-felmeddelande. Även så fungerar ej länken där SVT uppger att man kan läsa mer om vad man ska tänka på när man tipsar SVT.

Och om du inte har läst varför man ej bör använda JavaScript-kryptering så läs denna utmärkta artikel av Matasano.

jQuery version v1.6.1 används samt OpenPGP.js v.1.20130712. Severn uppger att det är opertivsystemet Ubuntu med webbservern Apache/2.2.22 och PHP/5.3.10-1ubuntu3.9.

Bra är att inga externa anrop genom exempelvis javascript genomförs. Detta genomförde bl.a. Poosty som vi testat tidigare. Google Analytics är populärt att använda men äventyrar säkerheten.

Ingen mailpekare hittas och ingen information i archive.org. Även så bör HSTS användas, speciellt med tanke på att http vidarebefodras till https.

Inga cookies identifierades.

Sammanfattning

Säkerheten har en bra nivå men kan bli bättre. En eventuell angripare kan kombinera att PFS ej används samt att all information ej krypteras med hjälp av PGP så kan meddelanden återskapas.

Ingen granskning av tredje part verkar ha genomförts. Detta är så klart något som rekommenderas. Även att genomföra aktiva attacker vilket är något som vi ej genomfört.

Vi har givetvis kontaktat SVT innan publiceringen av denna granskning och problemen som identifierats är åtgärdade eller delvis åtgärdade.

#MeraKrypto

MeraKrypto

#MeraKrypto är ett projekt där SNUS (Swedish Network Users’ Society) tillsammans med ISOC-SE vill bl.a. se att mer kryptografiska protokoll används. I ett blogginlägg på isoc.se så skriver Olle E. Johansson att vi måste höja ribban för att försvåra för utomstående att läsa trafik.

Johansson sammanfattar några av de svenska initiativ som används för att höja ribban med följande projekt:

  • Daniel Stenberg är med i arbetet runt HTTP 2.0 som troligen bara kommer använda TLS.
  • Jakob Schlyter jobbar med DANE och DNSSEC.
  • Olle E. Johansson jobbar med SIP och WebRTC.

Och även så frågar han sig hur detta ska mätas? Hur kan vi mäta att mer krypto används och inte mindre? Även om the goodguys blir bättre på att använda kryptering så blir även de badguys bättre på att använda kryptering.

Även om de onda inte kan skilja på bytes och bitar som i senaste fallet med Bitcrypt så invaggas många av en falsk säkerhet bara för att exempelvis https används.

Tillsammans kan vi dock göra Internet till en säkrare plats för alla.

Windows 8 lösenord, RC4, Google Wallet och MSB

Vi sammanfattar här några av de nyhterna vi tweetat ut de senaste dagarna:

Du följer väl oss på Twitter? https://twitter.com/kryptera

Root Zon DNSSEC KSK Ritual #4

Snart är det dags för nummer fyra av DNSSEC KSK signeringsritualen. Den kommer att gå av stapeln i El Segundo, Kalifornien, USA på måndag 2011-02-07. Ritualen beräknas börja kl 2100 UTC och slutar kl 0300 UTC .

Rörlig bild kommer att finnas tillgänglig om några veckor på iana.org/dnssec eller live direkt på dns.icann.org/ksk/stream

Ceremony 4 will include processing of a Key Signing Request (KSR)
generated by VeriSign, and the resulting Signed Key Response (SKR)
will contain signatures for Q2 2011, for use in the root zone between
2011-04-01 and 2011-07-05.

DNSSEC – Till vilket pris?

I senaste numret av Cisco IP Journal Volume 13 Number 1 så belyses ett problem som uppstår när DNSSEC börjar att användas och bandbreddsförbrukningen mer än dubbleras:

In other words, in this example scenario with stale Trust Anchor keys in a local client’s resolver, a single attempt to validate a single DNS response will cause the client to send a further 844 queries, and each .com Name Server to receive 56 DNSKEY RR queries and 4 DS RR queries…

The problem with key rollover and local management of trust keys appears to be found in around 1 in every 1,500 resolvers in the in-addr.arpa zones. With a current client population of some 1.5 million distinct resolver client addresses each day for these in-addr.arpa zones, there are some 1,000 resolvers who have lapsed into this repeated query mode following the most recent key rollover of December 2009. Each subzone of in-addr.arpa has six Name Server records, and all servers see this pathological re-query behavior following key rollover.

Root-zonen signerad

Root-zonen har nu äntligen blivit signerad! Vi pratar så klart om den nya standarden för säker DNS som går under namnet DNSSEC. Sverige har länge varit pionjärer inom detta område då .SE som sköter om .SE-zonen länge erbjudit innehavare av .SE-domäner att signera sina zoner (domännamn). Jakob Schlyter och Fredrik Ljunggren är de två konsulter som jobbat åt .SE att implementera nyckelhanteringen.

Nyckelgenereringscermonin ägde rum i Culpeper, Virginia /USA där även Anne-Marie Eklund Löwinder från .SE närvarade förutom delegater från  ett antal länder som såg till att allt gick rätt till.

Mer information finns på root-dnssec.org eller opendnssec.org.

Uppdatering: En läsare uppmärksammade att root-zonen signeras den 15:de Juli. Det är enbart singerings-ceremonin som inträffat ännu.