httpoxy – Ny omfattande sårbarhet mot webbapplikationer

httpoxy attack

httpoxy är namnet på en nygammal säkerhetsbrist kan återfinnas i otroligt många ramverk för webbapplikationer. Denna nya bugg gör det möjligt för en angripare att styra om utgående trafik från en webbapplikation.

Buggen kan beskrivas lättast genom följande förfarande:

  1. Angriparen gör ett anrop mot en sårbar applikation och skickar med Proxy-http headern
  2. Applikationen gör en utgående förfrågan efter data och använder sedan uppgifter från angriparens Proxy-http header som proxy
  3. Angriparen kan sedan sätta sig i mitten och genomföra MITM-attack

Nedan listas några programspråk och dess uppsättning som kan vara sårbar för denna attack.

Programspråk Ramverk HTTP-klient
PHP php-fpm
mod_php
Guzzle 4+
Artax
Python wsgiref.handlers.CGIHandler
twisted.web.twcgi.CGIScript
requests
Go net/http/cgi net/http

Åtgärder

För att förhindra denna attack måste först och främst din applikation använda sig av ovan programspråk, ramverk och http-klient. Även så måste din webbapplikation göra utgående http-förfrågningar när en besökare gör sitt anrop.

För att ta bort HTTP_PROXY miljövariabeln som är boven i dramat så kan du som använder Nginx lägga till följande:

fastcgi_param HTTP_PROXY "";

Använder du Apache som webbserver bör du först och främst läsa denna advisory och sedan kan du använda följande direktiv för att ta bort Proxy http-headern:

RequestHeader unset Proxy

Och använder du Microsoft IIS tillsammans med PHP så bör du lägga in följande i din apphost.config:

<system.webServer>
    <rewrite>
        <rules>
            <rule name="Erase HTTP_PROXY" patternSyntax="Wildcard">
                <match url="*.*" />
                <serverVariables>
                    <set name="HTTP_PROXY" value="" />
                </serverVariables>
                <action type="None" />
            </rule>
        </rules>
    </rewrite>
</system.webServer>

Buggen har återkommit under flertalet år i olika ramverk och tyvärr så har den aldrig riktigt åtgärdats.

Säkerhetsbuggen har fått följande CVE-er:

  • CVE-2016-5385: PHP
  • CVE-2016-5386: Go
  • CVE-2016-5387: Apache HTTP Server
  • CVE-2016-5388: Apache Tomcat
  • CVE-2016-1000109: HHVM
  • CVE-2016-1000110: Python

Här hittar du mer information: httpoxy.org

Testa lösenord med THC Hydra v8.2

hydraHydra tillsammans med ncrack och medusa är ett av de mer populära verktygen för att fjärrmässigt testa lösenord, exempelvis över Internet. Hydras första version kom ut 2001 och grundades av van Hauser från hacker-gruppen THC (The Hacker’s Choice).

Denna nya version som nyss släpptes heter v8.2 och har stöd för bl.a. TLS SNI vilket gör det möjligt att skicka med domännamn i TLS/SSL-förbindelser. Något som alla moderna webbläsare gör i dagsläget, så inte ett SSL-certifikat behövs per IP-adress.

Test av Hydra 8.2

Vi laddar hem den senaste versionen 8.3-dev från Github och testar att forcera lösenordet till användaren IEUser via ssh:

THC Hydra 8.3

Observera att hydra är beroenden av en mängd tredjepartsbiblioteket såsom openssl, libssh och zlib. Din kompilering kan lyckas men när du ska testa något protokoll så kan du få ett meddelande att den modulen inte finns inkompilerad.

När jag testar med Remote Desktop (RDP-modulen) så lyckas inte Hydra identifiera rätt lösenord konstigt nog. Enbart crowbar lyckas med detta, och medusa som följer med Kali Linux har inte rdp.mod (RDP modulen) med som standard.

Hela listan med protokoll som stöds är:

 Asterisk, AFP, Cisco AAA, Cisco auth, Cisco enable, CVS, Firebird, FTP, HTTP-FORM-GET, HTTP-FORM-POST, HTTP-GET, HTTP-HEAD, HTTP-POST, HTTP-PROXY, HTTPS-FORM-GET, HTTPS-FORM-POST, HTTPS-GET, HTTPS-HEAD, HTTPS-POST, HTTP-Proxy, ICQ, IMAP, IRC, LDAP, MS-SQL, MYSQL, NCP, NNTP, Oracle Listener, Oracle SID, Oracle, PC-Anywhere, PCNFS, POP3, POSTGRES, RDP, Rexec, Rlogin, Rsh, RTSP, SAP/R3, SIP, SMB, SMTP, SMTP Enum, SNMP v1+v2+v3, SOCKS5, SSH (v1 and v2), SSHKEY, Subversion, Teamspeak (TS2), Telnet, VMware-Auth, VNC and XMPP.

Så blir du en ninja på nätverksforensik

Nätverksforensik

För att bli en ninjamästare på nätverksforensik så gäller det först och främst att du är bekväm och känner till din uppsättning med verktyg. Jag rekommenderar att du börjar med att testa Linux-disten Security Onion som är har en stor mängd olika verktyg förinstallerade såsom NetworkMiner, Argus, Snort och Bro.

Sen gäller det också att ha tillgång till någon data att experimentera med, och desto råare format desto bättre. Därför gillar vi som jobbar med nätverksforensik formatet pcap (och numera även pcap-ng).

Har du inga egna pcap-filer så kan du alltid skapa upp dessa genom att spara ner nätverkstrafik till/från din egen dator eller hämta hem från Wireshark eller Netresec.

Hitta rätt i nätverkstrafiken

När du väl har tillgång till råmaterial i form av pcap-filer så måste du lista ut hur du ska angripa problemet. Oftast så finns det inte enbart en lösning på problemet utan som forensiker får du prova flera olika innan du eventuellt hittar en lösning.

Mer åren får du troligtvis även mer erfarenhet och kan lösa problem snabbare och navigera rätt snabbare bland nätverkstrafiken.

Frågan vi måste ställa oss är: Vad är syftet? Vad är det vi är ute efter. Är det potentiellt skadlig kod som har passerat eller söker vi efter något annat. Och innan vi börjar så bör vi även veta hur nätverkstopologin ser ut:

  • Är trafikinspelningen innanför eller utanför brandväggen?
  • Är det bakom NAT?
  • Är det egress/ingress eller dubbelriktad trafik

Sedan bör ni ha en Standing Operating Procedures (SOP) för hur trafiken ska hanteras. Jag rekommenderar exempelvis att alltid använda Snort och ett relativt uppdaterat regelverk som en av de första kontrollerna.

NinjaUtmaningar inom nätverksforensik

Att titta på nätverket ger oftast enbart en bild som många gånger bör kompletteras med övriga forensiska utredningar av datorer exempelvis. Även kan loggfiler från olika system också komplettera den nätverkforensiska undersökningen.

Jag ser även att mer och mer trafik blir också krypterad och använder sig av TLS (https) vilket gör det svårare att titta vad som går i sessionerna. False-flag är också något som förekommer mer och mer där metoden går ut på att förvilla och lämna falska spår.

Behöver Er organisation hjälp med nätverksforensik? Kontakta Triop AB 

En annan metod att kringgå och försvåra nätverksforensik är domain-fronting. Med denna metod så döljs skadlig trafik i kommunikation mot tjänster såsom CDN (se mitt föredrag från Internetdagarna 2014).

Verktygen du ska lära dig

Wireshark och tshark

Först och främst är Wireshark och dess CLI-version tshark något som jag anser att alla bör behärska. Och hanterar du stora mängder data så är det otroligt viktigt att känna till alla kommandoargument som tshark kan ta.

Exempel på kommando: Följande kommando kan användas för att titta på information om TLS/SSL-certifikatet vid en handskakning:

tshark -r snort.log.1425565272 -R ssl.handshake.certificate -V | grep dNSName:

Även så kan vi titta på SNI-värdet (server name indication) om detta finnes:

tshark -r test.pcap -T fields -e ssl.handshake.extensions_server_name

tcpdump

tcpdump är också ett sådant självklart kommando som följer med nästan alla Linux-distar och kan användas till det mesta. Om inte annat så har verktyget bra prestanda när det gäller att filtrera trafik när du skriver pcap-filter för att förfina sökningen, exempelvis:

tcpdump -r gigantisk-fil.pcap -w mindre-fil.pcap "dst port 31337"

Och behöver du snabbt och enkelt spara ner data så brukar jag köra kommandot nedan. Observera att snaplen -s inte behövs om du har en relativt ny tcpdump-version eftersom nya går standard till 65535 bytes (tidigare 96).

tcpdump -i en2 -s0 -w test.pcap

ngrep

ngrep används precis som det klassiska kommandot grep, dvs att vi söker efter något. Gör ingen direkt tolkning av protokoll såsom tshark/wireshark vilket gör att kommandot kan vara snabbare att arbeta med.

Följande kommando kan användas för att identifiera namn på HTTP-förfrågningar

ngrep -q -W byline -I snort.log.1425565276 Host:|grep -i ^Host

Network Miner

Erik Hjelmvik som utvecklat Network Miner har även utvecklat CapLoader och andra bra verktyg. Följer med Security Onion men en gratisversion kan även laddas hem från Netresec. Lätt och enkelt att arbeta med och är det bästa verktyget för att identifiera filer som går över nätverket.

För cirka 7400kr så får du en bättre version som har ytterligare en mängd funktioner såsom protokollidentifiering med hjälp av statistik, GeoIP, CLI-version.

NetworkMiner

Om du använder dig av Security Onion kan du starta NetworkMiner med kommandot /opt/networkminer/networkminer

tcpflow

NinjaDetta verktyg parar ihop TCP:s fem-tupel och skriver ner dessa strömmar till disk, en ström per fil. Otroligt värdefullt om du vill analysera stora mängder data närmare.

Varje fil får ett namn som relaterar till sessionen i form av IP-adress src/dst samt käll och destinations-porten. Med nollor som prefix, exempelvis:

185.003.051.013.00080-010.101.001.143.63092

Sedan kan vi hantera filen med vanliga verktyg såsom grep, head osv:

$ head -3 185.003.051.013.00080-010.101.001.143.63092
HTTP/1.0 304 Not Modified
Server: Apache-Coyote/1.1
P3P: policyref="/w3c/p3p.xml", CP="NON DSP COR NID CUR ADMa DEVa PSAa PSDa TAIa OUR IND COM CNT DEM INT LOC NAV PRE UNI"

Även så genomförs ingen vidare avkodning, så vi får själv ta hand om gzippat innehåll osv. Men har vi en nyare version och lägger på argumentet -e http (eller -a). Då får vi en till fil men med suffixet -HTTPBODY-002 exempelvis:

185.003.051.013.00080-010.101.001.143.63092-HTTPBODY-002

snort

Snort är en mjukvara för att upptäcka intrång i nätverkstrafik (IDS) men kan även läsa PCAP-filer i efterhand. Och som anti-virus motorer så fungerar en IDS bäst då regelverket är uppdaterat.

När det gäller Snort så finns det tre huvudspår när det gäller regelverk:

  • Emerging Threats
  • Snort – Cisco Talos
  • Snort Community

Jag rekommenderar att använda Snort Cisco Talos, kostar enbart 29$ per år för personligt bruk. Annars testa även Emerging Threats regler som också uppdateras och innehåller 47k regler. Kör kommandot rule-update på Security Onion om du vill uppdatera regelverket med PulledPork:

PulledPork

För att läsa in en pcap-fil och sedan skriva ut larm till mappen ./log/ kör du:

snort -r snort.log.1425565276 -c /etc/nsm/templates/snort/snort.conf --daq pcap --daq-mode read-file -l ./log/

Och om du som jag får många regler som larmar false-positive så kan du alltid lägga till dem i filen /etc/nsm/pulledpork/disablesid.conf

Även så kan Snort logga direkt till console med -A console argumentet.

Givetvis är även Suricata ett alternativ till Snort, och finnes så klart redan installerat i Security Onion.

Snort

argus

Argus (audit record generation and utilization system) är uppdelat i en mängd olika verktyg såsom ra, rasort och racluster. Argus gör det lätt att arbeta med flöden samt övergripande analyser. Och precis som många andra verktyg som jag gått igenom här så kan Argus fungera offline eller direkt online mot nätverkstrafik.

Även så kan argus-filer vara bra vid långtidslagring där bara meta-data behöver sparas från trafiken.

argus -r snort.log.1425565276 -w snort.log.1425565276.argus

Vår pcap-fil är på 153 MB och argus-filen är på 241K.

Sedan kan vidare använda argus verktyg såsom racluster och rasort för att koppla ihop TCP-sessioner och sedan sortera samtliga sessioner i filen för att försöka upptäcka exfiltration:

racluster -r snort.log.1425565276.argus -w -|rasort -r - -m sbytes|head -30

Och vill vi enkelt filtrera ut samtliga tcp-sessioner, slå ihop dessa samt se vilka som varit mest långvariga kan vi köra följande kommando:

racluster -r snort.log.1425565276.argus -w - -- tcp|rasort -r - -m dur -s stime saddr daddr sport dport dur proto |tail

OPSEC

SchhyyyNär du utför dina analyser så bör du upprätthålla god sekretess. Trafiken du analyserar kan innehåll diverse kod som gör att sårbarheter utnyttjas i exempelvis Wireshark. Se därför till att köra så mycket som möjligt med låg behörighet och helt avskilt från andra nätverk och system såsom Internet.

Och fundera igenom allt du gör mot Internet: Vad lämnar detta för spår? Om du exempelvis analyserar kommunikation som en trojan utnyttjar (C&C) och det helt plötsligt dyker upp ett curl-anrop från din analys-klient så kan detta förstöra framtida mtrl.

Antagonisten kan nämligen bevaka kontrollkanalerna och då snabbt radera samtliga bevis, nycklar osv om hen märker att du utför analys.

Riksbanken: Cyberattacker har blivit vanligare

Riksbanken går nu ut och varnar för att cyberangrepp mot det finansiella systemet. I den senaste rapporten från Riksbanken med titel Finansiell stabilitet 2016 så ägnas ett helt fördjupningskapitel på fyra sidor åt cyberangrepp.

I denna fördjupning så pekar Riksbanken bl.a. på att cyberangreppen ökade med 38 procent globalt under 2015 (källa PWC:s rapport Turnaround and transformation in cybersecurity).

Även så pekar man på den attack som genomfördes mot SWIFT-systemet i Bangladesh centralbank under Februari 2016.

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

Riksbankens system förstora betalningar går under benämningen RIX (här kan du se samtliga deltagare). Och RIX är själva navet i det svenska finansiella systemet och där även transaktioner mot RIX distribueras till SWIFT-nätverket.

Och vad detta betyder beskrivs i rapporten enligt följande:

Detta innebär att ett cyberangrepp mot någon del av dessa sammanlänkade nätverk kan hota den finansiella stabiliteten i Sverige men även internationellt

RIX-systemet
Övergripande bild på RIX-systemet

Även så framgår det i rapporten att allt fler aktörer i det finansiella systemet väljer att outsourca sin IT-infrastruktur. Och även om Finansinspektionen utövar tillsyn mot banker och finansiella infrastrukturföretag så framgår följande:

I dag finns det inte någon myndighets om bedriver direkt tillsyn av externa leverantörer av IT‐tjänster till finansiella företag och har mandat att besluta om sanktioner samt vidta åtgärder gentemot dessa externa leverantörer. Ett uttalat ansvar och mandat i detta avseende skulle sannolikt underlätta arbetet med att belysa och minska de risker som kan uppstå när ett fåtal externa leverantörer av IT‐tjänster ansvarar för en stor del av den finansiella sektorns IT‐drift.

Här kan du ladda hem rapporten i sin helhet som PDF:

Riksbanken Finansiell Stabilitet 2016

Ny attack mot Googles tvåfaktorsautentisering (2FA)

Google 2fa

En ny attack som försöker lura användare att skicka vidare sin unika 2FA-inloggningskod (token) har uppdagats av Alex MacCaw på Clearbit. Just denna attack försöker lura användare av Googles tjänster såsom Gmail.

Allt eftersom fler och fler börjar att använda 2FA så kommer även denna typ av attacker att bli allt vanligare.

Skärmdump på hur meddelandet kan se ut:

Google 2FA Attack

Till Android har det även rapporterats tidigare om skadlig kod som automatiskt kan skicka vidare SMS. Detta skrev ESET om i Mars 2016.

Hur står det till med den personliga integriteten?

Hur står det till med den personliga integriteten? är titeln på ett nytt delbetänkande från Integritetskommittén. I rapporten presenterar kommittén översiktlig beskrivning av faktiska och potentiella integritetsrisker som var och en av oss utsätts för i vårt dagliga liv.

Rapporten är gedigen och på hela 814 sidor. Och för den som gillar teknik så har IT-säkerhetsföretaget Kirei skrivit bilaga 3 som handlar om integritetsskyddande teknik.

Bilaga tre är även min personliga favorit och tar upp bl.a. avanonymisering. Även så finns ett intressant kapitel med rubriken Ett dygn med familjen Svenssons elektroniska spår. Där läsaren får följa en fiktiv familj i olika vardagsituationer och vilka digitala spår som denna familj lämnar efter sig:

  • Missade integritetsinställningar
  • Risken med dåliga lösenord
  • Barnens chattrafik okrypterad och avlyssnad
  • E-legitimation på vift
  • Övervakad på jobbet och osynlig kreditprövning
  • Prylar som skvallrar
  • Krypterade filer i molnet
  • Nummerplåtsavläsning
  • Hantering av uppgifter om hälsa
  • Allting spåras på webben
  • Elevhälsa på drift
  • Lifeloggingkameran som fotograferar för mycket
  • Personliga länkar visar vem besökaren är
  • Lojalitetsapp med specialerbjudande
  • Ansiktsigenkänning ger bättre service
  • Mobiltelefonen som spårsändare i stadsplaneringen
  • Mobilen loggar allt och lite till
  • I skattespindelns nät
  • Försäkringskassan profilerar
  • Kameraövervakning i sovrummet

Ordföranden för kommittén är Datainspektionens före detta generaldirektör Göran Gräslund.

Här kan du läsa rapporten i sin helhet:

Integritetskommitténs delbetänkande

Hur står det till med den personliga integriteten? – en kartläggning av Integritetskommittén

💳 Detta är nytt i PCI DSS v3.2

PCI DSSKreditkorts-standarden PCI DSS släpptes nytt i en version 3.2. Denna nya version innehåller en hel del intressanta saker som vi listat nedan. Uppdateringen bygger på feedback från de cirka 700 medlemsorganisationerna som använder sig av standarden och tillhandahåller kortbetalningar.

Ett annat underlag till denna uppdatering är analyser av de läckage av kreditkortsnummer som inträffat. Övriga branscher kan ta och lära en hel del från PCI DSS standarden som funnits sedan 2004.

Nyheterna i PCI DSS version 3.2

  • Tvåfaktorsautentisering blir flerfaktorsautentisering. Dvs minst två faktorer ska användas. Och detta ska användas för icke console-access samt fjärrinloggningar
  • Penetrationstester ska utföras minst var 6:de månad
  • Nytt avsnitt dedikerat till SSL/TLS
  • Regler hur kreditkortsnummer får visas upp
  • Kvartalsvis genomgång att personal följer säkerhetspolicys och operativa förfaranden
  • Att ha en process för att identifiera och rapportera fel i kritiska säkerhetssystem såsom brandväggar, IDS:er, loggning etc
  • Ledningen ska ha tydliga uppgifter när det gäller att skydda kreditkortsdata samt ta fram ett PCI compliance program
  • Dokumentation över krypto-algoritmer som används, hardware security modules (HSM) eller andra Secure Cryptographic Devices (SCD)
  • Dokumentation över nycklar och dess livslängder samt hur nycklarna används

PCI står för Payment Card Industry och DSS står för Data Security Standard. Och den gamla versionen 3.1 upphör att gälla 31 Oktober 2016. Dock är alla nyheter i version 3.2 enbart best practices fram till Februari, 2018 för att alla organisationer ska hinna ställa om.

Här kan du ladda hem Requirements and Security Assessment Procedures PCI DSS 3.2 som PDF:

PCI DSS v3.2

Kommentar på Riksrevisionens rapport om informationssäkerhet i staten

RiksrevisionenMyndigheten Riksrevisionen släppte för några dagar sin rapport med titeln Informationssäkerhetsarbete på nio myndigheter (RiR 2016:8). Rapporten omfattar en granskning gällande informationssäkerheten hos myndigheterna  Svenska kraftnät, Arbetsförmedlingen, Bolagsverket, Försäkringskassan, Lantmäteriet, Migrationsverket, Post- och telestyrelsen, Sjöfartsverket och Statens tjänstepensionsverk.

Arbetet med informationssäkerhet når inte upp till en godtagbar nivå på de granskade myndigheterna

Granskningen har genomförts med hjälp av intervjuer samt så har relevant dokumentation på tre av myndigheterna granskas. Övriga myndigheter har fått svara på en enkät.

Några av de positiva sakerna som tas upp i rapporten:

  • Alla tre myndigheter använder teknisk implementation i form av VPN och tvåfaktorsautentisering, vilket innebär en väsentligt minskad risk vid fjärranslutning.
  • Alla sex myndigheter uppger att de har en metod för att klassificera sina informationstillgångar.
  • Alla tre myndigheter har genomfört tekniska åtgärder för att höja säkerheten på bärbara datorer, och den tekniska säkerheten för dessa är därför god.

Och de negativa delarna och där brister framgår är desto mer, några av dessa är:

  • Den tredje myndigheten når inte upp till godkänt, eftersom backuperna förvaras på samma fysiska plats som originaldata.
  • En myndighet saknar skriftliga bestämmelser för säkerhetsloggning.
  • Det saknas dock bestämmelser om att lösenord inte får loggas.
  • En av de tre myndigheterna har en lösenordspolicy som når upp till godkänt.
  • Ingen av myndigheterna utför dock regelbundna och övergripande analyser som fokuserar på informationssäkerhet.
  • Ingen av myndigheterna når upp till godkänd nivå i fråga om att säkra nyckelkompetens.
  • Flera myndigheter har uppgett att man får, som det heter, uppfinna hjulet på egen hand i alltför stor utsträckning.
  • Två myndigheter har en otillräcklig organisation för att hantera incidenter.

Men hur kan det komma sig att hanteringen av informationssäkerheten kan bli så här? För även om detta bara är ett litet axplock av våra 340 myndigheter så gäller mycket av det som lyfts upp i Riksrevisionens rapport även på andra myndigheter. Och precis som Riksrevisionen skriver i sin rapport så är det främst myndighetsledningens ansvar att prioritera och ta ansvar för informationssäkerheten och inte delegera ner i organisationen.

Jag tror främst att det beror på individnivå, några av myndigheterna har lyckats att rekrytera och behålla engagerade och högt presterande medarbetare. Och därav de olika nivåerna på olika områden inom infosäk på myndigheterna. 

Givetvis är det även också brist på engagemang och intresse från myndighetsledningens sida. Kanske rentav så att brist på intresse för teknik och hur infosäk-arbete måste genomsyra allt arbete på myndigheten. För IT är inte enbart en fråga för IT-avdelningen, utan alla medarbetare på myndigheten måste ha utbildning och förståelse för cybersäkerhet.

Eller som Riksrevisionen framhäver slutsatserna:

Säkerhetsarbetet implementeras inte i de ordinarie verksamhetsprocesserna. Kärnverksamheten uppfattar inte att den har något ansvar för informationssäkerheten, utan att det ligger någon annan-stans i myndigheten såsom på IT- eller säkerhetsfunktioner.

Och även följande är intressant:

Granskningen visar att myndigheternas ledningar har delegerat ansvaret för informationssäkerhet, utan att se till att de ansvariga har ett tillräckligt mandat att utföra sina uppgifter och tillräckligt med resurser.

Tips: Läs även Kim Hakkarainens reflektioner.

Här kan du ladda Riksrevisionens rapport i sin helhet:

Informationssäkerhetsarbete på nio myndigheter - En andra granskning av informationssäkerhet i staten
Informationssäkerhetsarbete på nio myndigheter En andra granskning av informationssäkerhet i staten

Ny metodik för att identifiera Tor-webbläsaren samt Tails

Tor and Tails fingerprinting

Undertecknad har utvecklat en ny metod för att identifiera Tor Browser samt vilken version av det säkra och anonyma operativsystemet Tails som en klient använder sig av.

Metoden går ut först och främst på att fråga webbläsaren efter olika resurser som bara återfinnes i Tor-webbläsaren, och sedan titta på felmeddelandet som är olika beroende på om Tor eller Firefox används. Och beroende på dessa svar så kontrolleras sedan om Adblock Plus är installerat och vilket regelverk som användes. Eftersom Tails uppdaterar regelverket i varje version så kan jag således identifiera vilken version av Tails som används.

Jag har så klart skapat en demo-video, proof-of-concept kod och demo-sajt. Förfarandet rapporterades till Tor-utvecklarna i Januari som då rapporterade det vidare till Firefox som Tor Browser baseras på. Än så länge finns det ingen åtgärd och metodiken fungerar således fortfarande.

Lyckades även att identifiera om Tor Browsern går på Mac OS X genom att titta om -moz-osx-font-smoothing södjs (kanske bara retinas?).

Demo-sidan hittar du här: https://tor.triop.se och koden återfinnes på Github.

Demo video