Nya filer från Equation Group (EQGRP) släppta

NSA EQGRP

För några timmar sedan så släpptes krypteringsnyckeln till filen eqgrp-auction-file.tar.xz. Denna fil har tidigare legat ute för auktion för den som vill vara med i en budgivning. Filen uppges att innehålla verktyg från amerikanska myndigheten NSA:s hacking-grupp TAO, Tailored Access Operations.

Någon har även lagt upp hela arkivet med verktyg som totalt innehåller 5396 filer på Github här: https://github.com/x0rz/EQGRP

Fördelning över progamspråk som verktygen är skrivna i domineras av Perl:

Vi uppdaterar löpande med information gällande innehållet i arkivet.

Skärmdump på några av de exploits som förekommer och går mot Samba samt RPC dmispd:

Så identifieras Cloud Hopper APT10

Uppdatering: Min pull-request till Loki-projektets signaturdatabas har nu gått igenom och det enda du behöver göra är att ladda hem och köra Loki för att detektera APT10.

Myndigheten för samhällsskydd och beredskap (MSB) gick i förrgår ut och varnade för omfattande cyberattacker mot bl.a. Svenska managed service providers. Attacken är riktad mot företag som sköter drift och IT-infrastruktur för samhällssektorer som offentlig verksamhet, IT, kommunikation, sjukvård, energi och forskning.

Cyberattacken går under namnet APT10 eller Cloud Hopper och MSB meddelar att attacken har inriktat sig på att infektera system genom att lura människor. De som ligger bakom angreppen har lagt stora resurser på att kartlägga sina mål, organisationer och deras anställda, för att kunna skicka riktade e-postmeddelanden med trovärdiga dokument (så kallat riktat nätfiske, spearphishing).

Jag har tittat på de IOC:er (Indicators of Compromise) som är släppta av företaget PwC och skapat två filer som kan läsas in av en mängd olika verktyg såsom Loki (som jag använde för att identifiera Project Sauron/Remsec sist), för tyvärr så är PwC:s PDF inte helt lättarbetad.

Du kan därför ladda hem och ändra den Yara-fil samt en fil med Md5-checksummor som jag skapat på Github här: https://github.com/jonaslejon/apt10 och använda den direkt med Loki. Du använder filerna genom att lägga filen apt_apt10.yar i underkatalogen signature-base/yara/ och innehållet från hash-iocs.txt längst ner i den befintliga filen signature-base/iocs/hash-iocs.txt. Detta efter du laddat hem Loki här

Jag har även kört sökningar mot VirusTotal med de checksummor som PwC har släppt och tittat på ett antal olika saker såsom när antivirus-företagen identifierade APT10:

Här följer en skärmdump på en träff när jag använder Loki och MD5-filen samt Yara-filen från mitt Github-repo för test:

Och om jag tittar på statistik från VirusTotal gällande APT10 så är antivirus-mjukvaran McAfee bäst på att detektera APT10. Fortfarande identifieras 69 av 300 delar inte av någon antivirus-mjukvara.

Följande tabell visar på antalet detektioner per antivirus-produkt:

205 McAfee
205 GData
204 McAfee-GW-Edition
203 Symantec
198 Kaspersky
197 BitDefender
196 Emsisoft
195 F-Secure
192 MicroWorld-eScan
191 Panda
190 VIPRE
188 Ikarus
183 Fortinet
181 Sophos
181 Ad-Aware
181 AVG
170 ESET-NOD32
167 NANO-Antivirus
159 TrendMicro-HouseCall
159 AVware

Och tittar vi vidare på några av de exploits som används så har antivirus-företagen klassat dem som följande:

  • CVE-2012-0158
  • CVE-2010-3333
  • Exploit.OLE2.Toolbar
  • JS.S.Exploit.121732
  • JS.S.Exploit.166944
  • Exploit.Win32.OLE.78
  • EXP/Office.Exploit.Gen
  • DOC.S.Exploit.164492[h]
  • Exploit-MSWord!1ECBFF1A46A8

Och några ovan är relativt lätta att utläsa såsom CVE-2012-0158 som är en sårbarhet i Active X och CVE-2010-3333 är en sårbarhet i Microsoft Offices hantering av RTF-formatet.

Om du vill hjälpa till så får du gärna göra pull request på Github-repot med mer IOC-data från DHS.

Loki tittar främst på klienter och servrar och därför rekommenderar jag även att titta på nätverkstrafik såsom DNS-uppslagningar, för du har väl sparat undan nätverksdata i PCAP-format?

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.

Nyupptäckt sårbarhet i IIS 6.0

Mer än 8 miljoner webbplatser kan vara sårbar för en nyligen identifierad säkerhetsbrist i Internet Information Services (IIS) 6.0. Sårbarheten har utnyttjats på Internet sedan Juli 2016 och identifierades ”in the wild”.

Den sårbara funktionen heter ScStoragePathFromUrl och är en del av WebDAV:

Microsoft Windows Server 2003 R2 allows remote attackers to execute arbitrary code via a long header beginning with ”If: <http://” in a PROPFIND request

Säkerhetsbuggen identifierades av Zhiniang Peng samt Chen Wu vid South China University of Technology Guangzhou, Kina.

Enligt tjänsten BuiltWith så IIS används IIS på 13.8% av alla webbsajter samt IIS 6.0 versionen på 2.3% av alla webbsajter vilket motsvarar cirka 8.3 miljoner sajter.

Behöver Er organisation hjälp med cybersäkerhet? Kontakta Triop AB >

På Github så kan du hitta följande exploit som demonstrerar sårbarheten genom att starta upp kalkylatorn i Windows, calc.exe:

https://raw.githubusercontent.com/edwardz246003/IIS_exploit/master/exploit.py

Givetvis ska inte IIS 6.0 användas då detta är en mycket gammal version, men troligtvis så kan det hjälpa att stänga av WebDAV för att förhindra att sårbarheten utnyttjas.

Och här finnes en Snort-signatur (källa):

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"WEB-MISC IIS v6
WebDAV ScStoragePathFromUrl overflow attempt"; flow:to_server,established;
content:"PROPFIND"; nocase; http_method; content:"|0a|If|3a|"; nocase;
http_raw_header; isdataat:1000,relative; content:!"|0A|"; http_raw_header;
within:1000; reference:cve,2017-7269; reference:url,github.com/
edwardz246003/IIS_exploit;
classtype:web-application-attack; sid:1; rev:1;)

 

Ett år av obligatorisk it-incidentrapportering

Det har nu gått nästan ett år sedan den 1:a April 2016 då det är obligatoriskt för Sveriges (nästan) samtliga 244 myndigheter att rapportera in it-incidenter till MSB (Myndigheten för samhällsskydd och beredskap).

MSB rapporterar att det skickats in 214 incidentrapporter från 77 myndigheter och att snittet legat på 25 st per månad. Detta innebär att många myndigheter fortfarande inte skickat in en enda incidentrapport, vilket påvisar ett stort mörkertal. Men troligtvis så tar det några år innan myndigheter anpassar sig.

En annan intressant sak är att incidenter ska rapporteras inom 24h att de upptäckts men i verkligheten ser det annorlunda ut:

Vid genomgång av rapporterna visar det sig att runt 20 procent av incidenterna rapporterats mer än fem dagar efter att de upptäckts, vissa incidenter har rapporterats först efter en månad.

De incidenter som rapporteras in kategoriseras på följande sätt och antal:

Rapporten har även bilaga med sekretessbelagda uppgifter och där framgår vissa särskilda företeelser avseende it-incidentrapporteringen.

För inrapporteringen så används filkryptot KURIR 2.0.

Att loggning är viktigt är något som jag inte understryka nog och detta framkommer även i incidentrapporteringen:

I ett antal incidenter har det framkommit att myndigheter inte har någon dedikerad loggserver, något som är en viktig komponent för att kunna upprätthålla en fungerande övervakning av it-system och för att i efterhand ha möjlighet att klargöra vad som hänt i systemet.

Jag kan även utläsa att MSB använder ordet kryptotrojan återkommande gånger, vilket jag tycker är felaktigt. Utpressningsvirus eller ransomware tycker jag är mer rättvisande och något som Polisen etc använder. Och på tal om ransomware så anger rapporten att 40% av inkomna rapporter om ransomware har lett till informationsförlust. Tyvärr framgår det inte vilken typ av ransomware det rör sig om eller om antivirus-mjukvara detekterat dessa.

Här kan du läsa MSB:s årsrapport om it-incidentrapportering 2016 i sin helhet (PDF):

MSB Årsrapport IT-incidentrapportering

Allvarlig sårbarhet i Cisco Cluster Management Protocol

Cisco har via CIA Vault7-läckan identifierat en allvarlig sårbarhet i Cisco Cluster Management Protocol (CMP). Denna sårbarhet gör att en angripare kan fjärrmässigt tillförskaffa sig administrativa rättigheter på en Cisco-enhet.

Denna sårbarhet utnyttjas genom att en angripare skickar telnet-kommandon innehållandes specifika CMP-options (så kallade telnet option codes).

För att sårbarheten ska gå att utnyttja måste följande två förutsättningar vara uppfyllda:

  • CMP subsystem is present on the Cisco IOS XE software image running on the device, and
  • The device is configured to accept incoming Telnet connections.

Och för att se om just din enhet stödjer CMP kan du skriva kommandot: show subsys class protocol | include ^cmp

Cisco skriver på sin hemsida:

This vulnerability was found during the analysis of documents related to the Vault 7 disclosure

För att se hela listan med enheter som kan vara sårbara se Cisco.com

Tails 2.11 och Tor Browser 6.5.1 ute nu

Sex allvarliga säkerhetsbrister har uppdagats i Firefox vilket även resulterat till att Tor och Tails nu finns ute i nya versioner.

Tails-teamet meddelar även att detta kommer att bli den sista versionen då I2P finns med. Att stödet för anonymiseringsnätverket I2P tas bort från och med nästa version beror på prioriteringar.

Tails åtgärdar förutom Firefox-sårbarheterna även CVE-2017-6074 (local root privilege escalation) genom att stänga av dccp-modulen.

Även så finns det åtgärder för att försvåra fingerprinting via chrome:// och resource:// URL:er men tyvärr så verkar det som om mitt fingerprint-demo fungerar fortfarande:

Google släpper E2EMail

Google har länge satsat på olika lösningar för End-to-end kryptering. Flertalet av dessa bygger på Googles JavaScript-biblioteket med namnet End-to-end och återfinnes på Github.

E2EMail har utvecklats som ett Chrome-plugin ovanpå End-to-end och har nu kopplat sina trådar till Google. Detta för att End-to-end ska vara ett community-baserat plugin och inte enbart något som Google handhar, vilket också är bra för säkerheten att fler engagerar sig och utvecklar vidare.

Tyvärr så är PGP inte lätt att använda och det är lätt att göra fel vilket E2EMail hjälper till med. Utvecklingen av E2EMail har pågått under tre års tid och är även tänkt att hjälpa GMail användare att skicka och ta emot krypterad E-post.

Än så länge finns inte E2EMail i Chrome Web Store utan du måste själv clona Github-repot och kompilera koden.

För att installera genomför följande steg:

$ git clone https://github.com/e2email-org/e2email
$ cd e2email
$ ./do.sh setup
$ ./do.sh build

Sedan så ligger det en Chrome-extension under mappen build/e2email som du installerar i Chrome genom att gå in under Settings -> Extensions och slå på Developer Mode. Där väljer du sedan Load unpacked extension och välj den extension du just kompilerade.

CIA Vault7 läcka från Wikileaks

Jag tänkte kommentera gällande den senaste läckan från Wikileaks som inkluderar en stor mängd olika cyber-relaterade verktyg, metoder etc från vad som sägs är CIA.

Läckan ser ut att komma från något inom CIA som heter devlan.net och är troligtvis ett utvecklingsnätverk för cybervapen. Eftersom CIA till skillnad från NSA bedriver HUMINT så kräver majoriteten av verktygen fysisk access till enheten.

Det ser inte ut att finnas några överdrivna referenser till zero-days och generellt håller det som är läckt inte den högsta tekniska förmågan. Läckan innehåller även referenser till skadlig kod som CIA troligtvis installerar och antivirus-företagen är redan på att skriva signaturer för att identifiera CIA:s verktyg.

Viktigt också att tillägga är att om du kan ta dig in på en mobiltelefon genom att utnyttja sårbarheter så kommer du givetvis också åt applikationer såsom WhatsApp och Signal.

Även så finns det referenser till att CIA kan installera verktyg för att avlyssna via en vanlig Samsung Smart-TV. Och även detta kräver troligtvis fysisk access till TV:n innan eller när den införskaffas.

Läckan inträffade under förra året och de läcka filterna troligtvis varit tillgänglig för andra sedan tidigare. Den innehåller 8761 dokument och filer men inte så många binärer annat än ett fåtal exe-filer och python-kod.

Kommentar som återfinnes i läckan:

What did Equation do wrong, and how can we avoid doing the same?

CloudBleed – Allvarligt minnesläckage från CloudFlare

CloudFlare (CF) är numera en vital och central del av internet. CF tillhandahåller CDN (Content Delivery Network), DNS och WAF (Web Application Firewall) för att nämna några funktioner.

För några dagar sedan så kontaktade Tavis Ormandy CF gällande att han sett saker i Googles sökresultat som inte hör hemma där. När sedan CF undersökte så hittade man en parser-bugg som gör att minne från deras servrar kunde skickas ut felaktigt.

Ungefär 0.00003% av samtliga http-förfrågningar som gick genom CF drabbades av denna bugg. Och vid undersökningar i Googles cache så identifierades 700 fall där minne läckt och cachats av Google.

Turligt nog så påverkas inte privata (TLS) SSL-nycklar eftersom viss uppdelning finns mellan processerna i CF:s servrar.

För en mer komplett lista över sajter som ligger hos CF se här:

Uppdatering 1: Nu har CF skickat ut ett mail till samtliga kunder. De skriver bl.a. följande:

”To date, we have yet to find any instance of the bug being exploited, but we recommend if you are concerned that you invalidate and reissue any persistent secrets, such as long lived session identifiers, tokens or keys. Due to the nature of the bug, customer SSL keys were not exposed and do not need to be rotated.”

Uppdatering 2: Svenska betaltjänst-leverantören Mondido samt Kraken har återställt samtliga lösenord. Jag hoppas att fler följer efter som använder CF.

Uppdatering 3: Cloudbleed kan även ha och göra med att Google själva nollställt samtliga inloggningar mot Googles egna tjänster. Så här kommenterar Tavis:

”Hi Tavis, could you tell us why a lot of people had to re-authenticate their Google accounts on their devices all of the sudden? It may not have been related, but Google definitely did something that had us all re-authenticate.”

”I couldn’t tell you, this is not the correct place to ask.”

Uppdatering 4: Har nu laddat hem .se-zonen och kontrollerat hur många som använder CF:s namnservrar vilket ger en fingervisning om hur många .se-domäner som kan potentiellt läckt information:

$ grep cloudflare se.zone |awk ’{print $1}’|sort|uniq|wc -l
7827

Det kan även vara åt andra hållet. Dvs CF:s dyrare abonnemang så kan du köra med en egen namnserver men ändå nyttja CF:s tjänster.