FRA årsredovisning 2016: Sverige är utsatt för cyberangrepp

FRA årsrapport 2016

FRA släppte precis sin årsrapport för föregående år och trycker detta år på att antalet cyberattacker ökar. Genom sin signalspaning så ser myndigheten att en kvalificerad angripare nästan alltid kan hacka sig in i målet, det är bara en fråga om tid.

Förutom cyberattacker mot kritisk infrastruktur så riktar sig även främmande makt mot följande mål:

  • Försvarsförmåga och försvarsplanering
  • Svenska säkerhetspolitiska avsikter
  • Statshemligheter
  • Industrihemligheter
  • Forskningsresultat

En annan viktig slutsats som FRA drar är att med hjälp av signalspaning så kan vi lära oss om angriparnas angreppssätt, mål och verktyg. Detta kan sedan omsättas för att bygga relevanta skyddsåtgärder för att skydda svenska myndigheter och statligt ägda bolag.

Även framgår i årsrapporten att TDV (tekniska detekterings- och varningssystem) som vi skrivit om tidigare fortsätter att utvecklas. TDV är ett avancerat antivirus-system som tittar på signaturer i signalspaningen. Under 2016 har ytterligare ett antal verksamheter installerat systemet.

Begreppet cyberförsvar har även definierats tillsammans med Försvarsmakten enligt följande:

CYBERFÖRSVAR: En nations samlade förmågor och åtgärder till skydd för dess kritiska cyberinfrastruktur som syftar till att säkerställa kritiska samhällsfunktioner samt förmågan att försvara sig mot kvalificerade angrepp.

Här kan du ladda hem årsrapporten i sin helhet:

Så identifierar du säkerhetsbrister med AFL Fuzzer

AFL står för American fuzzy lop och är en fuzzing-mjukvara utvecklat av övermänniskan Michał Zalewski (lcamtuf) som jobbar på Google. Om Er organisation inte använder fuzz-tester i dagsläget som en del av säkerhetsgranskning eller kvalitétsprocess (QA) så är det läge att börja nu.

AFL är en instrumentell fuzzer och har hittat tusentals olika säkerhetsrelaterade buggar i program och bibliotek såsom libpng, PHP, OpenSSL, putty, Bind, QEMU, curl och procmail för att nämna några.

AFL är öppen källkod och går att köra på x86 Linux, OpenBSD, FreeBSD, och NetBSD. Även går afl på Solaris och macOS och tredjepartskod som körs på windows: winafl.

Jag har skrivit en hel del fuzzers i mina dagar och använt andras ramverk och det första verktyget jag använde var SPIKE runt 2002 som är utvecklat av Dave Aitel. Men sedan dess har det hänt en hel del när det gäller fuzzers och afl är en av de bästa enligt mig.

Nedan följer en guide hur du installerar och kommer igång med AFL:

Installation av afl

Att ladda hem och kompilera afl är relativt enkelt, men jag använder vanligtvis en mac och gillar att jobba med Vagrant (kräver även VirtualBox eller VMware).

Och det finns så klart en färdig Vagrant för just afl:

$ git clone https://github.com/JamieH/vagrant-afl
$ cd vagrant-afl
$ vagrant up
$ vagrant ssh

Det var ju enkelt. Nu kommer det lite krångligare, och det är att få afl att fungera tillsammans med mjukvaran vi vill testa/fuzza.

Kompilera koden med afl

Eftersom afl använder sig av instrumentering så bör du kompilera din kod med afl-gcc eller afl-g++ (afl-clang samt afl-clang++ finns också). Det kan du göra genom att göra följande efter det att du laddat hem källkoden:

$ CC=/usr/local/bin/afl-gcc CCX=/usr/local/bin/afl-g++ ./configure --disable-shared

Detta gör du i mappen där källkoden ligger som du vill fuzza. Just ovan exempel förutsätter även att configure finns i mappen (autoconf). afl stödjer även emulatorn Qemu om du inte skulle ha tillgång till källkoden (blackbox fuzzing).

Skicka in data med afl

Först och främst så måste afl skicka in genererad data i det program vi ska fuzza. Det går att göra på två sätt:

  • Via stdin (consolen)
  • Via en fil som argument

Och det blir genast problem med ovan två punkter om du exempelvis ska fuzza en mjukvara såsom webbserver som tar in data över nätverket. Även så måste mjukvaran stänga ner efter varje förfrågan.

Det finns så klart lösningar på ovan problem, antingen får vi patcha (skriva om koden) för att ta in data från stdin eller använda ett hjälpmedel såsom preeny. Med hjälp av preeny så kan vi fulpatcha anrop mot nätverksfunktionerna socket(), bind(), listen(), och accept() genom följande kommando. Då styrs nätverksanropen om till stdin/stdout:

$ LD_PRELOAD=x86_64-linux-gnu/desock.so afl-fuzz ..osv

Visa vägen

Men innan vi sätter igång med fuzzandet så är det två saker till vi måste lösa. Den första är att kontrollera huruvida instrumenteringen fungerar. Och det gör du med afl-showmap kommandot. Showmap har i stort sett samma argument som afl-fuzz.

Den programvara som jag testar att fuzza är Cyrus imapd och då måste vi även skicka in ett imap-kommando som i detta fall är A LOGOUT samt två miljövariabler:

$ CYRUS_ID=1 CYRUS_SERVICE=foo afl-showmap -m 100 -o /dev/null cyrus-imapd/imap/imapd -X < <(echo "A LOGOUT")
afl-showmap 2.35b by <[email protected]>
[*] Executing 'cyrus-imapd/imap/imapd'...

-- Program output begins --
* OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE AUTH=CRAM-MD5 SASL-IR] vagrant-ubuntu-trusty-64 Cyrus IMAP 3.0.0-beta6-3-gf721e5b server ready
* BYE LOGOUT received
A OK Completed
-- Program output ends --
[+] Captured 1535 tuples in '/dev/null'.
$

Toppen. 1535 tuples (basic blocks) identifierades, det ser bra ut. Om du får ett felmeddelande likt detta:

No instrumentation detected eller failed to map segment from shared object: Cannot allocate memory. Så testa ändra -m flaggan upp till exempelvis 200 som bestämmer hur mycket minne som får förbrukas.

Om jag startar mjukvaran felaktigt eller skickar in ett kommando som inte finns så får jag ingen output och betydligt mindre tuples, se här:

..klipp..

-- Program output begins --
-- Program output ends --
[+] Captured 464 tuples in '/dev/null'.
$

Skapa testfall för fuzzning

Även om afl-fuzz är relativt smart så måste vi föda in något som afl kan jobba vidare med. Och i fallet med imapd som jag testar så är det så klart lämpligt att skicka in olika typer av imap-kommandon. Med lite grep och awk-magi så plockar jag ut alla kommandon som Cyrus imapd stödjer direkt från källkoden:

$ grep strcmp cyrus-imapd/imap/imapd.c|grep cmd.s|awk -F'"' '{print $2}'|sort|uniq > afl/testcases/imap.txt

Och många av de imap-kommandon som finns tar ett eller två argument som vi måste lägga på så att varje testfall hamnar i en egen fil som sedan läses av afl-fuzz:

for a in `cat ../../testcases/imap.txt`; do echo "A $a A A" > $a-A-A.txt; done

Så för att repetera: ett testfall i varje fil i en katalog. Likt detta:

$ cat afl/imap/testcases/Logout.txt
A Logout

Starta fuzzningen med afl-fuzz

Såja, nu vet vi att mjukvaran startar och kan ta input från stdin. Vi har även skapat ett antal testfall och nu återstår bara att starta afl-fuzz.

För att starta fuzzningen kör:

$ CYRUS_ID=1 CYRUS_SERVICE=foo afl-fuzz -m 100 -o afl/imap/findings/ -i - cyrus-imapd/imap/imapd -X

Och då bör några tester genomföras och statusfönstret dyker upp:

AFL fuzzing

Och har vi tur och mjukvaran gått i några timmar/dagar/veckor så dyker några uniq crashes upp. Hangs kan så klart också vara intressant och betyda blockeringsattack (DoS).

Resultaten hamnar i katalogen findings/crashes/ där vi kan analysera vidare vad det är som orsakar en krasch med gdb. Har vi tur så kan vi även skriva en exploit som utnyttjar bristen.

Lop är även en fluffig kaninras, därav bilden av en kanin längst upp i denna guide.

Länkar och vidare läsning

Följande länkar är bra att ha och jag rekommenderar dig att läsa vidare:

Så upptäckte säkerhetsloggning med OSSEC ett intrång

Detta är en historia om hur min säkerhetsloggning som bl.a. bygger på OSSEC identifierade ett intrång på en av mina webbservrar.

OSSEC är öppen källkod och går under licensen GNU GPLv2 och utvecklades från början av Daniel Cid och företaget Third Brigade som sedermera blev uppköpta av Trend Micro. Dock så lovade Trend Micro att fortsätta hålla OSSEC som öppen källkod, vilket det fortfarande är.

OSSEC är en mjukvara som går under kategorin HIDS (host-based intrusion detection system) och har bl.a. funktioner för att analysera loggfiler efter suspekta mönster, detektera rootkits och utföra aktiva åtgärder såsom att blockera i brandvägg.


Det går att installera OSSEC som fristående installationer på varje server och sedan skicka vidare larm med hjälp av rsyslog, syslog-ng eller filebeat (föredetta logstash-forwarder) eller använda OSSEC:s inbyggda funktionalitet för att skicka loggar krypterat. Det finns även Windows-klienter till OSSEC.

Jag har konfigurerat OSSEC som en tripwire-funktionalitet, dvs att OSSEC kontrollerar checksummor på viktiga filer. Eftersom många webbattacker går ut på att modifiera webbsidor så har jag även lagt in så att OSSEC-larmar på förändringar i filer som ligger under webbkataloger. Standard så kontrollerar OSSEC enbart integritet på ett antal viktiga systemfiler, därför är det viktigt att lägga till ytterligare filer som du vill hålla koll på.

Jag brukar lägga till ungefär följande rad i /var/ossec/etc/ossec.conf filen:

 <directories realtime="yes" report_changes="yes" restrict=".htaccess|.php|.html|.js">/var/www/domän.se/</directories>

Och även följande rad om du vill larma på nya filer:

<alert_new_files>yes</alert_new_files>

Skulle du få många nya larm om temporära filer som skapas i någon katalog så kan du alltid lägga ignore på den katalogen enligt följande:

<ignore>/var/www/katalognamn</ignore>

Men observera dock vilken katalog du ignorerar så inte det går att utnyttja av en angripare.

Vidare bör du ställa ner intervallet då övriga filer kontrolleras som är standard på 22h. Du gör det med följande rad i ossec.conf:

<frequency>14400</frequency>

Även så måste du ändra följande fil: /var/ossec/rules/local_rules.xml och lägga till följande rad för att få larm om nya filer:

<rule id=”554″ level=”7″ overwrite=”yes”>
<category>ossec</category>
<decoded_as>syscheck_new_entry</decoded_as>
<description>File added to the system.</description>
<group>syscheck</group>
</rule>

Det är för att regeln med id 554 standard är satt som level=”0″ vilket betyder att du inte får några larm.

Intrånget

Det larm som dök upp från OSSEC som fick mig att höja på ögonbrynen är följande:

Den som är observant på ovan larm ser att includ_once() är en felstavning av PHP-funktionen include_once(). Givetvis så kontrollerade jag filen manuellt och upptäckte då att någon hade manuellt modifierat footer.php. Detta är ett vanligt förekommande förfarande när det gäller hackade WordPress-installationer.

Efter vidare undersökning så identifierade jag Filesman-phpbakdörren men även en till bakdörr. Denna bakdörr la jag in min egen bakdörr i så att den loggade alla försök att utnyttja bakdörren samt att lösenordet till bakdörren loggades. Om du är intresserad av bakdörrar till php så kan du kolla in min samling på Github Gist här.

Du kan med fördel även importera larm från OSSEC till Splunk eller ELK-stacken (Elasticsearch, Logstash och Kibana).

Filesman PHP-bakdörr

Granskning av IT-säkerheten på Dagens Nyheters (DN) tipssajt

Jag har genomfört en oberoende granskning av IT-säkerheten på DN:s sajt där användare kan skicka in tips. Tidigare har jag bl.a. granskat SVT:s TV-leaks. Min förhoppning är att fler kan dra lärdomar och således blir säkerheten bättre i längden.

All information nedan är sammanställt med hjälp av öppen information.

Peter Wolodarski som är chefredaktör på DN framhäver på sajten dngranskar.dn.se följande (se även skärmdump ovan):

Vi behöver din hjälp i vårt arbete. De största avslöjandena kommer från människor som har värdefull information. DN lägger stora resurser på granskande journalistik. Här kan du på ett säkert sätt lämna tips till våra undersökande reportrar.

Vidare så läser vi även följande:

Tjänsten är skyddad med hög kryptering för att ge dig som tipsare största möjliga säkerhet. Det innebär att tipset blir oläsligt utan en särskild nyckel. Bara ett begränsat antal reportrar på tidningen har tillgång till denna nyckel.

Denna särskilda nyckel som ovan text refererar till är en PGP-nyckel som ligger inbäddad på webbsidan. Denna nyckel läses sedan av openpgp.js och formulärdata krypteras och skickas över och lagras på serversidan.

Den publika PGP-nyckeln som återfinnes på sidan ser ut enligt följande:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: OpenPGP.js v1.3.0
Comment: http://openpgpjs.org

xo0EViaQEAEEAKGUFnG9PCA3tWCcj2+e6GgRzTSY7hbN5YYurJbNeHsE4SbT
UPHQzGKQsqcyYieIS9Uh/co42E1ndgG4xZSjRZslMWRkTQVCEGTCMPzm0sSE
P8zGndzF/R//FK4AvshSUBa8sLWTp026C2xqAhIvUOvKwRBK9PKclfKZVV/5
zG8zABEBAAHNMktyaXN0b2ZmZXIgw5Zyc3RhZGl1cyA8a3Jpc3RvZmZlci5v
cnN0YWRpdXNAZG4uc2U+wrIEEAEIACYFAlYmkBAGCwkIBwMCCRBMNmcxb9M1
+QQVCAIKAxYCAQIbAwIeAQAAOH0D/1RUQSjmYhkUoGkwLp5HF7Xl6UDYQpoX
8Xdhjb5Aufu/nUgs73nXS2MlycqHqoKGV0a43PzteujQz9gz86nIHrdB7F7l
jLlssUSzD2oePObv4wpK9lBee9HZs980+LWkK3t3yUe6+mixsspZvEAGe/Q0
k50JgxMHFcfj5uCTm3fTzo0EViaQEAEEALCZMwq4sfm59Hq5Z4hOv8pdPtMX
jy26WZBBaZ8csv54UWm7o7Xt2TRkU1eGR6j/UjAXVNZ6jKON10M8I+1nmlpx
ZtS3I9QRja7N0HOn/Mo9et5bHdZKQSHUd1vblRRddHOqU+C4EP+BAKqtR/Ne
y6RxOCaydspT+wJzWCS8dfarABEBAAHCnwQYAQgAEwUCViaQEAkQTDZnMW/T
NfkCGwwAAM/nA/9Ra0Mnr2cIOOFXN/TAeLK0JKG9s/hIa01zGMC9dDub5Q1r
zAiVO/c664MYvtbOOMOf5VeHRPBiVFuxw3Fl4MzX0g61bcHBTMKaT6iF+13l
3zONpw81eAh1fjN8PX4gcwrU6W+N4BTSBHO+3dMWNF9rlK/xGfqLzvXAo+zL
OCbglg==
=Bf3n
-----END PGP PUBLIC KEY BLOCK-----

Den med ett tränat öga ser att ovan nyckel inte ser ut att vara speciellt lång, nämligen enbart 1024-bitar RSA, vilket inte är att rekommendera sedan år 2010. Tittar vi närmare på nyckeln så ser vi även att den står på Kristoffer Örstadius.

Även något som är anmärkningsvärt så används inte denna nyckel när jag testar att skicka in ett tips med Firefox, då ser kommunikationen ut enligt följande:

Gör jag samma med Google Chrome så krypteras all information från formuläret med 1024-bitars nyckeln förutom filnamnet:

Tittar vi på webbservern så svarar den att det är en gammal Apache, openssl med en PHP-version som är end-of-life sedan 2015, dvs inga säkerhetsuppdateringar eller liknande kommer. Red Hat tillhandahåller säkerhetsfixar för dessa versioner efter noggrann kontroll:

Server: Apache/2.4.6 (Red Hat Enterprise Linux) OpenSSL/1.0.1e-fips PHP/5.4.16

Övriga saker att anmärka på är även att cookies för spårning och annonsering följer med från dn.se till dngranskar.dn.se såsom _ga (Google Analytics), optimizelyEndUserId, __couid (Kantar Sifo) och _burtAgency. Openpgpjs som används är version 1.30 och den senaste är 2.3.6.

Även bör headers som meddelar att webbläsare inte bör cacha innehåll användas såsom:

  • Cache-control: no-store
  • Pragma: no-cache

Sajten från A+ från SSLlabs.com vilket är bra och inga tredjepartsscript eller liknande laddas in.

Sammanfattning

Tjänsten är byggd med flertalet IT-säkerhetsbrister. Kommunikationen går över TLS vilket räddar upp situationen en del men informationen lagras troligtvis i klartext på servern när openpgp.js inte fungerar som den ska.

Jag har kontaktat DN innan publiceringen av denna granskning och DN meddelar att en ny sajt lanseras inom kort. Att titta på för inspiration för framtida arbete är SecureDrop som bl.a. The Guardian och NY Times använder.

Uppdatering: DN meddelar att kryptering även genomförs på serversidan av informationen efter den är inskickad.

SecureDrop över Tor som The New York Times använder sig av

Uppdatering: Burp Suites passiva granskning rapporterar 11 st medium-brister och 42 st low:

Windows SMBv3 zero-day

Proof of Concept (PoC)-kod för en ny zero-day har släppts på Github. Koden kan få en Windows-klient att krascha över nätverket i dagsläget (denial of service) men oklart om detta kan leda till något allvarligare.

Det koden gör är simulera en server och skickar då SMBv3-paket som får klienter av typen Windows 8 eller Windows Server 2012 är blåskärma. Detta för att enbart dessa operativsystem och nyare som stödjer version 3 av SMB-protokollet.

För att förmildra eventuell skada så rekommenderas blockering av TCP portar 139 och 445 samt UDP port 137 och 138 in/utgående genom brandväggar.

PCAP finnes här:

Skärmdump från Windows 8 där denna brist utnyttjas:

Allvarlig sårbarhet i McAfee ePolicy Orchestrator

Cisco Talos har upptäckt en blind SQL-injection i McAfee ePolicy Orchestrator. ePolicy Orchestrator är en populär mjukvara i många enterprise-nätverk och något som jag ofta stöter på vid mina penetrationstester.

Sårbarheten har fått CVE-2016-8027 och gäller versioner av ePolicy Orchestrator (ePO) 5.1.3 och äldre, ePO 5.3.2 och äldre.

McAfee ePolicy Orchestrator används för att centralt managera klienter som kör McAfee Antivirus. Klienterna pratar med servern över ett protokoll som heter SPIPE och servern har även en webbserver, Apache Tomcat som går på tcp port 8443.

Sårbarheten ligger i hur klientens GUID-värde (unika klient ID) skickas vidare in mot underliggande databas. På grund av en bristande filtrering så går detta värde direkt in mot databasen. Denna sårbarhet gäller dock enbart http post och inte SPIPE-kommunikationen, klienten kan prata med servern på båda protokoll.

För att förhindra denna sårbarhet bör klienter inte ha möjlighet att ansluta direkt på port 8443 till ePO-servern. Detta bör enbart administratörer ha behörighet att göra.

Det är oklart vad detta får för konsekvenser på klienter som använder servern om sårbarheten utnyttjas. Går det exempelvis att köra godtycklig kod på samtliga klienter?

CVSS3 (Common Vulnerability Scoring System) enligt följande:

8.2 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L

Mer tekniska detaljer om sårbarheten finnes i Cisco Talos detaljerade rapport.

Tarsnap – Backup i molnet för den som är paranoid

Tarsnap är en backuptjänst i molnet för den som är paranoid. Kryptering genomförs på klientsidan innan datan skickas upp till Amazon S3-tjänst. Tarsnap är utvecklat av Colin Percival som är övermänsklig, han har bl.a. utvecklat scrypt och är har varit säkerhetschef för FreeBSD. Givetvis är även tarsnap öppen källkod tillgänglig källkod och mer tekniska detaljer finnes här.

Tarsnap har inget inbyggt grafiskt gränssnitt och stödjer operativsystem såsom Mac OS X, Ubuntu, FreeBSD osv. Stöd till Windows finnes via Cygwin, även så finns det tredjepartskod med GUI.

Så kommer du igång med Tarsnap

Först och främst laddar du hem tarsnap till din server eller klient:

$ wget https://www.tarsnap.com/download/tarsnap-autoconf-1.0.37.tgz

Och verifierar sedan nedladdningen:

$ sha256sum tarsnap-autoconf-1.0.37.tgz
SHA256 (tarsnap-autoconf-1.0.35.tgz) = fa999413651b3bd994547a10ffe3127b4a85a88b1b9a253f2de798888718dbfa

Sedan installerar du eventuella beroenden som kan behövas.

Detta är för Ubuntu:

$ sudo apt-get install libssl-dev zlib1g-dev e2fslibs-dev make

Vi extraherar tarsnap och bygger koden:

$ tar xvfz tarsnap-autoconf-1.0.37.tgz
$ cd tarsnap-autoconf-1.0.37/
$ ./configure && make
$ sudo make install

Och förhoppningsvis gick allt bra och tarsnap är installerat. Om du inte har något konto på tarsnap.com så är det läge att skapa det nu. Det är gratis att skapa ett konto, men du måste sätta in pengar för att betala för lagring och överföring. Du kan betala med Bitcoin, kort eller Paypal.

Nu skapar vi en nyckel för denna server och anger våra login-uppgifter som vi använde när vi skapade kontot på tarsnap.com:

$ tarsnap-keygen --keyfile /root/domän-tarsnap.key --machine domän.se --user [email protected]
$ chmod 600 /root/domän-tarsnap.key

Viktigt här är att du sparar undan nyckelfilen domän-tarsnap.key på ett annat system än det du gör backup på. För förlorar du denna fil så kan du ej återskapa data från servern samt ser till att enbart användaren som gör backup får läsa denna nyckelfil.

Så gör du backup med Tarsnap

Även så fungerar tarsnap precis som tar men med lite extra argument. Jag brukar skapa en fil vid namn backup.sh som även dumpar ut MySQL-databas så den följer med i backupen.

Så här ser min backup.sh ut som körs via cronjobb varje natt av root. Se även till att obehöriga inte kan läsa filen backup.sh då den innehåller lösenord.

mysqldump -u root -plösenord https > /var/www/domän.se/backup/`date +"%Y%m%d"`.sql
tarsnap --keyfile /root/domän-tarsnap.key --cachedir /usr/local/tarsnap-cache -c -f domän.se-`date +%F` /var/www/domän.se/docs/ /var/www/domän.se/backup/ /etc/nginx/sites-enabled/default-ssl /etc/nginx/sites-enabled/default

Du kan även behöva skapa katalogen /usr/local/tarsnap-cache/. Vill du även ta bort äldre backup-filer så kan du göra det med följande rad. Observera att det kan även vara bra med en kontroll att backupen lyckas innan du tar bort äldre backup-filer:

tarsnap --cachedir /usr/local/tarsnap-cache --keyfile /root/domän-tarsnap.key -d -f domän.se-`date -d "2 days ago" +%F`

Glöm inte att testa återställning också vid regelbundna intervaller, det är viktigt.

Kolla även in denna gist som underlättar installationen.

Så håller Google sin molntjänst Google Cloud säker med KVM

Google Cloud använder sig av open-source hypervisorn KVM för dess molntjänster Google Compute Engine och Google Container Engine. Google är ett företag som ställer mycket höga krav på säkerheten och har genomfört ett antal olika säkerhetshöjande åtgärder i KVM.

Genom nedan olika åtgärder så arbetar Google med att höja säkerheten:

  • Proaktivt arbete – Googles erkända IT-säkerhetsforskare arbetar kontinuerligt med att försöka identifiera nya zero-days i KVM och rapporterar dessa tillbaka till KVM-projektet.
  • Reducera attackytan – Genom att ta bort komponenter som inte behövs så kan attackytan reduceras. Sådana delar är exempelvis äldre drivrutiner för möss och tangentbord. Även så begränsar Google den instruktionsuppsättning som KVM emulerar.
  • Använder inte QEMU – Genom att utveckla en egen virtualisering mot hårdvaran kan även attacker minskas. Google har ett begränsat antal hårdvaruplattformar som de behöver stödja som rullar i deras olika datacenters. Även så stödjer Google inte korsarkitektur för olika värd/gäst-kombinationer.
  • Uppstart och kommunikation – Google använder ett unikt förfarande för kommunikation mellan värd och gäst med hjälp av kryptografiska nycklar. Dessa nycklar används för att säkerställa autentisering och auktorisering.
  • Snabba åtgärder – Internt har Google en strikt SLA som medger snabba och effektiv åtgärder vid eventuella säkerhetsbrister.
  • Noggrann releaseprocess – Vid utrullning av nya versioner så används en gedigen kontroll av säkerheten. Enbart ett fåtal anställda vid Google har tillgång till byggsystemet och kan göra ändringar i källkoden.

Tittar vi historiskt på attacker såsom Rowhammer eller Venom så går dessa inte att utföra alternativt så har Google utvecklat övervakningsverktyg för att detektera dessa. Även så genomför Googles säkerhetsteam löpande fuzzing-tester av mjukvaran för att identifiera nya sårbarheter (se bl.a. OSS-fuzz).

På följande föredrag så berättar Googles Andrew Honing även om Googles KVM-säkerhetsförbättringar:

Facebook stödjer nu inloggning med säkerhetsnyckel (U2F)

Facebook meddelade precis att de nu stödjer tvåfaktorsautentisering med hjälp av en hårdvarunyckel. Det är nycklar som stödjer standarden FIDO U2F som är utvecklad av Google samt svenska företaget Yubico.

En Yubikey U2F från Yubico kostar 160kr och går att beställas från Yubicos hemsida (tillkommer frakt på cirka 50kr). Förutom Facebook så stödjer även populära tjänster såsom Dropbox, Salesforce, och Google U2F-enheter sedan tidigare.

Har du en mobiltelefon med Android och NFC stöd så finns det dock ett antal möjligheter för inloggning eftersom dessa enheter oftast inte har USB.

Bild på en Yubikey U2F från Yubico:

 

Test av säkra operativsystemet Qubes OS

Qubes OS är ett säkert operativsystem som använder en lite annorlunda säkerhetsarkitektur om man jämför med OpenBSD som jag testat tidigare. Qubes använder sig av Xen hypervisor som är öppen källkod för att isolera olika applikationer mot olika domäner (operativsystem/VM).

Och Qubes är även Edward Snowdens favorit när det gäller operativsystem:

Följande bild påvisar uppdelningen mellan olika virtuella VMs:

Attackytan från nätverket går direkt mot en egen isolerad domän och administration (grafiskt gränssnitt) ligger i en domän något som kallas för Dom0.

Qubes har funnits sedan 2012 och grundades av Joanna Rutkowska. Senaste versionen 3.2 har bl.a. stöd för att släppa igenom USB-enheter direkt till ett VM. Detta gör att man exempelvis kan använda sig av en Bitcoin hårdvaruplånbok med USB-gränssnitt. Qubes är framförallt framtaget för arbetsstationer och ej servrar.

Installation

Jag hade två laptops att testa Qubes OS på. Tyvärr så bootade inte installationen upp på den ena av dessa. Installationen går ut på att du bränner ut en ISO på ett USB-minne som du sedan startar upp på. Processen att installera operativsystemet tar drygt en timme där manuella moment enbart består av några få frågor.

Hela installationsförfarandet är mycket enkelt och du har även möjlighet att partionera samt kryptera hårddisken vid installationen.

De tre standardsystemen som jag väljer att installera är:

  • Standard, dvs sys-net och sys-firewall
  • Standard applikation-qubes: arbete, privat, vault och untrusted
  • Whonix gw samt arbetsstation. För att köra Tor

Användning av Qubes OS

Den mesta användningen av Qubes görs genom menyn uppe till vänster samt Qubes VM Manager.

Nedan två skärmdumpar visar detta:

Personliga filer och Firefox

Personlig domän med filhantering samt Firefox
Qubes VM Manager som hanterar VM:s

Att starta upp en ny applikation, exempelvis Firefox i den personliga domänen tar enbart några sekunder. Och då startar Fedora upp i en hypervisor och när Firefox startats upp så visas det i mitt gränssnitt.

Observera även på skärmdumpen nedan att titeln på fönstret innehåller namnet personal och färgen är gul.

QubesOS med Firefox i personlig säkerhetsdomän

Säkerhet

Även om uppdelningen mellan VM:ar så hänger säkerheten på operativsystemet som går i respektive hypervisor samt hypervisorn i sig, och i detta fall Xen. Qubes går inte ut med säkerhetsbulletins vanligtvis för sårbarheter som exempelvis drabbar Firefox.

Säkerhetsbuggar som publicerats under 2016 från QubesOS hemsida:

Just den sista sårbarheten ovan är intressant. För den kan påverka det template-system som Qubes använder. All kommunikation till templates går genom brandväggen (sys-firewall) förutom ett undantag och det är uppdateringar som går via tinyproxy, detta för att templates alltid ska ha senaste uppdateringar.

Qubes använder sig även i dagsläget något som heter paravirtualisering (PV) som ställer högre säkerhetskrav på hypervisorn. Detta är dock något som Qubes-utvecklarna ångrar i dagsläget och kommer att gå över till full virtualisering (HVM) från och med version 4 av Qubes OS.

Windows

Det går att köra Windows och då med hårdvaruvirtualisering (HVM). Windows 7 64-bitar stöds när det gäller verktyg som Qubes tillhandahåller: qubes windows tools. Dessa verktyg gör att kopiera/klistra, fönster samt filöverföring fungerar smidigt.

Sammanfattning

Qubes gör att du på ett enkelt sätt kan höja säkerheten avsevärt på din arbetsstation. Med medföljande verktyg så kan du enkelt sköta vardagliga saker såsom surfa säkert, hantera lösenord och sköta ordbehandling.

Framförallt är det enkelt och komma igång om du känner dig hemma med Linux sedan tidigare.