Molntjänster och FISA 702

Daniel Melin som till vardags jobbar på Skatteverket har skrivit ett intressant inlägg på sin privata LinkedIn-sida där han går igenom amerikanska underrättelselagen FISA och speciellt FISA 702 och hur denna påverkar svenska medborgare. Kortfattat kan man säga att personuppgifter som behandlas av amerikanska företag i Sverige kan läsas av amerikansk underrättelsetjänst.

Jag har med tillstånd av Daniel återpublicerat texten här nedan:

En kommentarstråd till en Linkedin-post av Microsoft fick mig att på nytt börja fundera över FISA 702. Vad innebär FISA 702 egentligen? Hur långt sträcker den sig? Vad innebär avtalsvillkoren från de amerikanska leverantörerna i förhållande till FISA 702?

Eftersom det var Microsoft som var i ursprungligt fokus utgår jag från deras avtal och information, men genomgången har inte specifikt med Microsoft att göra, jag bara använder dem som exempel för att det ska bli enklare att förstå.

Kommentera gärna om jag missat eller missuppfattat något. Jag har skrivit efter bästa förmåga, men ämnet är svårt och ursprungstexterna är inte helt lättlästa.

När används FISA 702?

FISA 702 tillåter att den amerikanska regeringens chefsjurist (Attorney General) tillsammans med den nationella underrättelsechefen (Director of National Intelligence) godkänner inhämtning av information om (1) icke-amerikaner, (2) som sannolikt inte befinner sig i USA, samt (3) för att inhämta underrättelseinformation om andra länder.

Alltså omfattas allt som har med Sverige och svenska medborgare att göra av FISA 702.

Vad anges i lagtexten?

lagtexten till FISA 702 står det:

Notwithstanding any other law, the President, through the Attorney General, may authorize electronic surveillance without a court order under this subchapter to acquire foreign intelligence information for periods of up to one year if the Attorney General certifies in writing under oath that the electronic surveillance is solely directed at the acquisition of the contents of communications transmitted by means of communications used exclusively between or among foreign powers, as defined in section 1801(a) (1), (2), or (3) of this title.

An electronic surveillance authorized by this subsection may be conducted only in accordance with the Attorney General’s certification and the minimization procedures adopted by him.

With respect to electronic surveillance authorized by this subsection, the Attorney General may direct a specified communication common carrier to:

(A)furnish all information, facilities, or technical assistance necessary to accomplish the electronic surveillance in such a manner as will protect its secrecy and produce a minimum of interference with the services that such carrier is providing its customers; and

(B)maintain under security procedures approved by the Attorney General and the Director of National Intelligence any records concerning the surveillance or the aid furnished which such carrier wishes to retain.

Alltså, utan domstolsbeslut kan NSA inhämta underrättelseinformation om andra länder via en kommunikationsleverantör utan att röja att inhämtning pågår. Inhämtad information kan därefter lagras på obestämd tid.

Vad anges i FISA Amendments Act of 2008 Section 702?

FISA Amendments Act of 2008 Section 702 går det bland annat att läsa:

One of the primary purposes in enacting the FAA was the creation of a new way for the US Government to compel providers of electronic communications services to assist the Government in acquiring foreign intelligence information concerning non-US persons located outside the United States.

Certification 2008-A: Targeting Directed at Foreign Governments and Similar Entities

This collection will be accomplished by a variety of means at switches and other parts of the infrastructure of companies that provide electronic communications services to people abroad from within the United States.

The collection will seek to acquire foreign intelligence information concerning foreign governments, factions thereof and similar types of entities, and also states that a list of the entities that will be targeted is included as “Exhibit F” (Sverige är ett utpekat land i Exhibit F)

NSA may disseminate to CIA unevaluated data that comes from collection pursuant to this certification and that CIA requests in order to carry out its clandestine espionage and counterintelligence activities abroad.

NSA may also disseminate to FBI, at FBI’s request, unevaluated data that comes from collection pursuant to this certification.

Alltså, kommunikationsleverantörer ska hjälpa NSA att inhämta underrättelseinformation om t.ex. Sverige. Denna information kan sen delas med CIA och FBI.

Vad står i ett typiskt avtal med en amerikansk molntjänstleverantör?

Av Microsoft Onlinetjänster Dataskyddstillägg daterad 21 juli 2020 framgår:

Microsoft lämnar inte ut eller ger åtkomst till Behandlade data, utom enligt följande: (1) På Kundens instruktioner. (2) Enligt beskrivning i detta DPA. (3) Så som krävs enligt lag. I detta avsnitt avses med ”Behandlade data” följande: (a) Kunddata. (b) Personuppgifter. (c) Andra data som behandlas av Microsoft i samband med den onlinetjänst som är Kundens konfidentiella information enligt volymlicensieringsavtalet.

FISA 702 är en lag och omfattas således av (3).

Microsoft ska inte lämna ut eller ge åtkomst till Behandlade data till rättsvårdande myndighet såvida inte detta krävs enligt lag. Om rättsvårdande myndighet skulle kontakta Microsoft med en begäran om behandlade data ska Microsoft försöka hänvisa den rättsvårdande myndigheten till att begära dessa data direkt från Kunden. Om Microsoft är tvungna att lämna ut eller ge åtkomst till Behandlade data till rättsvårdande myndighet ska Microsoft omgående meddela Kunden och tillhandahålla en kopia av begäran, såvida inte Microsoft är förhindrade enligt lag att göra så.

NSA är såvitt jag vet inte en rättsvårdande myndighet i USA, utan en underrättelsemyndighet. Hela stycket synes endast hantera situationen med FBI och CLOUD Act.

Vid mottagande av tredje mans begäran om behandlade data ska Microsoft omgående meddela kunden, såvida inte detta är förbjudet enligt lag. Microsoft ska avvisa begäran utom då uppfyllelse krävs enligt lag. Om begäran är giltig ska Microsoft försöka hänvisa tredje man direkt till Kunden med sin begäran om data.

Begäran enligt FISA 702 är enligt lagtexten belagd med tystnadsplikt varför kund inte kommer informeras av Microsoft.

För mig framstår det tydligt att Microsoft kommer lämna ut kunders information till NSA utan att informera kunderna. Jag noterar även att det inte finns något om att informationens geografiska placering påverkar avtalet varför det förefaller uppenbart att FISA 702 träffar Microsoft som koncern.

Vad skriver Microsoft om kopplingen till FISA?

På Microsofts blogg framgår bland annat:

Q: Do you give the U.S. government direct access to Skype and Outlook.com data flows as suggested by some stories reporting on documents released by Edward Snowden?

A: We’ve been clear about this. We do not provide any government with direct access to emails or instant messages. Full stop. Like all providers of communications services, we are sometimes obligated to comply with lawful demands from governments to turn over content for specific accounts, pursuant to a search warrant or court order.

Detta är förmodligen sant men NSA behöver inte direkt tillgång till meddelanden eller annan data eftersom Microsoft tvingas leta upp data och därefter överlämna denna data till NSA.

Notera även att svaret endast hanterar de situationer när det finns ett domstolsbeslut. FISA 702 bygger enligt lagtexten inte på domstolsbeslut.

Q: How does Microsoft define a FISA order seeking disclosure of content?

A: This category would include any FISA electronic surveillance orders (50 U.S.C. § 1805), FISA search warrants (50 U.S.C. § 1824), and FISA Amendments Act directives or orders (50 U.S.C. §1881 et seq.) that were received or active during the reporting period.

Notera frånvaron av FISA 702 (50 U.S.C. §1802)

Q: How does Microsoft define a FISA order requesting disclosure of noncontent?

A: This category would include any FISA business records (50 U.S.C. § 1861), commonly referred to as 215 orders, and FISA pen register and trap and trace orders (50 U.S.C. § 1842) that were received or active during the reporting period.

Notera frånvaron av FISA 702 (50 U.S.C. §1802)

Min slutsats

Jag har i viss mån missbedömt FISA 702 tidigare. Lagstiftningen är extremt långtgående både vad gäller vilken information som kan inhämtas och hur länge information får sparas.

Att EU-domstolen och EDPB går hårt fram gällande personuppgiftsbehandling i USA och hos amerikanska bolag som är kommunikationsleverantörer (t.ex. molntjänstleverantörer) förefaller högst rimligt. En personuppgiftsansvarig i Sverige är faktiskt förhindrad att göra en riskbedömning eftersom det är helt omöjligt att bedöma vilken data som samlas in, för vilket syfte och under vilken tid.

Artikel 28.1 i GDPR och artiklarna 7 och 8 i EU-stadgan kan helt enkelt inte uppfyllas av en amerikansk leverantör.

Ny VMware vCenter RCE

Uppdatering: Här och här finnes mer info.

En ny allvarlig sårbarhet har uppdagats i VMware vCenter som medger Remote Code Execution i standardinstallationen. Sårbarheten har blivit tilldelad CVE-2021-21972 och fått en CVSS-score på 9.8 av of 10, således mycket allvarlig.

Läser vi på om VMwares advisory så står det följande:

The vSphere Client (HTML5) contains a remote code execution vulnerability in a vCenter Server plugin

Den del av vCenter servern som är sårbar hanterar vCenter Server plugin for vRealize Operations (vROps) och är aktiverad standard även om du inte använder just den funktionen.

VMware har släppt en säkerhetspatch och uppgradering till version vCenter Server 6.5 U3n, 6.7 U3l, eller 7.0 U1c snarast är rekommenderat. Observera också att port 443 måste vara exponerad för att sårbarheten ska gå att utnyttja.

Sårbarheten uptäcktes av Mikhail Klyuchnikov på företaget Positive Technologies.

Läs mer hos VMware på följande två länkar:

https://www.vmware.com/security/advisories/VMSA-2021-0002.html

Skärmdump från Twitter:

ProductVersionRunning OnCVE IdentifierCVSSv3SeverityFixed VersionWorkaroundsAdditional Documentation
vCenter Server7.0AnyCVE-2021-219729.8Critical 7.0 U1cKB82374None
vCenter Server6.7AnyCVE-2021-219729.8Critical 6.7 U3lKB82374None
vCenter Server6.5AnyCVE-2021-219729.8Critical 6.5 U3nKB82374None

Test av JARM

JARM är ett relativt nytt blue-teaming verktyg som bl.a. kan användas för att skapa fingerprints av Command and Control-servrar (C&C). Verktyget är skapat av ett team där John Althouse ingår som också är en av grundarna till JA3/JA3s och HASSH.

Jarm används för att skapa ett unikt fingeravtryck (fingerprint) av en specifik TLS-kapabel server såsom Apache, Nginx, Cobalt Strike eller Metasploit.

Genom att skicka 10 st olika ClientHello TLS-meddelanden så skapas denna unika fingerprint.

Kör man jarm.py mot exempelvis Metasploit så får man följande fingerprint:

07d14d16d21d21d07c42d43d000000f50d155305214cf247147c43c0f1a823

Skärmdump när jag kör jarm mot en metasploit-lyssnare som använder sig av reverse_https-payloaden:

För fler signaturer se följande Github-repo: https://github.com/cedowens/C2-JARM och givetvis så stödjer Shodan jarm-fingerprints sedan November 2020:

Ett tips är att testa att kombinera jarm med Rita och aktivt skicka ut probes till de anslutningar som ser suspekta ut. Den fingerprint som jarm beräknar är på 62 tecken och är en form av hybrid fuzzy hash. Observera att jarm ej bryr sig om x509-certifikatinformation.

Även bra att notera att om man ställer sin C2-server såsom Cobalt Strike eller Metasploit bakom Nginx så kommer då Nginx-hashen att vara den som fingerprintas.

Jarm finns att laddas hem här:

Homomorfisk kryptering

Homomorfisk kryptering

För oss som gillar homomorfisk kryptering (HE) så börjar det nu dyka upp användningsområden lite här och var. Kortfattat kan man säga att homomorfisk kryptering medger att du kan göra beräkningar på krypterad information. Något som kan vara mycket användbart när molntjänster nyttjas och du inte vill dela med dig av information till molnleverantören.

Microsoft är en leverantör som nu använder homomorfisk kryptering i dess mjukvara Edge för att kontrollera läckta lösenord, detta gör man via algoritmen Oblivious Pseudo-Random Function (OPRF). Tidigare har bl.a. Haveibeenpwned använt k-anonymity för att kontrollera lösenord mot läckta listor.

När vi ändå är inne på k-anonymitet så är det värt att nämna att det finns vissa problem och en beskrivning av Googles implementation hittar du här.

Vad som också är intressant är att Microsoft har släppt biblioteket för att göra detta som open-source och under MIT-licens. Biblioteket heter Microsoft SEAL och går att ladda hem här.

Bild som beskriver Microsofts Password Monitor Service och dess användning av OPRF:

Säkerhetsbrist i sudo

sudo

En ny säkerhetsbrist har identifierats i mjukvaran sudo. Sudo som installeras som standard i många operativsystem är som standard setuid root. Det innebär att eventuella brister kan leda till att lokala användare kan erhålla root-behörigheter.

Med åren har också sudo blivit större och fler funktioner har tillkommit. Detta har bl.a. lett till att OpenBSD nu har ett alternativ som heter doas.

Igår så rapporterade det amerikanska säkerhetsföretaget Qualys att de identifierat en sårbarhet i sudo (CVE-2021-3156). Sårbarheten medger att en lokal användare kan utnyttja en heap-sårbarhet och således bli root. Buggen har funnits sedan 2011 och återfinnes i standardkonfigurationen. Att det just finns med i standardkonfigurationen är viktigt att poängtera eftersom många sårbarheter som uppdagats i sudo kräver speciella konfigurationer.

Sårbarheten återfinnes i funktionen set_cmnd() och kan enklast triggas enklast genom att använda sudoedit och följande kommando:

sudoedit -s '\' `perl -e 'print "A" x 65536'` 

Och är du sårbar så får du en segfault. Observera att du behöver lokalt konto men inte medlem i sudoers eller motsvarande. Samt att alla installationer inte har sudoedit, såsom macOS.

Video från Qualys som förevisar sårbarheten:

Om du som jag undrar lite över sudos logotyp, så se XKCD här.

Nordkorea angriper säkerhetsforskare

Googles grupp för avancerad säkerhetsforskning som går under namnet Threat Analysis Group (TAG) har precis släppt en nyhet gällande att fiktiva cybersäkerhetsforskare som angriper andra cybersäkerhetsforskare.

Kopplingar kan göras till Lazarus-grupperingen som har anslutningar till Nordkorea, visar bl.a på analys som Kaspersky och Google har genomfört.

Första delen av attacken använder sig av social engineering och ett antal olika kanaler såsom Twitter, Keybase, LinkedIn, Discord och Telegram. En initial kontakt tas med målet där en fråga ställs om denne vill samarbeta gällande undersökning/utveckling av en ny sårbarhet. Då skickas sedan ett Visual Studio-projekt som innehåller en DLL med bakdörr samt kod som exekveras när projektet byggs (<PreBuildEvent>).

Enligt uppgift från Google så utnyttjas även en 0-dagars sårbarhet i Windows 10 och Chrome om besökaren går till bloggen blog.br0vvnn[.]io. Även denna blogg länkas vidare i chattarna på ovan sociala medier. Google har dock inte identifierat vilken sårbarhet som utnyttjas, men sägs vara CVE-2020-15994 som är en use-after-free i V8.

Jag tycker dock det låter konstigt att bränna 0-dagars för att angripa andra säkerhetsforskare, men kanske uppsidan är större. Och just moduset att angripa andra säkerhetspersoner har hänt många gånger förr, speciellt att exploits innehåller bakdörrar.

En av de som kontaktats är bl.a svenska Joel Eriksson:

Även så skriver Richard Johnson följande på Twitter:

”Update: I’ve recovered and decrypted registry keys holding config and neutered the service, I’m RE’ing the driver. I have confirmed with colleagues that only visiting the blog was enough to get popped via Chrome/Brave. I’ve confirmed my machine connected to their C&C many times.”

Twitter-profiler som använts:

Och följande LinkedIn-konton:

  • https://www.linkedin.com/in/billy-brown-a6678b1b8/
  • https://www.linkedin.com/in/guo-zhang-b152721bb/
  • https://www.linkedin.com/in/hyungwoo-lee-6985501b9/
  • https://www.linkedin.com/in/linshuang-li-aa696391bb/
  • https://www.linkedin.com/in/rimmer-trajan-2806b21bb/

För hela listan med IOC:er så se Googles inlägg eller detta blogginlägg.

Följande bild publicerade Dave Aitel på Twitter:

Uppdatering: Här är skärmdumpen från Kaspersky Threat Attribution Engine:

DNSpooq – Ny DNS-attack

DNSpooq är det fiffiga namnet på en ny cache-poisoning attack mot mjukvaran Dnsmasq. Dnsmasq är en liten cachande rekursiv resolver som vanligtvis finnes i olika typer av inbyggda enheter såsom mobiltelefoner, Cisco-enheter, brandväggar, Ubiquiti-produkter för att nämna några av de 40 olika tillverkarna som skeppar med dnsmasq. Företaget som ligger bakom attacken har räknat ut att det finns ungefär 1 miljon sårbara enheter som är direkt kopplade till internet och troligtvis många fler som inte går att nå från internet.

DNSpooq består av flertalet olika sårbarheter som identifierats och ser ut enligt följande:

Och kan sammanfattas med följande citat:

The vulnerabilities all reduce the entropy of identiers TXID (Transaction ID) and source port and their combination, which should consist of 32 non-predictable bits in total, according to [8]. The vulnerabilities need to be combined in order to produce a feasible attack.

En dnsspoof-attack kan visas på följande sätt:

Förutom cachespoofnings-attackerna som identifierats har även fyra buffer-overflow sårbarheter identifierats i hanteringen av DNSSEC i dnsmasq.

Alla versioner av dnsmasq före 2.83 är sårbara för dessa attacker. Och denna version släpps idag den 19:de Januari.

Rapporten från JSOF går att ladda hem som PDF här.

Listan med CVE:er är följande:

  • CVE-2020-25681: A heap-based buffer overflow in dnsmasq in the way it sorts RRSets before validating them with DNSSEC data in an unsolicited DNS response
  • CVE-2020-25682: A buffer overflow vulnerability in the way dnsmasq extract names from DNS packets before validating them with DNSSEC data
  • CVE-2020-25683: A heap-based buffer overflow in get_rdata subroutine of dnsmasq, when DNSSEC is enabled and before it validates the received DNS entries
  • CVE-2020-25687: A heap-based buffer overflow in sort_rrset subroutine of dnsmasq, when DNSSEC is enabled and before it validates the received DNS entries
  • CVE-2020-25684: Dnsmasq does not validate the combination of address/port and the query-id fields of DNS request when accepting DNS responses
  • CVE-2020-25685: Dnsmasq uses a weak hashing algorithm (CRC32) when compiled without DNSSEC to validate DNS responses
  • CVE-2020-25686: Dnsmasq does not check for an existing pending request for the same name and forwards a new request thus allowing an attacker to perform a ”Birthday Attack” scenario to forge replies and potentially poison the DNS cache

Ubiquiti hackade

Igår fick jag ett mail om att amerikanska företaget Ubiquiti har blivit hackade. Ubiquiti är bl.a. en av världens största tillverkare av bas-enheter för WiFi-kommunikation. Mailet innehåller relativt lite information eftersom att företaget uppger att de inte känner till omfattningen ännu.

Även om det var länge sedan jag själv använde Ubiquitis molntjänst så antar jag att det är fullt möjligt att erhålla access till det lokala nätverket via Ubiquitis centrala tjänst, därav är detta extra allvarligt. Även kan jag tänka mig att DNS kan omkonfigureras, firmware kan ändras osv.

Det som framgår i mailet är att användarnamn, hashat lösenord, adress och telefonnummer kan ha läckt. Samt framgår det även att det rör sig om en tredjepartsleverantör där läckan ska ha skett.

Utskicket har även bekräftats av Ubiquiti själva, se forumtråd här (via Säkerhetsbubblan). Utskicket gick via Mailchimp och använde bl.a. tracking-länkar, vilket gjorde att det var initialt svårt att avgöra äktheten i mailet.

Statligt sponsrade cyberattacker

Nu finns den andra live-inspelningen på YouTube, Facebook och LinkedIn. Denna gång pratar jag med Christoffer Strömblad som driver cstromblad.com. Vi pratade nästan en timme om statliga cyberattacker, deras förmågor och konsekvenserna av statligt sponsrade cyberattacker:

Den tidigare live-inspelningen med Christian på Cybix om CTF:er (Capture The Flag) finns att beskåda här.

Så gick intrånget mot FireEye till

Uppdaterat 2020-12-15: SolarWinds har i sin 8-K anmälan till US Securities and Exchange Commission angett följande: ”SolarWinds currently believes the actual number of customers that may have had an installation of the Orion products that contained this vulnerability to be fewer than 18,000”. Detta kan betyda att 18000 installationer har genomförts med bakdörren.

Uppdatering 2020-12-16: Bra analys av bakdörren av Qeeqbox.

Uppdatering 2020-12-17: Jag glömde i en tidigare version av detta blogginlägg att länka till källan som bekräftar att det är via SolarWinds som angriparna tog sig in hos FireEye, den källan återfinner du här.

Sent igårkväll så släpptes information om hur FireEye hackades via en så kallad supply-chain attack. Allt tyder på att intrånget genomfördes av APT29, Cozy Bear som är en grupp som kopplas mot ryska staten samt att en mjukvara från SolarWinds användes som intrångsvektor. Förutom FireEye så kunde även APT29 läsa mail under några månader på amerikanska myndigheten U.S. Treasury and Commerce.

APT29 placerade en bakdörr i SolarWinds mjukvara Orion som används för nätverksövervakning någon gång under mars-juni 2020. Den mjukvaran kommunicerade hem till SolarWinds som vanligt men kunde även fjärrstyra datorn som hade bakdörren installerad. Troligtvis genomförds intrånget mot SolarWinds genom deras byggsystem eftersom bakdörren också var signerad med SolarWinds certifikat.

Bland SolarWinds kunder kan man hitta en intressant lista med organisationer:

Bland kunder listas Volvo, Ericsson och Telenor. Oklart om det är just Orion som används av dessa kunder eftersom SolarWinds är ett stort företag med många produkter.

Bakdörren återfanns i filen SolarWinds.Orion.Core.BusinessLayer.dll. Och bl.a. Microsoft Defender kan upptäcka denna bakdörr som Solorigate. Andra namn för bakdörren är även SUNBURST samt operation UNC2452.

Att bakdörren var oupptäckt enbart under några månader beror troligtvis på att angriparna blev giriga och ville komma åt mer information i fler system. När spåren började att nystas upp så pekade de på SolarWinds produkt Orion och att ge sig på FireEye som är specialister på att göra IT-forensiska utredningar är troligtvis en bidragande faktor till att bakdörren inte blev så långlivad.

Intressant i denna historia är också att lokala VPS-anslutningar (virtuella privata servrar) inom landet användes för att inte väcka misstanke mot trafik som går utom landet. Även framhäver FireEye följande som också är intressant:

After a dormant period of up to two weeks, the malware will attempt to resolve a subdomain of avsvmcloud[.]com. The DNS response will return a CNAME record that points to a Command and Control (C2) domain. The C2 traffic to the malicious domains is designed to mimic normal SolarWinds API communications

Kontrollera alltså dina PCAP-filer eller brandväggsloggar efter DNS-uppslag mot avsvmcloud[.]com, förslagsvis under hela 2020. Här är ett exempel när jag söker efter denna information i Moloch (numera Arkime):

Bakdörren finns uppladdad på VX Underground här och läs även på om reproducerbara byggen som jag skrev om 2017, vilket är en av flera metoder för att försvåra denna typ av attack.

IOC:er

  • b91ce2fa41029f6955bff20079468448
  • 02af7cec58b9a5da1c542b5a32151ba1
  • avsvmcloud[.]com

Se även FireEyes Yara-regler på Github här samt länken i början av detta blogginlägg.