Taggat med: rsa

Ny sårbarhet i IPSec

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 GrotheJoerg Schwenk och Dennis 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 – Return of Bleichenbacher’s Oracle Attack

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:

F5 BIG-IP SSL vulnerability CVE-2017-6168
Citrix TLS Padding Oracle Vulnerability in Citrix NetScaler Application Delivery Controller (ADC) and NetScaler Gateway CVE-2017-17382
Radware Security Advisory: Adaptive chosen-ciphertext attack vulnerability CVE-2017-17427
Cisco ACE Bleichenbacher Attack on TLS Affecting Cisco ProductsEnd-of-Sale and End-of-Life CVE-2017-17428
Bouncy Castle Fix in 1.59 beta 9Patch / Commit CVE-2017-13098
Erlang OTP 18.3.4.7,
OTP 19.3.6.4,
OTP 20.1.7
CVE-2017-1000385
WolfSSL Github PR / patch CVE-2017-13099
MatrixSSL Changes in 3.8.3 CVE-2016-6883
Java / JSSE Oracle Critical Patch Update Advisory – October 2012 CVE-2012-5081

En lösning till problemet är att helt sluta använda RSA och förlita sig på elliptiska kurvor samt Diffie-Hellman.

Robot-attacken är resultat av forskning från Hanno Böck, Juraj Somorovsky från Horst Görtz Institute och Craig Young, Tripwire.

Och för att testa om en sajt är sårbar för Robot kan du använda RobotAttack.org, dev.testssl.com eller testssl.sh

Skärmdump från dev.ssllabs.com där jag identifierat en sårbar sajt:

ROCA: Ny attack mot RSA 1024 samt 2048-bitar

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.

Mer information nedan om CVE-2017-15361:

Källa: https://crocs.fi.muni.cz/public/papers/rsa_ccs17

Nyheterna i Transport Layer Security version 1.3 (TLS 1.3)

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:

  • RSA är borttaget – RSA tillhandahåller inte Forward Secrecy
  • Svaga Diffie-Hellman grupper kan inte användas (SSL_OP_SINGLE_DH_USE)
  • CBC är borta – Är orsaken till attacker såsom Lucky13 och BEAST
  • RC4 samt SHA1 får inte längre användas
  • Export-algoritmer (ansvarig för attacker såsom FREAK, LogJam etc)
  • Nytt är ChaCha-Poly1305 samt stöd för OCB-modes (tipstack till Joachim Strömbergson)
  • Algoritmen för RSA-padding är Probablilistic Signature Scheme (PSS)
  • 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:

  1. Skriv in ”chrome://flags/” i adressbaren och trycker enter
  2. Gå till ”Maximum TLS version enabled.” och välj ”TLS 1.3”
  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.

Granskning av IT-säkerheten på Dagens Nyheters (DN) tipssajt

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:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPGP.js v1.3.0
Comment: http://openpgpjs.org

xo0EViaQEAEEAKGUFnG9PCA3tWCcj2+e6GgRzTSY7hbN5YYurJbNeHsE4SbT
UPHQzGKQsqcyYieIS9Uh/co42E1ndgG4xZSjRZslMWRkTQVCEGTCMPzm0sSE
P8zGndzF/R//FK4AvshSUBa8sLWTp026C2xqAhIvUOvKwRBK9PKclfKZVV/5
zG8zABEBAAHNMktyaXN0b2ZmZXIgw5Zyc3RhZGl1cyA8a3Jpc3RvZmZlci5v
cnN0YWRpdXNAZG4uc2U+wrIEEAEIACYFAlYmkBAGCwkIBwMCCRBMNmcxb9M1
+QQVCAIKAxYCAQIbAwIeAQAAOH0D/1RUQSjmYhkUoGkwLp5HF7Xl6UDYQpoX
8Xdhjb5Aufu/nUgs73nXS2MlycqHqoKGV0a43PzteujQz9gz86nIHrdB7F7l
jLlssUSzD2oePObv4wpK9lBee9HZs980+LWkK3t3yUe6+mixsspZvEAGe/Q0
k50JgxMHFcfj5uCTm3fTzo0EViaQEAEEALCZMwq4sfm59Hq5Z4hOv8pdPtMX
jy26WZBBaZ8csv54UWm7o7Xt2TRkU1eGR6j/UjAXVNZ6jKON10M8I+1nmlpx
ZtS3I9QRja7N0HOn/Mo9et5bHdZKQSHUd1vblRRddHOqU+C4EP+BAKqtR/Ne
y6RxOCaydspT+wJzWCS8dfarABEBAAHCnwQYAQgAEwUCViaQEAkQTDZnMW/T
NfkCGwwAAM/nA/9Ra0Mnr2cIOOFXN/TAeLK0JKG9s/hIa01zGMC9dDub5Q1r
zAiVO/c664MYvtbOOMOf5VeHRPBiVFuxw3Fl4MzX0g61bcHBTMKaT6iF+13l
3zONpw81eAh1fjN8PX4gcwrU6W+N4BTSBHO+3dMWNF9rlK/xGfqLzvXAo+zL
OCbglg==
=Bf3n
-----END PGP PUBLIC KEY BLOCK-----

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.

SecureDrop över Tor som The New York Times använder sig av

Uppdatering: Burp Suites passiva granskning rapporterar 11 st medium-brister och 42 st low:

NSA varnar för kvantdatorer

NSA Kvantdatorer

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

– Dr. Krysta Svore, Microsoft Research

Uppdatering: Obs Curve25519 hjälper inte mot beräkningar utförda av en kvantdator.

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

Faktorisera 512 bitar RSA SSL/TLS

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:

  1. När klienten skickar sitt Hello-meddelande så frågar den efter standard RSA
  2. Angripare som sitter i mitten (MITM) ändrar detta svar till export RSA
  3. Servern svarar med sin 512-bitars export RSA-nyckel, signerad med sin nyckel för långa livslängder (long term key).
  4. Klienten sväljer detta svar på grund av OpenSSL/SecureTransport-buggen.
  5. Angriparen faktoriserar RSA för att hitta den privata nyckeln
  6. När klienter krypterar ’pre-master secret’ till servern så kan nu angriparen dekryptera TLS huvudhemlighet (master secret)
  7. Nu kan angriparen se klartext och injicera nytt innehåll

Demonstration av hur attacken kan nyttjas mot NSA (eller rättare skrivet, Akamai):

nsa-fake copy

Allvarlig sårbarhet i Microsoft Schannel

microsoftIgå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.

  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256

Läs mer här:  technet.microsoft.com/library/security/ms14-066

Kryptering i Apple iOS: iMessage, AirPlay och AirDrop

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”.

iOS Security

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

Dokumentet kan du ladda hem här: