En ny sårbarhet har uppdagats som gör det möjligt att beräkna IPSec PSK-nycklar offline. Detta gäller både IKEv1 och IKEv2 samt main mode. Aggressive mode har sedan tidigare varit känt att det går att utföra offline forceringsattacker mot, och till viss del även main mode.
Då sårbarheten återfinnes i IKE-standarden så drabbas troligtvis samtliga leverantörer och följande CVE:er har blivit utfärdade än så länge:
Cisco – CVE-2018-0131
Huawei – CVE-2017-17305
ZyXEL – CVE-2018-9129
Clavister – CVE-2018-8753
Själva attacken har CVE-2018-5389
Attacken nyttjar Bleichenbachers attack och har och göra med hur RSA nonces används för autentisering och upptäcktes av Martin Grothe, Joerg Schwenk ochDennis Felsch.
Rekommendationen från teamet som identifierade sårbarheten är att patcha dina enheter samt om du måste använda PSK (pre-shared key) är att använda minst 19 slumpmässiga tecken som inte återfinnes i någon ordlista. Givetvis är certifikatbaserad inloggning säkrast när det gäller IPSEC.
Här nedan kan du ladda hem forskningsrapporten som presenterar attacken under USENIX konferensen:
ROBOT är en ny intressant attack som använder sig av Bleichenbachers Oracle för att attackera tjänster som använder sig av TLS såsom https. Attacken går mot PKCSv1.5 som är en padding som används tillsammans med RSA. Genom att skicka ett antal olika krypterade meddelanden är det möjligt för en angripare att återskapa krypterat https-data.
För att få en uppfattning om hur omfattande problemet med ROBOT-attacken är så kan vi titta på den skanning som Dirk Wetter på testssl.sh projeketet genomfört mot Alexa Top 10k-listan.
Ovan visar alltså på att runt 15% av sajterna är sårbara.
Jag gillar även följande presentationsbild som är från Tibor Jager kurs på Paderborn Universitetet i Tyskland:
Samt så har den officiella sajten RobotAttack.org har sammanställt en lista över sårbara implementationer, där den som är mest anmärkningsvärd är Cisco ACE som tydligen används av många företag men Cisco ej kommer att patcha:
Uppdatering: Även smartcards från Gemalto med produktnamnet IDPrime.NET är sårbara för ROCA. Dock så säljer Gemalto ej dessa sedan September 2017. Gäller dock inte Gemalto-korten med snarlikt namn: Gemalto IDPrime MD.
RSA-nycklar som skapats med hårdvara från tillverkaren Infineon Technologies AG medger att en angripare kan genomföra faktoriseringsattacker. Och således återskapa den privata nyckeln från ett RSA-nyckelpar där enbart den publika RSA-nyckeln är känd. Attacken utnyttjar Coppersmith’s Attack där en låg exponent e används.
Kända användare av hårdvara från Infineon Technologies AG är bl.a. Estlands nationella ID-kort med smartcard.
The worst-case price of the factorization on an Amazon AWS c4 computation instance is $76 for the 1024-bit key and about $40,000 for the 2048-bit key.
Du kan testa om din publika RSA-nyckel är påverkad online eller offline:
Sårbarheten upptäcktes av slovakiska och tjeckiska säkerhetsforskare från Centrum för forskning om kryptografi och säkerhet vid Masaryk University, Tjeckien. Enigma Bridge Ltd, Cambridge, Storbritannien; och Ca ’Foscari University of Venice, Italien.
SSL och TLS har under lång tid säkrat upp en betydande del av den krypterade kommunikationen på Internet. Sedan SSL version 1.0 släpptes internt hos Netscape Communications år 1994 så har det hänt en hel del.
Den nya versionen som just nu håller på att utvecklas inom en arbetsgrupp hos IETF har versionsnumret 1.3 där målsättningen är högre prestanda samt tillhandahålla en ännu högre säkerhet. Man kan säga att designkriteriet för denna nya version är ”less is more” och det innebär att en hel del föråldrade krypton har fått stryka på foten:
Nytt meddelande av typen EncryptedExtension. Som nu är krypterat, tidigare skickades många okrypterat
När det gäller prestanda så har ett antal åtgärder införts:
0-RTT samt 1-RTT
Genom att få ner antalet TCP-paket som måste skickas fram och tillbaka vid varje anslutning så kan snabbare TLS (och webbsidor etc) uppnås.
Här följer en bild hur 1-RTT ser ut där klienten skickar ett ClientHello direkt, samt så gissar klienten vilka krypton som kommer att användas:
När du sedan har en session etablerad så kan sedan 0-RTT användas vid senare tillfälle (Session Resumption) men detta möjliggör dock återuppspelningsattacker.
Vill du redan nu testa TLS 1.3 i Google Chrome så kan du göra följande:
Gå till ”Maximum TLS version enabled.” och välj ”TLS 1.3”
Starta om Chrome
Och vill du testa med Firefox så behöver du ladda hem senaste nightly-build där TLS 1.3 är påslaget som standard.
Och nu när vi besöker kryptera.se och tar upp Developer Tools (DevTools) så synes följande:
Viktigt att tillägga är att TLS 1.3 inte är färdigt ännu och ändras löpande. Detta gör att mjukvara såsom OpenSSL är försiktiga med att göra förändringar. Den senaste uppdateringen till TLS 1.3 heter draft-19 och släpptes för cirka 2 veckor sedan.
För att exempelvis Nginx ska stödja TLS 1.3 så måste även OpenSSL stödja detta. Och OpenSSL kommer med stöd inom några veckor i version 1.1.1.
Uppdaterad 2017-12-27: Enligt Cloudflare är det bara %0.06 av webbläsarna som använder TLS 1.3 och detta beror främst på att många mellanlådor inte stödjer TLS 1.3.
Uppdaterad: 2017-06-06, användes internt hos Netscape. Inte Mozilla som grundades först många år senare.
Jag har genomfört en oberoende granskning av IT-säkerheten på DN:s sajt där användare kan skicka in tips. Tidigare har jag bl.a. granskat SVT:s TV-leaks. Min förhoppning är att fler kan dra lärdomar och således blir säkerheten bättre i längden.
All information nedan är sammanställt med hjälp av öppen information.
Peter Wolodarski som är chefredaktör på DN framhäver på sajten dngranskar.dn.se följande (se även skärmdump ovan):
Vi behöver din hjälp i vårt arbete. De största avslöjandena kommer från människor som har värdefull information. DN lägger stora resurser på granskande journalistik. Här kan du på ett säkert sätt lämna tips till våra undersökande reportrar.
Vidare så läser vi även följande:
Tjänsten är skyddad med hög kryptering för att ge dig som tipsare största möjliga säkerhet. Det innebär att tipset blir oläsligt utan en särskild nyckel. Bara ett begränsat antal reportrar på tidningen har tillgång till denna nyckel.
Denna särskilda nyckel som ovan text refererar till är en PGP-nyckel som ligger inbäddad på webbsidan. Denna nyckel läses sedan av openpgp.js och formulärdata krypteras och skickas över och lagras på serversidan.
Den publika PGP-nyckeln som återfinnes på sidan ser ut enligt följande:
Den med ett tränat öga ser att ovan nyckel inte ser ut att vara speciellt lång, nämligen enbart 1024-bitar RSA, vilket inte är att rekommendera sedan år 2010. Tittar vi närmare på nyckeln så ser vi även att den står på Kristoffer Örstadius.
Även något som är anmärkningsvärt så används inte denna nyckel när jag testar att skicka in ett tips med Firefox, då ser kommunikationen ut enligt följande:
Gör jag samma med Google Chrome så krypteras all information från formuläret med 1024-bitars nyckeln förutom filnamnet:
Tittar vi på webbservern så svarar den att det är en gammal Apache, openssl med en PHP-version som är end-of-life sedan 2015, dvs inga säkerhetsuppdateringar eller liknande kommer. Red Hat tillhandahåller säkerhetsfixar för dessa versioner efter noggrann kontroll:
Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.1e-fips PHP/5.4.16
Övriga saker att anmärka på är även att cookies för spårning och annonsering följer med från dn.se till dngranskar.dn.se såsom _ga (Google Analytics), optimizelyEndUserId, __couid (Kantar Sifo) och _burtAgency. Openpgpjs som används är version 1.30 och den senaste är 2.3.6.
Även bör headers som meddelar att webbläsare inte bör cacha innehåll användas såsom:
Cache-control: no-store
Pragma: no-cache
Sajten från A+ från SSLlabs.com vilket är bra och inga tredjepartsscript eller liknande laddas in.
Sammanfattning
Tjänsten är byggd med flertalet IT-säkerhetsbrister. Kommunikationen går över TLS vilket räddar upp situationen en del men informationen lagras troligtvis i klartext på servern när openpgp.js inte fungerar som den ska.
Jag har kontaktat DN innan publiceringen av denna granskning och DN meddelar att en ny sajt lanseras inom kort. Att titta på för inspiration för framtida arbete är SecureDrop som bl.a. The Guardian och NY Times använder.
Uppdatering: DN meddelar att kryptering även genomförs på serversidan av informationen efter den är inskickad.
Uppdatering:Burp Suites passiva granskning rapporterar 11 st medium-brister och 42 st low:
Eller rättare skrivet så gick den amerikanska myndigheten NSA ut för några dagar sedan och varnade för att många av nutidens algoritmer som används bör uppgraderas för att motstå beräkningar utförda av kvantdatorer.
Det rör framförallt RSA där nyckelstorlekar är under 4096 bitar, men även elliptiska kurvor kan ligga dåligt till eftersom en variant av Shors algoritm kan användas. Eller som NSA uttrycker det:
Minimum 3072 bit-modulus to protect up to TOP SECRET.
Intressant också är gällande hashalgoritmer så rekommenderas minst SHA384, vilket i praktiken innebär SHA512.
Nu innebär detta inte att alla måste byta över en natt utan NSA rekommenderar att leverantörer slutar att leverera och tillverka produkter eller mjukvaror som implementerar algoritmer som ej kan motstå beräkningar utförda av kvantdatorer.
Och förutom RSA och SHA så rekommenderas ECDH (Elliptic Curve Diffie–Hellman) med med minst 384 bitar.
Personligen så föredrar jag Curve25519 av Daniel J Bernstein etc, se SafeCurves. Bitcoin exempelvis använder sig av secp256k1.
The RSA-2048 Challenge Problem would take 1 billion years with a classical computer. A quantum computer could do it in 100 seconds
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:
Nyligen så uppdagades en ny attack mot SSL/TLS vid namn SMACK. Denna attack nyttjar det faktum att många webbsajter i dagsläget erbjuder gamla krypteringsalgoritmer där bl.a. RSA 512 bitar finns med samt en sårbarhet i klienter.
Att faktorisera 512 bitar RSA går relativt snabbt med hjälp av ett kluster hos exempelvis Amazon EC2. Och med hjälp av 75 st servrar hos Amazon tar det cirka 7h och kostar runt 800 SEK. Och verktyget som användes för detta är bl.a. cado-nfs (eller så kan även ggnfs + msieve användas).
Men hur utbrett är problemet eg. med dessa korta nyckellängder på serversidan? Jo, av 14 miljoner sajter som stödjer SSL/TLS så har 36.7% detta problem. Och problemet i detalj består i att om en klient såsom OpenSSL eller Apples SecureTransport får tillbaka ett svar som inkluderar export-grade RSA så kommer dessa klienter att acceptera svaret, även om de ej frågat efter export-grade RSA.
Förfarandet steg för steg:
När klienten skickar sitt Hello-meddelande så frågar den efter standard RSA
Angripare som sitter i mitten (MITM) ändrar detta svar till export RSA
Servern svarar med sin 512-bitars export RSA-nyckel, signerad med sin nyckel för långa livslängder (long term key).
Klienten sväljer detta svar på grund av OpenSSL/SecureTransport-buggen.
Angriparen faktoriserar RSA för att hitta den privata nyckeln
När klienter krypterar ’pre-master secret’ till servern så kan nu angriparen dekryptera TLS huvudhemlighet (master secret)
Nu kan angriparen se klartext och injicera nytt innehåll
Demonstration av hur attacken kan nyttjas mot NSA (eller rättare skrivet, Akamai):
Igår släppte Microsoft sina månatliga patchar för November och en av de mer allvarligare sårbarheterna som åtgärdas medger kodexekvering över nätverket (MS14-066).
Sårbarheten som åtgärdas återfinnes i Microsoft Secure Channel (Schannel) och är den del som hanterar SSL/TLS. Denna sårbarhet gäller enbart Windows Server men Microsoft patch även inkluderar Windows 7 och 8.
Tyvärr så framgår inga temporära åtgärder som kan genomföras för att förmildra en eventuell attack (workarounds).
Även så har Microsoft uppdaterat sina cipher suites och stödjer nu Galois/counter mode (GCM) samt perfect forward secrecy med hjälp av DHE + RSA.
Apple har nu släppt ett dokument som beskriver säkerheten i operativsystemet iOS. Detta dokument är omfattande och är på hela 33 sidor.
I dokumentet beskriver bl.a. att iOS använder sig av ARM-processorns funktion vid namn Execute Never (XN) för att markera pages som icke exekverbara. Även så använder Safari webbläsaren denna för sin JavaScript JIT-kompilerare. Detta för att försvåra exploitering.
iMessage kryptering
Apple avänder sig av DJB:s Curve25519 (ECDH) samt RSA och AES en hel del, exempelvis för iMessage-kryptering:
When a user turns on iMessage, the device generates two pairs of keys for use with the service: an RSA 1280-bit key for encryption and an ECDSA 256-bit key for signing.
AirPlay kryptering
Även hur AirPlay använder kryptering beskrivs:
AirPlay audio and video streams utilize the MFi-SAP (Secure Association Protocol), which encrypts communication between the accessory and device using ECDH key exchange (Curve25519) with 2048-bit RSA keys and AES-128 in CTR mode
AirDrop kryptering
När en användare slår på AirDrop så skapas en 2048-bit RSA-nyckel som sedan används för TLS-kommunikation över Bluetooth Low-Energy (BTLE) eller WiFi. Ingen accesspunkt eller Internetanslutning behövs för att använda AirDrop. Verifiering av vem som skickar genomförs genom kontroll mot kontaktlistan ”Contacts Only”.
Page 3 Introduction
Page 4 System Security
Secure Boot Chain
System Software Authorization
Secure Enclave
Touch ID
Page 8 Encryption and Data Protection
Hardware Security Features
File Data Protection
Passcodes
Data Protection Classes
Keychain Data Protection
Keybags
FIPS 140-2
Page 14 App Security
App Code Signing
Runtime Process Security
Data Protection in Apps
Accessories
Page 17 Network Security
SSL, TLS
VPN
Wi-Fi
Bluetooth
Single Sign-on
AirDrop Security
Page 20 Internet Services
iMessage
FaceTime
Siri
iCloud
iCloud Keychain
Page 27 Device Controls
Passcode Protection
Configuration Enforcement
Mobile Device Management (MDM)
Apple Configurator
Device Restrictions
Supervised Only Restrictions
Remote Wipe