Taggat med: nsa

Så upptäcker ni bakdörrar i IT-system

Så upptäcker ni bakdörrar i IT-system

Att upptäcka bakdörrar i IT-system är ingen lätt match och en mycket bra utvecklad bakdörr är mer eller mindre omöjlig att upptäcka. En bra utvecklad bakdörr har en mycket liten och snäv målgrupp och ligger vilande större delen av tiden. Men det finns givetvis olika metoder och sätt att upptäcka bakdörrar, för förr eller senare så kan misstag eller avvikande beteenden analyseras och påvisa en bakdörr.

Denna guide är främst skriven för att upptäcka bakdörrar som redan är in-planterade. Och hur bakdörrarna kommer in är utanför denna guide, men för att nämna några sätt:

  • Implanterade från start i servrar eller mjukvara/hårdvara
  • Via manuella eller automatiska uppdateringar av mjukvara, firmware osv
  • Man in the middle-attack eller MOTS mot nedladdad mjukvara
  • Via hackad server eller klient, bifogade filer i mail, sårbarhet i mjukvara
  • Fysiskt installerad via serverhall eller evil-maid attack
  • Infekterat PyPi, NPM, CPAN, RubyGem, NuGet-paket
  • Insider

Klienter och servrar

En vital funktion för att upptäcka bakdörrar på klienter och servrar är att samla in data, det kan röra sig om processer som startar och avslutas, drivrutiner som installeras/avinstalleras, telemetridata. Det är information där en enskild loggrad eller händelse kanske inte säger så mycket, men om den berikas och sätts i ett större sammanhang kan identifiera ett avvikande beteende.

Använder ni Windows-baserade system så är Sysmon ett givet verktyg att använda. För Linux-system så bör man använda verktyg såsom Sysdig Falco och auditd. Eller mer generiska verktyg såsom osquery.

Jag rekommenderar även att titta närmare på Velociraptor som jag bloggade tidigare om. Givetvis bör även binärer, konfigurationsfiler och dylikt hållas koll på med tripwire-liknande funktionalitet. Jobb som körs vid regelbundna intervall såsom cron, AT (Task Scheduler) osv. Eller vid uppstart av mjukvara, system (autoruns).

Nätverk

Jag har tidigare skrivit om RITA som kan underlätta analysen av nätverkstrafik för att hitta beacons som bakdörrar och implantat använder sig av för att kommunicera. Men en väl skriven bakdörr gör detta väldigt sällan och avviker minimalt från normal nätverkstrafik.

Att använda sig av TLSI (TLS Inspection) kan underlätta analysen av TLS/SSL-krypterad nätverkstrafik men det finns givetvis risker också, som bl.a. NSA varnat för. Rekommenderar att titta på PolarProxy som kan hjälpa till med TLSI.

Verktyg som kan hjälpa dig att analysera nätverkstrafik är exempelvis Zeek, JA3/S, Brim, Suricata, Arkime (fd Moloch) och SecurityOnion.

Passivt bör ni också undersöka om system anropar och kopplar upp sig mot kända C&C-servrar, därav viktigt att underhålla aktuella Threat Intelligence-listor med IP-adresser, domännamn etc.

Mängden av data som flödar ut ur era system kan också ge en fingervisning om exfiltration genomförs. Men detta är inte alltid helt enkelt att upptäcka, vid forensiska undersökningar där jag medverkat har jag sett att antagonister delar upp upp information i flertalet 500MB RAR-arkiv som exfiltreras över en längre tid för att undgå upptäckt.

bakdörr IT-system skadlig kod

Glöm inte heller att DNS kan användas för kommunikation, som bl.a. SolarWinds Orion SUNBURST-bakdörren gjorde. Även kan Twitter och andra sociala medier eller andra välkända tjänster användas för kommunikation med bakdörren. Steganografi kan också nyttjas för att försvåra upptäckt.

På internet eller fjärrsystem

Att aktivt undersöka vilka fjärrsystem på Internet som anropas kan hjälpa till att förstå om bakdörren pratar med en Command and Control-infrastruktur (C&C). Flertalet olika datakällor såsom Shodan kan användas för att förstå vilket eller vilka målsystem som kommunikationen sker mot.

Ett verktyg såsom JARM kan hjälpa till med detta och skapa unika signaturer. Observera att just aktivt undersöka system på internet kan vara en legal gråzon och undersök noga vad ni har möjlighet att göra.

Avslutande ord

Jag rekommenderar att bygga upp ett antal olika scenarion där ni undersöker vilka möjligheter ni har att upptäcka just dessa metoder. För att ge några exempel:

  • Log4j JNDI-sårbarheten utnyttjas på ett system mot Internet. Om en bakdörr sedan installeras på detta system, hur kan ni försvåra installation av bakdörren och hur ni upptäcka denna bakdörr?
  • En mjukvara som automatiskt uppdateras börjar att ”ringa hem” via dess normala kanaler för uppdateringar. Men innehåller nu krypterad data om erat interna nätverk såsom AD-namnet
  • DNS används för exfiltration
  • Switchen ni köpte innehåller en Rasperry Pi med WiFi eller 4G-mobildata för exfiltration av intern nätverkstrafik

Vad väntar ni på? Avsätt tid och resurser redan nu för att utveckla förmågan att upptäcka bakdörrar i IT-system. Och givetvis så bör ni också genomföra åtgärder för att försvåra för att bakdörren hamnar i IT-systemet i första taget, och även dess möjligheter att kommunicera ut på internet (eller på andra sätt ringa hem).

Desto mer bakdörren är integrerad i en befintlig komponent i era IT-system desto svårare är det att upptäcka den.

Tack till Erik Hjelmvik för genomläsning och synpunkter!

NSA varnar för ny Windows-sårbarhet

NSA varnar för ny sårbarhet i Windows

TL;DR Windows CryptoAPI Spoofing-sårbarhet

Uppdatering: Nu finns det en PoC ute, se nedan bild (källa)

Uppdatering 2: Attacken fungerar även mot Chrome.

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.

Varningen i sin helhet kan du läsa här (PDF)

NSA varnar för TLS-inspektion

NSA

Amerikanska säkerhetsmyndigheten NSA går nu ut och varnar för  Transport Layer Security Inspection (TLSI). Anledningen till att NSA nu varnar för TLSI är för att metoden att granska nätverkstrafik som går in och ut ur organisationer blir allt vanligare samt att denna metod även medför ett antal olika säkerhetsrisker.

Några anledningar till att TLSI blir allt vanligare är för att kontrollera att nätverkstrafiken inte innehåller någon form av skadlig kod eller att klienter kommunicerar med skadliga webbplatser eller Command and Control-servrar (C&C). Denna form av inspektion kan också förekomma i enheter såsom Deep Packet Inspection (DPI) eller NIDS/IDS, Network Intrusion Detection Software.

Exempel på hur det kan se ut med och utan TLS-inspektion:

Bild från NSA

Problemen som NSA pekar på

Men vilka problem är det då som kan uppstå med denna set-up? Jo det finns flertalet problem som jag tänkte gå igenom här:

Validering av certifikat – Tidigare undersökningar visar på att certifikatvalideringen i TLSI-enheter inte varit 100%-ig och detta ökar risken för bl.a. man-i-mitten attacker.

Algoritmer och SSL/TLS-versioner – Precis som förra punkten så kan brister i SSL/TLS-handskakningen eller val av algoritmer påverka säkerheten såsom nedgraderingsattacker.

Tillgången till klartext – Det finns en punkt i organisationen där någon kan läsa och modifiera klartexttrafik. Detta är ett problem ur säkerhetssynpunkt men även integritet. Ett intrång kan även leda till att klartexttrafik kan läsas.

Insiderhotet – En person som har tillgång till trafiken kan läsa ut lösenord. Se till att ha en särskild granskningsroll som kan se vad TLSI-administratörerna gör för något.

Observera också att en TLSI kan användas både för utgående trafik från klienter men även inkommande (reverse proxy) för exempelvis webbsajter. Värt att nämna här är även den sårbarhet i F5:s produkter som Christoffer Jerkeby hittade. Vill du själv testa TLSI så kan jag rekommendera Erik Hjelmviks PolarProxy.

En annan sak som NSA lyfter i rapporten är även att du bör undvika att bädda in flertalet produkter där din klartext flödar. Försök att hålla ner komplexiteten för riskerna ökar med antalet produkter samt så försvåras felsökning. Certifikatspinning kan också bli ett problem samt så påpekas att HTTP Strict Transport Security (HSTS) inkluderar stöd för att binda en TLS-session(?).

Rapporten från NSA kan du hitta i sin helhet här:

NSA tls rapport
MANAGING RISK FROM TRANSPORT LAYER SECURITY INSPECTION 

Källa: NSA

Attacker mot SSL VPNs

Attacker mot SSL VPNs

En av de mer intressanta släppen under sommarens Blackhat-konferens i Las Vegas var den som handlade om att attackera SSL VPN:s.

Och varför är detta intressant? Jo det finns ett antal olika faktorer till att just detta är intressant och jag ska försöka beskriva dem nedan:

Underrättelsetjänster

NSA och andra underrättelsetjänster ser VPN:s som mål för att de används för att utbyta information. Med hjälp av passiv (och aktiv) avtappning så kan informationen ge fördelar, försprång och gynna den egna industrin:

Equation Group’s BENIGNCERTAIN tool – a remote exploit to extract Cisco VPN private keys. 

Attackytan

Attackytan för specifikt SSL VPN:s är intressant då det mest troligt är en webbservern inblandad och denna kan innehålla sårbarheter. Webbservern måste hantera TLS, HTTP och underliggande protokoll. Vilket kan jämföras med exempelvis IKE och IPSEC.

En angripare som kan ta sig in i en VPN-enhet kan troligtvis också ta sig vidare in i nätverket eller modifiera kommunikationen (förutom att läsa av den).

Hårdvaran

När du köper ett SSL VPN så köper du troligtvis en låda av en leverantör som du inte vet så mycket om. Hur är det underliggande operativsystemet uppsäkrat? Vet du om den använder den ASLR + DEP? Och om den nu blir hackad, hur genomför du en forensisk undersökning av enheten?

Sårbarheterna

Följande sårbarheter har identifierats av Meh Chang (@mehqq_) och Orange Tsai (@orange_8361) i Fortigate SSL VPN:

  • CVE-2018-13379: Pre-auth arbitrary file reading
  • CVE-2018-13380: Pre-auth XSS
  • CVE-2018-13381: Pre-auth heap overflow
  • CVE-2018-13382: The magic backdoor
  • CVE-2018-13383: Post-auth heap overflow

Även har sårbarheter identifierats i Pulse Secure VPN, se mer här.

Även så har Palo Alto i all tysthet även patchat sin GlobalProtect, se mer här. Vad som också är skrämmande just nu är att två av ovan sårbarheter utnyttjas aktivt på internet av angripare vilket CERT-SE gick ut med en varning om.

Åtgärder

Sist men inte minst så tänkte jag ge några rekommendationer vad ni som organisation bör göra om ni har ett SSL VPN som är exponerat mot Internet.

  • Spara ner trafik framför och bakom SSL VPN:et. Så ni kan i efterhand undersöka vad som har hänt.
  • Uppdatera och se till att senaste säkerhetspatchar är installerade och att produkten inte är End-of-Life
  • Se till att loggar skickas från SSL VPN:et. Om möjligt alla typer av loggar såsom access-loggar på webbservern.
  • Begränsa tillgången till system som kan nås via VPN:et. Dvs ge inte full åtkomst till allt bara för att en användare ansluter via VPN.
  • Genomför en oberoende säkerhetsgranskning av uppsättningen
  • Er anslutningspunkt kanske inte bör vara vpn.företagsnamn.se
  • Följ upp anslutningar till och från Erat VPN. Har någon överfört 100 GB via VPN:et utan en koppling till en inloggad användare? Långa TCP-sessioner, beacons osv.
  • Policy över hantering av nya och användare som slutar samt regelbunden uppföljning
  • Försvåra password-spraying attacker genom att använda hårda/mjuka certifikat etc. Dator + användarcertifikat
  • Har ni eller har haft en sårbar version. Se till att byta samtliga lösenord
  • Sök av kontinuerligt med en sårbarhetsskanner

Har jag missat något ovan? Fyll gärna på i kommentarsfältet nedan.

Uppdatering: Här finns en NSE-fil för Nmap för att identifiera sårbara Pulse Secure VPNs: https://github.com/r00tpgp/http-pulse_ssl_vpn.nse/blob/master/http-pulse_ssl_vpn.nse

NSA släpper Reverse-Engineering verktyg

NSA släpper Reverse-Engineering verktyg

Uppdatering: Ghidra är nu släppt på https://ghidra-sre.org/

Amerikanska säkerhetsmyndigheten NSA avser att släppa verktyget GHIDRA som open-source under den årliga RSA-konferensen som går av stapeln i San Francisco under Mars månad.

Stöd mitt bloggande via Patreon 👊

GHIDRA är ett ramverk för att utföra Reverse-Engineering eller baklänges ingenjörskonst som det ibland kallas. Analysera binär kod exempelvis i syfte att undersöka skadlig kod eller ta sig in i system.

The GHIDRA platform includes all the features expected in high-end commercial tools, with new and expanded functionality NSA uniquely developed, and will be released for free public use at RSA.

Robert Joyce, NSA

Charlie Miller som tidigare jobbat på NSA kommenterade på Twitter att verktyget fanns för 13 år sedan då han jobbade på myndigheten:

Verktyget är skrivet i programspråket Java och påminner mycket om IDA Pro som är ett verktyg som jag spenderat en hel del tid med.

Information om GHIDRA har tidigare läckt via CIA Vault7-läckorna som återfinnes på Wikileaks.

Unfetter – NSA:s nya verktyg för att upptäcka avancerade cyberattacker

Den amerikanska myndigheten NSA har tillsammans med det icke vinstdrivande företaget Mitre utvecklat ett nytt verktyg vid namn Unfetter. Med hjälp av detta verktyg så kan en organisation effektivare identifiera cyberattacker genom att fokusera på att upptäcka beteendebaserad metodik istället för indikatorer samt inspireras av Mitres tidigare projekt vid namn CAR och ATT&CK.

Verktyget finns tillgängligt som open-source via Github och jag har givetvis testat verktyget.

Först och främst så klonade jag hem repot som innehåller docker-compose.yml vilket används av Docker. Sedan skrev jag docker-compose up i katalogen för att ladda hem och starta upp sex stycken containers:

NSA unfetter Docker composer up

Den container som heter unfetter-discover-gateway ser till att exponera tcp port 80 samt 443 och surfar vi sedan in på https://localhost så möts vi (förutom ett certifikatfel) följande bild:

Där jag sedan har möjlighet att navigera vidare till någon av de vyer som finns förinstallerade via Kibana:

  • Threat Dashboard
  • Analytic Exchange
  • Assessments
  • Assessments 3.0
  • Intrusion Set Dashboard
  • Events Dashboard
  • API Explorer
  • STIX

Tanken är alltså att du ska skicka in data från olika klienter och servrar med hjälp av NXlog och sysmon exempelvis.

Följande övergripande arkitekturbild visar hur det hänger ihop:

Givetvis så följer det även med exempelkonfigurationer till både nxlog och sysmon.

Men den kanske mest intressanta frågan är: Hur upptäcks avancerade cyberattacker? Det är genom att koppla ihop olika indikatorer, exempelvis denna:

CAR-2016-04-005: Remote Desktop Logon

Vilket implementerar ungefär (pseudokod) följande regler på inkommande analyserade loggar:

[EventCode] == 4624 and
[AuthenticationPackageName] == 'Negotiate' and
[Severity] == "Information" and
[LogonType] == 10

A remote desktop logon, through RDP, may be typical of a system administrator or IT support, but only from select workstations. Monitoring remote desktop logons and comparing to known/approved originating systems can detect lateral movement of an adversary.

Dessa indikatorer kan sedan kopplas mot Mitres ATT&CK och olika grupperingar såsom Equation Group (EQGRP) och deras modus operandi. Dock verkar det inte gå automatiskt i dagsläget och så här ser Intrusion Set Dashboard ut för Equation:

Equation Group

Vi kan även se att Equation har 2 av 219 attack patterns i det intrusion set som följer med Unfetter. För den som vill se hur logstash är konfigurerad mot sysmon kan kolla in följande konfigg-fil på Github.

NSA framhäver även att Unfetter inte är färdigt för att användas i produktion ännu:

This is not designed for production use

Google startar cybersäkerhetsföretag: Chronicle

Nu startar Google upp ett nytt säkerhetsföretag vid namn Chronicle. Eller egentligen är det inte Google som startar upp företaget utan Googles moderbolag Alphabet. Chronicle är en avknoppning av Alphabets labbverksamhet som går under det mystiska namnet X.

Chronicle ska hjälpa till att stärka cybersäkerheten med bl.a. artificiell intelligens och smarta algoritmer. Även den populära tjänsten VirusTotal som Google köpte för några år sedan flyttas till Chronicle.

Stephen Gillett som är VD på Chronicle säger:

We want to 10x the speed and impact of security teams’ work by making it much easier, faster and more cost-effective for them to capture and analyze security signals that have previously been too difficult and expensive to find. We are building our intelligence and analytics platform to solve this problem.

Och en annan relaterad och intressant nyhet är att Amazon köper upp företaget Sqrrl som grundats av ett antal personer som tidigare jobbat på NSA. Sqrrl har byggt en intressant plattform för Threat Hunting.

Tidning avslöjade visselblåsare

Tidningen The Intercept publicerade igår en NSA-rapport med klassificeringen TOP SECRET. Rapporten är på fem sidor och beskriver de cyberattacker som ryssland utförde mot USA i samband med valet förra året.

Dokumentet som läckt har scannats samt publicerats av The Intercept. Detta dokument innehåller spårningskoder i form av små prickar som många skrivare automatiskt lägger till, se här:

Detta är välkänt och uppmärksammat av exempelvis organisationen EFF. Det finns även en mjukvara för att avkoda dessa prickar och något som flertalet personer på Twitter uppmärksammat samt Robert Graham:

Och som du ser ovan så får vi ut när utskriften genomfördes samt vilket serienummer skrivaren som skrev ut det läckta dokumentet som The Intercept publicerat. Den som läckt dokumentet heter WINNER och enligt följande arresteringsorder så jobbade hon som konsult åt en amerikansk myndighet i Georgia.

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:

Blackhat Europe 2016 rapport dag 2

Blackhat Europe 2016

Detta är en sammanfattning av ett antal föreläsningar under Blackhat Europe 2016 som gick av staplen i London. En sammanfattning från dag 1 kan du läsa här.

Identifiera nya sårbarheter i webbapplikationer med hjälp av backslash

portswigger

Föreläsare: James Kettle från PortSwigger

Problemet med många av dagens automatiska sårbarhetsskanners är att de bara identifierar lågt hängande frukter. Att skicka många webbförfrågningar automatiskt för att täcka samtliga buggar är helt enkelt omöjligt. Därför har James valt att försöka bygga en ny extension till Burp där målet är att identifiera bugg-klasser istället för enskilda sårbarheter.

Detta gör han genom att skicka tester för buggklasser istället för enskilda sårbarheter. Exempelvis så testas escape-hanteringen av input-data och observerar output.

Som test så listade han samtliga Bug Bounty-program som tillåter automatiska skanningar. Även så skrev han ytterligare en extension till Burp Suite som begränsar antalet förfrågningar per domän till 3 st.

Burp Extension finns att ladda hem här: https://github.com/PortSwigger/backslash-powered-scanner

Så förhindrar du att Big Data används för att analysera ditt liv

 

breaking-big-data

Föreläsare: David Venable från Masergy Communications

David Venable har en bakgrund från att arbetat på amerikanska myndigheter såsom NSA. Han berättar att mer och mer metadata och data samlas in av myndigheter och företag. Föreläsaren är dock inte oroad för att myndigheter missbrukar data utan mer de företag som sparar på sig metadata och inte har samma rutiner för att förhindra missbruk.

David rekommenderar boken Weapons of math destruction.

Att dra slutsatser med algoritmer och felaktig data kan få ödesdigra konsekvenser. Exempelvis att du är uppkopplad mot samma mobilmast som en terrorist, dvs du råkar bara befinna dig på fel ställa vid fel tidpunkt.

Intressant att Uber för några år sedan gick ut med ett blogginlägg som nu är raderat hur de kan spåra dina engångsligg, läs mer här: http://boingboing.net/2014/11/19/uber-can-track-your-one-night.html

Det kommer troligtvis mycket snart att finnas försäkringsbolag som börjar att använda GPS-data, inköposdata och annan data.

Även går han igenom alla olika metoder som kan användas för att spåra en person. Såsom vilken handstil du använder, skrivbeteende eller vilka tider du är aktiv.

Med hjälp av olika metadata såsom dina vänner, beteenden, känslor, rörelser blir en persona av dig. Även rekommenderar han The Grugq’s OPSEC: Because jail is for wuftpd.

Intressant också är att om du har för lite information på nätet så blir du automatiskt misstänkt. Exempelvis gör kinser och ryssar detta så fort det kommer en ny diplomat. Om det finns för lite information så klassas personen automatiskt som CIA undercover-agent.

Injektion av felaktigheter i säkra bootprocesser

secureboot

Föreläsning av Niek Timmers & Albert Spruyt från Risecure

Genom att påverka strömstyrkan vid rätt tillfälle och inte för mycket och inte för lite så kan fel introduceras i hårdvara. Det är dock svårt att exakt påverka vad som kommer att hända när fel introduceras.

Forskarna som presenterar har tagit fram en ny metod vid namn instruction corruption. Denna metod kan användas för att angripa SecureBoot-processer. Desto tidigare in i uppstarts-processen desto högre behörigheter har koden som körs, men dock så är det mindre kod i början och mer i slutet av uppstartsprocessen. Dvs mindre attackyta i början av uppstartsprocessen.

För den som vill testa hemma så finns det en hårdvara vid namn ChipWhisperer Lite som underlättar fault-injection attacker.

Observera att du kan bricka enheten om du glitchar för hårt. Olika värden att kontrollera vid attacken:

  • Väntan innan injektion
  • Voltstyrka
  • Tiden för injektion

För att ta sig förbi SecureBoot så måste en if-funktion påverkas så att en RSA-verifiering lyckas istället för misslyckas. Och tittar man på assembler-koden så finns det minst fyra ställen som opkoden kan påverkas för att starta upp på en annan mjukvara.

Men hur förhindrar tillverkarna denna typ av attack? Jo det måste göras genom flertalet olika metoder. Bl.a. genom att införa multipla kontroller på olika ställen. Men även om tillverkaren lägger in exempelvis dubbla memcmp:s så optimerar kompilatorn bort den ena av denna.

Det forskarna har gjort nu som är nytt är dom bygger nya attacker genom att introducera logiska sårbarheter, exempelvis storleken vid en memcpy.

Vad händer med krypton efter kvantdatorernas intåg?

post-quantumFöreläsning av Jennifer Fernick från University of Waterloo

Detta är den första kvinnliga föreläsaren som jag lyssnar på under konferensen, vore så klart trevligt med en ännu mer diversering av talare. Hur kommer ett kryptoarmageddon att se ut? Troligtvis kommer det inte att vara som när en ny iPhone-modell som står överallt i nyheterna.

Med tanke på problemen att gå från 3DES till AES så kommer post-quantum crypto att vara ett stort problem.

Quantum-safe security beror på: Kryptografisk forskning, standarder, system/integration och leverantörer/tillverkare (även open source).

Även om exempelvis TLS stödjer post-quantum algoritmer så dyker andra problem upp exempelvis att stödja längre nycklar.

Just nu finns följande post-quantum krypton ute i stora drag:

  • TLS med post-quantum algoritmer
  • Tor circuts med algoritmer
  • Hash-baserade signaturer
  • Off-the-Record Messaging (OTR) är ett område där föreläsaren har fokuserat på.

Signal-protokollet baseras på många delar av OTR. Diffie-Hellman är exempelvis inte säkert för beräkningar utförda av kvantdatorer. AES försvagas från 256-bitar till 128 bitar exempelvis.

Projektet Open Quantum Safe (OQS) har implementerat många av post-quantum algoritmer:

https://github.com/open-quantum-safe/liboqs