Heartbleed dag sex

broken-heartbleedYtterligare ett antal dagar har nu passerat sedan OpenSSL-buggen Heartbleed offentliggjordes och det är dags att göra ett antal till reflektioner.

Det har visat sig att buggen går att nyttja till att erhålla den privata nyckeln, framförallt via Hearbleed Challenge.

The bad news is that [discovery] changes our recommendation from: reissue and revoke as a medium priority to reissue and revoke as a high priority.

Skrev Matthew Prince, CEO på CloudFlare till Ars Technica.

Akamai har släppt en patch för att säkra upp minnesallokeringen i OpenSSL. Deras implementation går under namnet secure_malloc (OpenSSL använder sig av OPENSSL_malloc). Läs även mer här av Alex Clemmer.

Även oklart huruvida denna sårbarhet nyttjas innan den blev offentligt känd. EFF hävdar dock att så är fallet och har bevis på detta.

Bra saker som händer efter Heartbleed

OpenSSL får mer donationer som går att granska kodbasen samt så kontrollerar generellt fler ögon OpenSSL efter buggar.

Revokeringen av certifikat ses över då exempelvis Chrome har revokeringskontroll avstängt som standard.

Forward-secrecy eller PFS som det också kallas blir mer använt.

Uppdatering: Bra blogginlägg av Einar Otto Stangvik om hur han gick till väga för att hitta den privata nyckeln.

OpenSSL Heartbleed dag två

broken-heartbleedDet har nu gått över två dagar sedan nyheten släpptes om sårbarheten i OpenSSL, som går under namnet Heartbleed. Det börjar bli dags att sammanfatta samt dra några slutsatser om sårbarheten.

OpenSSL is not developed by a responsible team.

– Theo de Raadt (Källa)

  • Huruvida privata nycklar kan läckas är ännu oklart men för att vara på den säkra sidan så bör nya certifikat utfärdas och privata nycklar skapas.
  • Det har verifierats att åtminstone på FreeBSD så går det att få ut privata nycklar. Uppdatering: Om systemet nyligen startats. Källa
  • Sessionsnycklar dvs cookies är lätt att exfiltrera via Heartbleed.
  • Nätverkstrafik bör sparas ner i en cyklisk buffer (FIFO) för att ges möjlighet att gå tillbaka och se om sårbarheten nyttjas. Hur lång tid tillbaka begänsas av lagringsutrymmet. Även bra för att se vad som företaget eller organisationen blivit av med. Uppdatering: Så klart ej möjligt att se vad för data som exfiltrerats om du använder PFS som Jimmy Bergman påpekar i en kommentar.
  • Regler till IDS:er finns ut såsom Snort.
  • Finns även en Heartbleed Honeypot.
  • Stora drakarna såsom Google, Twitter och Facebook var ute tidigt och patchade mycket snabbt.
  • Några hundra av Internets topp 1000 största sajter är fortfarande sårbara.
  • Röster höjs över att C är ett skräpspråk som tillåter detta fel. Varför inte skriva om allt i Go, Python eller [sätt in valfritt språk här]?
  • Byta lösenord kan vara bra om du loggat in på någon https-tjänst de senaste dagarna.
  • OpenSSL finns inbakat i en hel del hårdvara som ännu ej uppdaterats.
  • Anonymiseringsnätverket Tor såg tidigt att antagonister försökte nyttja svagheten.
  • Prioriteringarna hos de som släppte informationen kan frågasättas. Exempelvis varför domänregistrering av heartbleed.com, skapande av logotyp etc kom före att informera mjukvaru-utvecklare.
  • Diversering bland mjukvaror är bra. Läs Dan Geers rapport om monoculture.
  • Det finns oneliners, script till Nessus och Nmap samt modul till Metasploit för att nyttja sårbarheten.
  • Flertalet tjänster gör det säkra före det osäkra och stänger helt ner tills de patchat och bytt nycklar. Exempelvis Mojang/Minecraft.
  • Många skiter i att eventuella privata nycklar röjts, exempelvis Swedbank. Uppdatering: De var troligtvis aldrig sårbara i första hand.
  • Buggen introducerades Sun, 1 Jan 2012 00:59:57 +0200 (22:59 +0000), se git.
  • Använd tvåfaktorsautentisering och Perfect Forward Secrecy (PFS).
  • Revokera nuvarande certifikat.

 

 

Finns säkert en hel till. Lämna gärna en kommentar nedan. Och avslutar med följande bild:

Heartbleed honeypot

Heartbleed CVE-2014-0160

Uppdatering: Läs även det nya inlägget här.

Då var det dags att uppgradera OpenSSL: En ny sårbarhet har identifierats i hanteringen av heartbeats.

Denna sårbarhet är synnerligen läskig då följden bl.a. kan bli att din privata nyckel läcker ut och en obehörig kan dekryptera tidigare eller pågående data såsom cookies (sessionsnycklar).

Detta gäller OpenSSL versioner 1.0.1 samt 1.0.2-beta men även 1.0.1f och 1.0.2-beta1.

Och här kan du testa om din server är sårbar: http://filippo.io/Heartbleed/

Glöm inte att sårbarheten gäller ej enbart https utan andra protokoll som förlitar sig på SSL/TLS och specifikt med hjälp av OpenSSL.

Teknisk analys av sårbarheten

Den första byten i SSLv3 paketen anger om det är ett heartbeat-paket eller ej. Koden som den är skriven förlitar sig på att klienten skickar tillräckligt med data. Vilket en angripare kan strunta i.

Har du blivit av med din privata nyckel så är det inte bara att byta.. och hur vet ni att ni blivit av med den privata nyckeln?

Även så ryktas det att denna sårbarhet påverkar klienter och ej enbart servrar.

Här finns RFC:n https://tools.ietf.org/html/rfc6520 och en mer teknisk analys finnes här:

blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html

 

Granskning av Cryptocat

Cryptocat

Företaget Least Authority har genomfört en granskning av den populära krypterade chatt-klienten Cryptocat. Kopplingar till Sverige finns också då Bahnhof erbjuder serverplats i deras bunker.

Granskningen påvisar flertalet fel såsom att återanvända IV och nyckel. Även att det går att återanvända alias för att utge sig för någon annan.

Majoriteten av kodbasen är skriven i Javascript.

The audit investigated essential security properties such as the confidentiality and integrity protection of Cryptocat  chat sessions and file transfers. The audit techniques included interactive penetration testing, code and design analysis, and discussion with developers.

For the purposes of this audit, we assume integrity of the Cryptocat  add-on installed by the user.

A well-known outstanding attack is the side channel of timing information emitted by the implementation of cryptographic algorithms computing on secrets. It is an unsolved problem how to prevent that information leakage with cryptographic algorithms implemented in JavaScript . This issue is outside the scope of this audit.

Här kan du ladda hem granskningen som PDF:

Uppdatering: Även så har iSEC Partners genomfört en granskning som är mer fokuserad på iPhone som du kan läsa här:

Ny version av Tails

Tor onion

Tails är ett inkognito-operativsystem (OS) från Tor-projektet. OS:et är baserat på Linux och innehåller enbart ett fåtal applikationer som anses säkra. Även så är Tor inkluderat för anonym anslutning till Internet.

Systemet är ett såkallat Live-system och kan således startas direkt på din dator via USB-minne eller CD-skiva.

Den nya versionen som kom ut i dag har nummer 0.23 och innehåller mestadels säkerhetsfixar men även ett antal andra förbättringar som gör att din integritet höjs och spårning blir svårare:

  • Slumpmässig MAC-adress på nätverkskortet
  • Hur du ansluter via Tor. Sitter du bakom en brandvägg som enbart tillåter webbsurf eller behöver du kringgå DPI (Deep Packet Inspection).

Här kan du hitta changelog:

https://git-tails.immerda.ch/tails/plain/debian/changelog

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.

Kryptografiska valutor & Bitcoin

Kanske har du läst om Bitcoin i tidningen någon gång, om att priset går upp eller ner. Men vad är egentligen en kryptografisk valuta? Hur kan den fungera och vad skiljer den från traditionella valutor som kronor, dollar och euro?

För att svara på den fråga behöver vi först fundera på av vad en valuta är och varför de flesta valutor för det mesta går att använda för att betala för varor och tjänster. Den typiska valutan för hundra år sedan var utgiven av en centralbank som garanterade att en viss mängd av valutan gick att växla mot en given mängd av en ädel metall, till exempel guld. Centralbankens jobb är att trycka sedlar och mynt som är svåra att förfalska och att se till att det finns tillräckligt med guld i kassavalven för att alla som vill växla skall kunna få motsvarande guld.

Ett sådant system av pengar har ett stort värde för ett samhälle, eftersom det möjliggör mer komplicerad handel än byteshandel. Det visar sig också att så länge alla litar på att riksbanken inte tillverkar massor med nya sedlar och mynt så att valutan minskar dramatiskt i värde så går det att klara sig utan kopplingen till ädla metaller. Så fungerar valutor idag.

Men måste en valuta ha en centralbank? Inte nödvändigtvis. Om de går att hitta ett annat sätt att garantera att det bara finns en viss specifik mängd av något så skulle detta något också kunna användas som valuta. Något som det var lätt att känna igen och lätt att skicka från en köpare till en säljare. Med utgångspunkt i dessa kriterier skapades Bitcoin utifrån det radikala antagandet att matematik och datorers beräkningskapacitet kan användas för att skapa ett system som uppfyller kriterierna för att kunna fungera som en valuta.

Bitcoin använder två kryptografiska mekanismer: kontrollsummor och kryptografisk signatur. Dessa utgör tillsammans grundbultarna i ett komplett system för en alternativ valuta.

Kryptografisk signatur

Den som tar emot eller sänder en bitcoin behöver en adress. En adress är en publik del av BitCoinett asymmetriskt nyckelpar. Den som skapade adressen har även den andra delen, en hemlig nyckel och med hjälp av denna kan ägaren signera en ny transaktion som skickar bitcoin-värdet vidare till någon annans adress. Signaturen kan sedan verifieras med en dator som matematiskt bevisar att någon med tillgång till rätt hemlig nyckel skapade transaktionen.

Blockkedjan och gruvdrift

Att kunna skapa matematiskt säkrade transaktioner som bevisar Anna skickat en bitcoin till Berit är har visserligen sina poänger, men innan det finns ett otvetydigt sätt att avgöra att Anna har en bitcoin att skicka så är systemet som helhet lite begränsat. Det är här blockkedjan kommer in. Blockkedjan är en publikt tillgänglig länkad lista över alla giltiga transaktioner i systemet. Ungefär var tionde minut läggs ett nytt block till listan. Blocket innehåller information om en massa bitcoin-transaktioner mellan olika adresser men även en notering om några helt nya bitcoins som skapats. Det är det ända sättet att skapa bitcoins.

Vad är det så som gör att inte vem som helst när som helst kan skapa ett nytt block och lägga till listan i den process som kallas gruvdrift eller mining på engelska? Det beror på att varje block måste ha en kryptografisk kontrollsumma av typen SHA-256 med vissa speciella egenskaper. Att hitta en kontrollsumma med rätt egenskaper (den måste börja med väldigt många nollor) kräver väldigt många försök. Runt om i världen står det datorer med specialbyggda kretsar som prövar och prövar tills de hittar en kontrollsumma som uppfyller kriterierna.

Med hjälp av blockkedjan, som i dagsläget är några gigabyte stor, kan en bitcoin-klient avgöra vilka adresser som har ett saldo som ännu inte är spenderat. Den som vill skicka bitcoin till någon skapar en singerad transaktion som för över en specifik mängd bitcoin från en adress med ett saldo till en mottagaradress. Transaktionen skickas sedan till nätverket av datorer som ägnar sig åt gruvdrift och letar efter nästa block till kedjan. När transaktionen väl kommer med i ett block och fogas till kedjan går den att lita på för mottagaren.

Copyright © 2014 Noa Resare

Licensed via Creative Commons CC-By 4.0.

Bild med kryptovalutor är CC-BY 4.0 kryptera.se

Ny okänd kryptoattack i skadlig kod

Den skadliga spionprogramvaran Flame, som infekterade datorer i Iran 2012, uppnådde matematiska genombrott som bara kunde ha utförts av kryptografer av världsklass, menade två av världens främsta krypteringsexperter:

 Vi har bekräftat att den skadliga koden Flame använder en ännu okänd MD5 kollisionsattack med valt-prefix.

Skrev Marc Stevens i ett e-postmeddelande som skickades till en diskussionsgrupp om kryptografi tidigare i föregånde vecka. ”Kollisionsattacken i sig är mycket intressant från en vetenskaplig synvinkel och det finns redan några praktiska slutsatser.” Benne de Weger, en kollega till Stevens, och en annan expert på kryptografiska kollisionsattacker, som informerades om resultaten, var eniga.

”Kollisions”-attack, då två olika källor av klartext genererar identiska kryptografiska hash, har sedan länge funnits i teorin. Men det var inte förrän sent under 2008 som ett forskarteam utförde ett fullständigt praktiskt sådant. Genom att använda ett nätverk av 200 PlayStation 3-konsoler för att hitta kollisioner i MD5 algoritmen — och att utnyttja svagheterna i sättet på vilket SSL-certifikat utfärdades — som de konstruerade en falsk-certifikatutfärdare, som var betrodd av alla större browsers och operativsystem. Stevens, från Centrum Wiskunde & Informatica i Amsterdam, och de Weger, vid Technische Vrije Universiteit Eindhoven, var två av de sju drivkrafterna bakom forskningen som gjorde 2008-attacken möjligt.

Flame är det första kända exemplet på en MD5 kollisionsattack, som använts i elakt uppsåt i en verklig miljö. Det hanterade esoterisk teknik för att digitalt signera skadlig kod med ett falskt intyg som verkade ha sitt ursprung hos Microsoft. Genom att distribuera falska servrar i nätverk som var värdar för datorer som redan var smittade av Flame — och genom att använda certifikaten för att signera moduler i Flame — kunde den skadliga programvaran kapa Windows uppdateringsmekanism som Microsoft använder för att distribuera korrigeringsfiler till hundratals miljoner kunder.

Enligt Stevens och de Weger är kollisionsattackerna utförda av Flame en ny betydande vetenskaplig upptäckt. De kom till denna slutsats efter att Stevens använt ett anpassat kriminaltekniskt verktyg som han utvecklat för att upptäcka och analysera hash-kollisioner.

Ännu intressantare är att resultaten har visat, att våra publicerade kollisionsattacker med vald-prefix inte användes, utan en helt ny och okänd variant”, skrev Stevens i ett uttalande som distribuerades under torsdagen. ”Detta har lett till vår slutsats att utformningen av Flame är delvis baserat kryptoanalys av världsklass. Ytterligare forskning kommer att utföras för att rekonstruera hela kollisionsattacken med vald-prefix, som planerades för Flame.

Analysen förstärker teorier som forskare från Kaspersky Lab, CrySyS Lab och Symantec publicerade för nästan två veckor sedan. Nämligen att Flame kan enbart ha utvecklats med stöd av en välbärgad nationsstat.

Tor Instant Messaging Bundle (TIMB)

Tor-projektet har börjat arbetet med att ta fram en egen säker meddelande-funktion (instant messaging). Projektet går under namnet TIMB eller Tor Instant Messaging Bundle.

Projektet började med en genomgång av olika meddelande-klienter för att välja den som är lättast att anpassa gällande säkerhet, kryptering och hackbarhet (modifiering).

Valet föll på Instantbird och även om Instantbird ej stödjer OTR (Off-the-Record) så kommer det att läggas till.

Instantbird fungerar på flertalet plattformar såsom Linux, Windows och Mac OS X och är baserat på Mozillas XULRunner.

Protokoll som kommer att stödjas är troligtvis IRC samt XMPP från början, detta pga att Tor ej vill använda sig av libpurple som annars stödjer en större mängd chatt-protokoll.

Utvecklingen av TIMB kan du följa här:

TLS Fallback Signaling (SCSV)

TLS Fallback Signaling Cipher Suite Value (SCSV) är en ny föreslagen IEFT standard (draft) från Adam Langley och Bodo Moeller på Google.

SCSV är tänkt att användas för en TLS-klient såsom webbläsare att berätta för servern när en handskakning misslyckas och återupptas med en lägre TLS/SSL-version.

Varför är detta viktigt?

Jo,  om en angripare kan på något sätt få en klient att misslyckas med sin handskakning och sedan nedgradera anslutningen från TLSv1.2 exempelvis SSLv3 och därefter nyttja en svaghet i SSLv3.

Som det fungerar rent praktiskt med SCSV implementerat så skickar klienten en cipher-suite som ej finns på riktigt.

Denna är:

TLS_FALLBACK_SCSV {0x56, 0x00}

Men vad ska servern göra när denna cipher-suite dyker upp från en klient? Jo servern ska kontrollera att förhandlingen verkligen gäller den högsta version som både klienten och server stödjer:

If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
highest protocol version supported by the server is higher than
the version indicated in ClientHello.client_version, the server
MUST respond with a inappropriate_fallback alert.

Läser man vad Adam har skrivit på sin blogg så verkar implementationen gjort att många prylar slutat att fungera. Såsom F5:s webbcachar och Kasperskys anti-virusprodukter som genomför SSL MITM (ej standard).

Här kan du läsa vidare i du den fullständiga draften: