Taggat med: Diffie-Hellman

Nytt intressant malware: FritzFrog

👉 Stöd mitt bloggande via Patreon

FritzFrog Malware

FritzFrog är en ny typ av malware som är skrivet i programspråket Go och riktar sig mot servrar som exponerar SSH.

Den skadliga koden är modulärt uppbyggd och skriver inga filer till disk efter infektion. Det som kanske är mest intressant är att kommunikationen använder sig av ett helt egenutvecklat peer-to-peer protokoll.

Karta över infektioner från företaget Guardicore:

Vid infektion så startas en process vid namn ifconfig och nginx upp. Som lyssnar på TCP port 1234. Den skadliga koden är packad med UPX och efter att processerna startats upp så raderas filer på disk. För att undvika detektion på nätverket så tunnlas kommunikation över port 1234 via SSH. Denna kanal används även för P2P-protokollet som gör nyckelutbyte med hjälp av Diffie Hellman samt kryptering med AES.

Kommandon som kickas via P2P-protokollet:

Även så lägger den skadliga koden en publik nyckel till .ssh/authorized_keys för att ge möjlighet att ta sig in i systemet vid senare tillfälle.

På Github så finns det IOC:er samt kod för att detektera FritzFrog. En av syftet med den skadliga koden är att utvinna kryptovalutan Monero med hjälp av mjukvaran XMRig miner som ansluter mot web.xmrpool.eu över port 5555.

Antalet attacker från nätverket har ökat stadigt sedan början på året:

Intresserad av botnets? Kolla in Guardicores Botnet Encyclopedia.

WEASEL – Ny bakdörr från Facebook

Facebook har släppt ett intressant nytt implantat (bakdörr) vid namn WEASEL. Mjukvaran är skriven i Python3 och utnyttjar DNS samt AAAA-records för att skicka och ta emot beacons. Den behöver inte heller några externa beroenden och kan således köras under de flesta operativsystem.

Ett implantat är en typ av mjukvara som används av angripare för att utföra olika uppgifter och kommunicera in och ut ur nätverk. WEASELs klientdel har inga direkta inbyggda funktioner förutom att sköta kommunikationskanalen, självradering och intervall för kommunikation. Vill du ha mer funktioner så får du själv bygga till det eftersom WEASEL stödjer exekvering (eval) av Python3-kod.

Fokus vid utvecklingen av WEASEL har varit på att försöka försvåra IT-forensiska undersökningar och därför finns ej stöd för persistens. Mjukvaran stödjer inte heller att flertalet operatörer jobbar mot samma instans.

För kryptering av data över DNS så används AES-128 i CTR mode samt Diffie-Hellman för nycklar. Oklart hur stödet för Windows ser ut men går säkert att åstadkomma med Pyinstaller.

Här hittar du WEASEL på Github:

Jag har tyvärr ej testat WEASEL ännu men har det på min todo-lista. Om du gör det eller redan testat så lämna gärna en kommentar om dina erfarenheter.

Bild på vessla av Keven Law – originally posted to Flickr as On the lookout…, CC BY-SA 2.0

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.

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.

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