Taggat med: google

Ny tjänst från Google: VirusTotal Monitor

VirusTotal som ägs av Google sedan några år är en bra tjänst för den som vill kontrollera om filer innehåller skadlig kod. Mer än 70 st olika antivirus-motorer söker igenom den fil som du laddar upp till VirusTotal.

Stöd Kryptera.se via Patreon >

Men ett problem för de som utvecklar mjukvara eller operativsystem är att ibland så blir deras filer felaktigt flaggade som skadlig kod. Så därför har VirusTotal släppt en ny tjänst vid namn Monitor som låter mjukvaruutvecklare att ladda upp filer som de utvecklat.

Det finns flertalet fördelar med detta, dels så får utvecklaren och antivirus-leverantören larm om någon av dessa filer ger utslag vid genomsökning. Dels kan jag få en verifikation att filen jag laddade upp ingår eller är en känd mjukvara.

Tidigare har även VirusTotal delat med sig av alla filer som laddats upp men nu kommer dessa filer som laddas upp inom Monitor enbart delas till AV-leverantörer om de flaggas med skadlig kod.

För de utvecklare som har en utvecklingspipeline så finns det även möjlighet att ladda upp filer via ett REST API.

Exempel på hur det kan se ut om du laddar upp en fil till VirusTotal som matchar mjukvara från HP:

Skärmdump från VirusTotal Monitor:

Twitterstorm mot Yubico

Uppdatering: Markus har nu skrivit ett blogginlägg om händelsen. Tipstack till John

Uppdatering 2: Yubico har gjort en pudel och uppdaterat sin blogg.

En twitter-storm har uppstått på grund av att Yubico hävdas ha kopierat forskning som presenterats under konferensen Offensive Con av Markus Vervier samt antisnatchor.

Forskningen som presenterades under konferensen påvisar en eller flera svagheter i WebUSB som används av bl.a. 2FA nycklar såsom Yubikeys. Chrome stödjer WebUSB och delade ut en belöning på $5000 till Yubico som i sin tur donerade pengarna till Girls Who Code, här kan du hitta Yubicos advisory ”WebUSB Bypass of U2F Phishing Protection”.

Yubico hävdar dock att det säkerhetsproblem som upptäcktes av dem var mycket större än det som presenterades av Markus och antisnatchor:

Our own researchers quickly discovered there was a broader set of security concerns within WebUSB that affected the entire ecosystem of FIDO U2F authenticators

En av många twitterinlägg från upprörda personer:

Den som vill se presentationen från Offensive Con så finns den här:

Snart går Google CTF av stapeln

Den 23:de Juni är det dags för andra året av Googles egna säkerhetsinriktade Capture the Flag-tävling (CTF). Förra året var det första och då vann ett lag från Israel vid namn pasten:

Årets tävling börjar den 23:de Juni och körs live via Internet. Det finns möjlighet till grymma priser såsom checkar och swag.

Förra årets högsta pris var en check på 13337$ vilket är cirka 116000 SEK.

Nytt för detta år är att det kommer att finnas en övning även för nybörjare som kommer att likna en riktig miljö där målet är att genomföra ett penetrationstest.

För den som vill vara med besök: capturetheflag.withgoogle.com

Det finns också ett antal intressanta Write-Ups från förra året att läsa här:

https://drive.google.com/drive/folders/0BwMPuUHZOj0nZ2dGZS1KbWNGN0E

Ny intressant sårbarhet i Redhat Linux

En säkerhetsforskare på Google har identifierat en sårbarhet i operativsystemet Redhat Linux och dess derivat såsom Fedora. Sårbarheten återfinnes i DHCP-hanteringen och gör det möjligt för en angripare på samma nätverk att exekvera kod (RCE).

Så här skriver Redhat i det varningsmeddelande som publicerats:

”A malicious DHCP server, or an attacker on the local network able to spoof DHCP responses, could use this flaw to execute arbitrary commands with root privileges on systems using NetworkManager and configured to obtain network configuration using the DHCP protocol.”

Sårbarheten med CVE-2018-1111 är så enkel att utnyttja att den får plats i en tweet:

Och det är klart att det blir problem, för tittar man närmare på den kod som hanterar DHCP-parsningen i ett shellscript via NetworkManager:

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.

Snabbare fuzztester med taviso loadlibrary

Tavis Ormandy (taviso) på Google har släppt ett nytt verktyg som underlättar fuzztester av mjukvaror. Verktyget heter loadlibrary och gör att dynamiska bibliotek (DLL:er) från Windows kan köras på Linux.

Vid storskaliga fuzztester är det viktigt med så lite overhead som möjligt för att inte slösa resurser på onödiga saker. Därför utvecklade taviso verktyget loadlibrary för att enkelt kunna skapa små containers med Windows-DLL:er och sedan fuzza dessa DLL:er i en storskalig miljö. Google har även sedan tidigare utvecklat verktyget OSS-fuzz som just är ett ramverk för att snabbt och enkelt göra fuzzing av mjukvaror.

Fuzz-tester är en metodik för att skicka in mer eller mindre slumpmässig data på olika sätt och sedan se hur ett program beter sig. Och kan då upptäcka en mängd olika sårbarheter såsom buffer-overflows, integer underflows osv.

Taviso har med hjälp av loadlibrary identifierat en allvarlig sårbarhet i bl.a. Microsofts antivirus-motor vid namn Microsoft Malware Protection Engine, Mpengine.dll (Windows Defender).

Exempel på hur Mpengine kan köras på Linux för att genomsöka filen eicar.com efter Eicar-testvirus:

$ ./mpclient eicar.com
main(): Scanning eicar.com...
EngineScanCallback(): Scanning input
EngineScanCallback(): Threat Virus:DOS/EICAR_Test_File identified.

Till skillnad från Wine som kör hela Windows-applikationer så kör taviso-loadlibrarykod från enstaka DLL:er.

Här kan du ladda hem loadlibrary från Github:

Obligatorisk Dilbert:

Nyheterna i Transport Layer Security version 1.3 (TLS 1.3)

SSL och TLS har under lång tid säkrat upp en betydande del av den krypterade kommunikationen på Internet. Sedan SSL version 1.0 släpptes internt hos Netscape Communications år 1994 så har det hänt en hel del.

Den nya versionen som just nu håller på att utvecklas inom en arbetsgrupp hos IETF har versionsnumret 1.3 där målsättningen är högre prestanda samt tillhandahålla en ännu högre säkerhet. Man kan säga att designkriteriet för denna nya version är ”less is more” och det innebär att en hel del föråldrade krypton har fått stryka på foten:

  • RSA är borttaget – RSA tillhandahåller inte Forward Secrecy
  • Svaga Diffie-Hellman grupper kan inte användas (SSL_OP_SINGLE_DH_USE)
  • CBC är borta – Är orsaken till attacker såsom Lucky13 och BEAST
  • RC4 samt SHA1 får inte längre användas
  • Export-algoritmer (ansvarig för attacker såsom FREAK, LogJam etc)
  • Nytt är ChaCha-Poly1305 samt stöd för OCB-modes (tipstack till Joachim Strömbergson)
  • Algoritmen för RSA-padding är Probablilistic Signature Scheme (PSS)
  • Nytt meddelande av typen EncryptedExtension. Som nu är krypterat, tidigare skickades många okrypterat

När det gäller prestanda så har ett antal åtgärder införts:

  • 0-RTT samt 1-RTT

Genom att få ner antalet TCP-paket som måste skickas fram och tillbaka vid varje anslutning så kan snabbare TLS (och webbsidor etc) uppnås.

Här följer en bild hur 1-RTT ser ut där klienten skickar ett ClientHello direkt, samt så gissar klienten vilka krypton som kommer att användas:

När du sedan har en session etablerad så kan sedan 0-RTT användas vid senare tillfälle (Session Resumption) men detta möjliggör dock återuppspelningsattacker.

Vill du redan nu testa TLS 1.3 i Google Chrome så kan du göra följande:

  1. Skriv in ”chrome://flags/” i adressbaren och trycker enter
  2. Gå till ”Maximum TLS version enabled.” och välj ”TLS 1.3”
  3. Starta om Chrome

Och vill du testa med Firefox så behöver du ladda hem senaste nightly-build där TLS 1.3 är påslaget som standard.

Och nu när vi besöker kryptera.se och tar upp Developer Tools (DevTools) så synes följande:

Viktigt att tillägga är att TLS 1.3 inte är färdigt ännu och ändras löpande. Detta gör att mjukvara såsom OpenSSL är försiktiga med att göra förändringar. Den senaste uppdateringen till TLS 1.3 heter draft-19 och släpptes för cirka 2 veckor sedan.

För att exempelvis Nginx ska stödja TLS 1.3 så måste även OpenSSL stödja detta. Och OpenSSL kommer med stöd inom några veckor i version 1.1.1.

Uppdaterad 2017-12-27: Enligt Cloudflare är det bara %0.06 av webbläsarna som använder TLS 1.3 och detta beror främst på att många mellanlådor inte stödjer TLS 1.3.

Uppdaterad: 2017-06-06, användes internt hos Netscape. Inte Mozilla som grundades först många år senare.

Google släpper E2EMail

Google har länge satsat på olika lösningar för End-to-end kryptering. Flertalet av dessa bygger på Googles JavaScript-biblioteket med namnet End-to-end och återfinnes på Github.

E2EMail har utvecklats som ett Chrome-plugin ovanpå End-to-end och har nu kopplat sina trådar till Google. Detta för att End-to-end ska vara ett community-baserat plugin och inte enbart något som Google handhar, vilket också är bra för säkerheten att fler engagerar sig och utvecklar vidare.

Tyvärr så är PGP inte lätt att använda och det är lätt att göra fel vilket E2EMail hjälper till med. Utvecklingen av E2EMail har pågått under tre års tid och är även tänkt att hjälpa GMail användare att skicka och ta emot krypterad E-post.

Än så länge finns inte E2EMail i Chrome Web Store utan du måste själv clona Github-repot och kompilera koden.

För att installera genomför följande steg:

$ git clone https://github.com/e2email-org/e2email
$ cd e2email
$ ./do.sh setup
$ ./do.sh build

Sedan så ligger det en Chrome-extension under mappen build/e2email som du installerar i Chrome genom att gå in under Settings -> Extensions och slå på Developer Mode. Där väljer du sedan Load unpacked extension och välj den extension du just kompilerade.

SHA-1 har nu blivit knäckt av Google – Ska vi vara oroliga?

Google släppte precis en bomb där de skriver att de lyckats att genomföra kollisionsattacker mot SHA-1. Som proof-of-concept så har man skapat två PDF-filer med olika innehåll men samma SHA-1 checksumma.

Att fasa ut SHA-1 är något som påbörjades för många år sedan men det har tyvärr gått långsamt och SHA-1 används fortfarande på många ställen såsom Git, Firefox, certifikat, Windows, PGP, TPM-chip osv. Teoretiska attacker mot SHA-1 presenterades redan 2013, så att det nu går att genomföra praktiskt är inte helt förvånansvärt.

Den grupp som skapat denna nya kollisionsattack består av personer från Google och CWI Amsterdam. Attacken går under namnet SHAttered och mer information återfinns på nedan infografik samt på sajten shattered.io.

Dock krävs det fortfarande en hel del beräkningskapacitet för att genomföra attacken och Ars Technica har räknat på detta:

Had the researchers performed their attack on Amazon’s Web Services platform, it would have cost $560,000 at normal pricing. Had the researchers been patient and waited to run their attack during off-peak hours, the same collision would have cost $110,000. That’s within the $75,000 to $120,000 range CWI’s Stevens projected in late 2015.

Att forskarna använder just PDF-filer är för att det är relativt lätt att lägga in godtycklig padding.

Som tur var så finns det även ett verktyg på Github för att detektera denna attack.

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: