Uppdatering: Sårbarheten (sårbarheterna) är nu officiell och den återfinnes i CUPS. CUPS används för att hanter utskrifter. Läs mer på Simones blogg här men kontentan är att för den allvarligaste så behövs det enbart UDP-paket mot 631 där cups-browsed återfinnes. PoC återfinnes även här.
En säkerhetsforskare vid namn Simone Margaritelli (evilsocket) har på X (föredetta Twitter) skrivit att han identifierat en sårbarhet som fått CVSS score på hela 9.9 och påverkar majoriteten av all Linux-baserade operativsystem samt FreeBSD. Huruvida andra BSD OS såsom OpenBSD är sårbart, är oklart just nu.
Det har spekulerats en hel del var sårbarheten ligger bl.a. för att en ny version av OpenSSH släpptes precis som bl.a åtgärdar en del pre-auth prylar samt tar bort stöd för DSA i större utsträckning.
Datum som gäller framöver för denna sårbarhet:
September 30: Information på Openwall security mailing list.
Oktober 6: Full public disclosure
Observera att det fortfarande är oklart gällande omfattningen av denna sårbarhet.
Uppdatering: Evilsocket har nu stängt sin X-profil, här återfinns skärmdump av inlägget:
Inom cybersäkerhet så har det på senare tid blivit populärt att prata om hur man kan analysera och begränsa attackytan, engelska: Attack surface reduction (ASR). Och jag har som vanligt funderat en hel del på området: Det är av stor vikt att organisationer har en insikt och förmåga att förstå sin attackyta.
Tittar man först och främst från internet där majoriteten av alla cyberattacker sker från så ser attackytan ut enligt följande:
Tjänster, servrar och enheter som är exponerade mot internet
Annan utrustning som kopplas upp såsom switchar, kopiator/scanner, laptops och mobiltelefoner
Indirekt attackyta, dvs sådant som kan bifogas med E-post och hamna hos en anställd. Eller när en anställd surfar ut eller på annat sätt ansluter utåt
Supply Chain. Mjukvaruppdateringar, hårdvara som köps in, firmware osv
Via en annan leverantör eller kund. Tänk exempelvis delad hosting
WiFi, bluetooth och andra uppkopplingar såsom VPN
Via molntjänster eller molnleverantörer
Finns säkert fler sätt än ovan som attacker kan ske men viktiga här är att begränsa och isolera samtliga områden där attacker kan genomföras. Ni som organisation måste förstå i detalj vad det innebär att exponera tjänster såsom Apache, Nginx eller Microsoft IIS.
Är det så att ni exponerar en webbserver, vad har den för TCP/IP-stack, TLS-implementation osv? Och kollar vi längre upp i lagret, vad har ni för API:er exponerade? Har ni köpt en on-premise appliance eller någon annan form av magisk låda, så har denna troligtvis en hel del funktioner så ni inte känner till som exponeras utåt.
För det är inte en fråga om ni kommer att bli hackade, utan en fråga om när. Och då måste ni ha verktyg att upptäcka denna attack. Övervaka därför samtliga kanaler på både insida och utsida och titta efter avvikande mönster. Om webbservern pratar TLS 100% av fallen så ska inte helt plötsligt förekomma klartext (annat än just sådant som kan förekomma i protokollet).
Jag gillar OpenBSD-teamets filosofi där allt ska vara avstängt från start och behöver du någon funktion eller tjänst så måste du aktivt aktivera denna ”secure by default”.
På klienter som används mot internet bör därför så lite funktioner, applikationer och dylikt användas. Tittar man på en standard Windows-installation så stödjer denna runt 600-700 olika filformat där många kan användas för att utnyttja eventuella sårbarheter.
Sammanfattning
Tänk så här: Desto mindre rader kod ni exponerar direkt eller indirekt mot internet eller andra attackvägar in mot Er organisation, desto säkrare blir ni. Bryt ner attackytan även mot individuella tjänster och portar som exponeras.
Isolera servrar, tjänster och annat som går att nå direkt från internet. Övervaka dessa tjänster och titta efter avvikande beteenden. Förändringar i attackytan över tid är också viktig att uppmärksamma.
Om någon lyckas få åtkomst till Er mail från internet, eller VPN eller annat som används remote. Vad får det för konsekvenser? Testa och granska, med exempelvis penetrationstester eller red-teaming.
En ny säkerhetsbrist har identifierats i mjukvaran sudo. Sudo som installeras som standard i många operativsystem är som standard setuid root. Det innebär att eventuella brister kan leda till att lokala användare kan erhålla root-behörigheter.
Med åren har också sudo blivit större och fler funktioner har tillkommit. Detta har bl.a. lett till att OpenBSD nu har ett alternativ som heter doas.
Igår så rapporterade det amerikanska säkerhetsföretaget Qualys att de identifierat en sårbarhet i sudo (CVE-2021-3156). Sårbarheten medger att en lokal användare kan utnyttja en heap-sårbarhet och således bli root. Buggen har funnits sedan 2011 och återfinnes i standardkonfigurationen. Att det just finns med i standardkonfigurationen är viktigt att poängtera eftersom många sårbarheter som uppdagats i sudo kräver speciella konfigurationer.
Sårbarheten återfinnes i funktionen set_cmnd() och kan enklast triggas enklast genom att använda sudoedit och följande kommando:
sudoedit -s '\' `perl -e 'print "A" x 65536'`
Och är du sårbar så får du en segfault. Observera att du behöver lokalt konto men inte medlem i sudoers eller motsvarande. Samt att alla installationer inte har sudoedit, såsom macOS.
Video från Qualys som förevisar sårbarheten:
Om du som jag undrar lite över sudos logotyp, så se XKCD här.
De senaste dagarna så har det publicerats två intressanta sårbarheter som jag tänkte skriva några rader om, den första är en ”VPN bugg” som påverkar många olika typer av VPN-anslutningar och den andra handlar om en miss i operativsystemet OpenBSD som medger att flertalet autentiseringsmekanismer går att kringgå.
OpenBSD
Denna sårbarhet har CVE 2019-19521 och upptäcktes av säkerhetsföretaget Qualys. Även så finns det ett antal relaterade sårbarheter enligt följande:
CVE-2019-19520: Local privilege escalation via xlock
CVE-2019-19522: Local privilege escalation via S/Key and YubiKey
CVE-2019-19519: Local privilege escalation via su
Men den allvarligaste medger att du över nätverket (remote) kan kringgå autentiseringen i flertalet program såsom smtpd, ldapd och radiusd.
Det är nämligen så att programmet login_passwd anropas vid autentisering. Och om informationen som skickas vidare till login_passwd innehåller -schallenge som argument så returneras lyckad inloggning, se följande exempel:
Denna sårbarhet går under CVE 2019-14899 och medger att en angripare kan injicera data i en VPN-tunnel eller lista ut vilken IP som blivit tilldelad inne i en tunnel. Denna sårbarhet påverkar flertalet Linux OS, FreeeBSD, OpenBSD, Android och macOS.
Kortfattat kan man säga många operativsystem som etablerar VPN-tunnlar inte bryr sig om vilket gränssnitt som data kommer in på. Så om du har ett tunnel-gränssnitt och data helt plötsligt kommer in på ett annat gränssnitt så funkar det lika bra.
Och Colm MacCárthaigh som jobbar på Amazon meddelar att Amazon Linux inte påverkas men att attacken kan bli ännu mer allvarlig om DNS kan påverkas inne i VPN-tunneln:
Hijacking traffic via DNS is usually much more powerful than payload injection; for example an attacker can observe all connections but choose to target only connections that do not use TLS. This is more flexible and helps evade detection.
Mer omfattande information hittar du i följande PDF samt följande två intressanta patchar till OpenBSD:
Ett av världens kanske säkraste operativsystem är nu ute i en ny version. Det handlar så klart om OpenBSD och den nya versionen som har fått versionsnummer 6.1:
We are pleased to announce the official release of OpenBSD 6.1.
This is our 42nd release. We remain proud of OpenBSD’s record of more than twenty years with only two remote holes in the default install.
Denna nya version innehåller ett antal höjdpunkter som är enligt följande:
syspatch för enkel binärpatchning av i386 samt amd64-system. Laddar hem och installerar nya säkerhetsfixar.
acme-client för den som vill skapa Let’s Encrypt SSL-certifikat.
xenodm som är en ny standard display manager
Libressl samt OpenSSH som innehåller mängder med förbättringar och säkerhetsuppdateringar.
Det är nu möjligt att köra Linux under virtualiseringsmotorn vmm/vmd som följer med som standard i OpenBSD
Förbättrat stöd för trådlösa nätverkskort (802.11)
Att ladda hem och installera OpenBSD går snabbt och smidigt. ISO-filen är enbart 200 MB och själva installationen tar max 5 minuter för den som är någorlunda ninja på BSD:
Sedan när systemet är installerat och Chromium installerat så testar jag att surfa in till kryptera.se.
Givetvis fungerar även doas (istället för sudo), figlet, xeyes och xlogo tillfredsställande:
OpenBSD 6.1 skärmdump
Jag har även tidigare testat OpenBSD, läs mer här:
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:
If you're serious about security, @QubesOS is the best OS available today. It's what I use, and free. Nobody does VM isolation better. https://t.co/FyX5NX47cS
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.
För några dagar sedan så släpptes en ny version av det säkra operativsystemet OpenBSD. Denna nya 5.9-version har en ett antal intressanta nya säkerhetsfunktioner såsom pledge. Pledge är en ny typ av sandlåde-liknande funktionalitet som begränsar vad enskilda program får och inte får göra.
Pledge är enkelt att implementera i sitt program och följer ett regelverk som berättar om programmet får öppna nätverkskommunikation, skriva/läsa filer osv. Kontrollen sker sedan i kerneln att programmet håller sig inom ramarna.
Viktigt att notera är också att den nya pledge-funktionen inte är någon silverkula som löser alla problem. Men som många andra saker som OpenBSD tar till sig så höjer det säkerheten i det stora hela tillsammans med tekniker såsom W^X, ASLR och ProPolice.
För att demonstrera hur enkelt det är så titta på följande kodrader som begränsar vad kommandot ping får göra:
if (options & F_NUMERIC) {
if (pledge("stdio inet", NULL) == -1)
err(1, "pledge");
} else {
if (pledge("stdio inet dns", NULL) == -1)
err(1, "pledge");
}
Första argumentet till pledge()-anropet är en lista med tillåta anrop, se man-sidan för mer info om dessa:
inet – Tillåter nätverkskommunikation med anrop såsom socket, listen, bind, getpeername.
dns – Tämligen självförklarande. behövs enbart om användaren ej specificerar argumentet -n
Det var väl enkelt? Än så länge använder sig 453 av 707 program pledge, av OpenBSD:s grundinstallerade program. Även så använder sig använder 14 st externa program av pledge såsom mutt, chrome och i3.
Jag testar OpenBSD under VirtualBox och det tar under 10 minuter att ladda hem samt komma igång med operativsystemet. Installationsförfarandet har blivit avsevärt mycket smidigare på senare år med exempelvis automatiskt partitionslayout.
Sedan ett tag tillbaka så följer kommandot doas med i grundinstallationen av det supersäkra operativsystemet OpenBSD. Doas är tänkt att användas istället för sudo (substitute user do) och vara ett säkrare alternativ.
Sudo har med tiden växt att bli ett monster som kan göra allt för alla och därmed även ökat riskerna för eventuella sårbarheter vilket nu uppdagades i samband med glibc DNS-buggen.
As shipped in OpenBSD, the compiled sudo was already five times larger than just about any other setuid program
Och för att komma igång med doas på OpenBSD så behöver du bara skapa en konfigurationsfil i /etc/doas.conf. Och tittar vi på exempel i manualsidan för doas.conf så finner vi följande:
$ doas id
uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest)
Perfekt. Det fungerar, men för att vara på den säkra sidan så tar vi bort ordet ”nopass” från konfigurationsfilen och vi får då istället skriva in lösenordet varje gång.
Sedan är det bara att ta bort sudo-paktet med pkg_delete och för att underlätta tillvaron så kan även ett alias för sudo kopplas mot doas.
Oklart i dagsläget när eller om doas kommer att porteras till andra operativsystem. Men lämna gärna en kommentar om du känner till något annat OS där doas finns.
doas är primärt skrivet av OpenBSD-utvecklaren Ted Unangst och du kan läsa mer om hans tankar bakom i denna bloggpost:
Theo de Raadt som är chefsutvecklare för OpenBSD skickade nyligen ut ett meddelande gällande rykten om att FBI skulle ha lagt till enbakdörr i OpenBSDs IPSec implementation. OpenBSD är öppen källkod vilket medger att vem som helst kan granska koden och upptäcka en eventuell bakdörr.
Här är meddelandet från Gregory Perry till Theo de Raadt:
Long time no talk. If you will recall, a while back I was the CTO at NETSEC and arranged funding and donations for the OpenBSD Crypto Framework. At that same time I also did some consulting for the FBI, for their GSA Technical Support Center, which was a cryptologic reverse engineering project aimed at backdooring and implementing key escrow mechanisms for smart card and other hardware-based computing technologies.
My NDA with the FBI has recently expired, and I wanted to make you aware of the fact that the FBI implemented a number of backdoors and side channel key leaking mechanisms into the OCF, for the express purpose of monitoring the site to site VPN encryption system implemented by EOUSA, the parent organization to the FBI. Jason Wright and several other developers were responsible for those backdoors, and you would be well advised to review any and all code commits by Wright as well as the other developers he worked with originating from NETSEC.
This is also probably the reason why you lost your DARPA funding, they more than likely caught wind of the fact that those backdoors were present and didn’t want to create any derivative products based upon the same.
This is also why several inside FBI folks have been recently advocating the use of OpenBSD for VPN and firewalling implementations in virtualized environments, for example Scott Lowe is a well respected author in virtualization circles who also happens top be on the FBI payroll, and who has also recently published several tutorials for the use of OpenBSD VMs in enterprise VMware vSphere deployments.
Merry Christmas…
Gregory Perry
Chief Executive Officer
GoVirtual Education
Det har åtskilliga gånger på sistone kommit på tapeten hur webbutvecklare bygger dåliga lösenordsfunktioner utan salt, eller lagrade direkt i klartext exempelvis.
Det amerikanska IT-säkerhetsföretaget Matasano försöker reda ut vad som är bra och vad som är dåligt gällande säkra lösenordshashar:
Varför är just OpenBSD:s lösenordsfunkion så bra
Varför går vissa lösenord att knäcka med regnbågstabeller (rainbow tables)
Ett av världens kanske säkraste operativsystem är nu ute i en ny version. Det handlar så klart om OpenBSD och den nya versionen som har fått versionsnummer 6.1:
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.
stdio – Grundläggande systemanrop (syscalls) tillåts. Såsom close, dup, mmap, pipe osv.
