Linus Tech Tips nu tillbaka på internet

Man har naturligtvis inte löst alla problem, men ett av dem iaf...

Inte så konstigt egentligen, I många Linux distributioner så gnäller GUI:t till direkt om du försöker exekvera en binär på detta viset (och vissa blockar det helt om binären kommer via mail eller från en zip-fil) och det är en av punkterna som Windows-användare som testar på Linux gnäller röven av sig om att det är "icke användarvänligt".

En session token är ofta helt frikopplad från den ip där den skapades. Ofta för att man ska kunna stödja B2B lösningar, säg t.ex att du loggar in hos din bank för att se börskurser, banken själv driftar inte dessa utan de tar dem från 3:e part och denna 3:e part använder en session-token för att garanter att det är banken som tar data, samtidigt vill inte banken ge ut sin inloggningsdata mot 3:e parten till dig så därför skapar de en session token mot 3:e parten behind-the-back och ger dig denna token så att din browser sedan kan kommunicera direkt mot 3:e parten mha denna token.

Och då skulle ju inget fungera om denna token var bunden till en ip-adress. Sen kan man tycka att just en inloggnings sessions-token mot YT borde vara bunden till ip för kan inte se hur/varför den skulle kunna användas B2B (och skulle den det så kunde man ju ha det som ett val vid skapande av token).

Jag var faktiskt under intrycket att attacker via RTLO-metodik var ett utagerat kapitel. Tydligen är det inte över ännu, även fast OS egentligen vet att maskerad pågår.

Som många nämnt i tråden så borde det givetvis finnas flera saker implementerat mellan en stulen sessionskaka och total blackout på Google YouTube, och det finns säkerligen flera saker att arbeta med från båda håll beträffande hur stöld går till och varför det är stöldbegärligt samt allt däremellan.

LMG som använder företagslösning med Google ("Workspace") har förmodligen inofficiellt haft det litet svettigare än att själva YouTube-delen blankades, men delar med domäner och mail osv kanske har haft bättre säkerhet.

Det skall bli intressant att få höra en mera utförlig redogörelse kring det inträffade i kommande WAN Show.

"När det kommer till ansvar för händelserna pekas inget finger på någon specifik person eller organisation och inga reprimander kommer ges. I stället tar Linus ansvar för situationen och trycker på vikten att sätta säkerhetsrutiner inom företaget, så inte liknande händelser sker i framtiden. Ansvaret läggs dock på Google som, trots sin effektivitet i detta fallet, bör se över sina verktyg för att liknande händelser inte ska kunna ske i framtiden."

Det låter som en fantastisk chef. "Det är mitt ansvar. Men egentligen är det någon annans."

Så det hela var användare problem

När Paul hibbert träffa på den för några veckor sen och han blev tillfälligt av med sin kanal så skannade han den. Ren och fin sa Windows defender. Möjligt att något annat program hade fångat det men svårt att veta.
I hans fall var det ett script makertat som en pdf med logga och en sbc eller liknande ändelse. Kan till och med varit pdf.sbc sen tror jag Windows numera gömmer filändelser by defualt ? Ännu svårare att fånga i sådana fall.

Scr var det hos Hibbert, dvs en fil ursprungligen tänkt som skärmsläckare, men som är en sorts exekverbar fil. Ja, Windows har länge dolt filändelser som standard och det är en av de första sakerna jag ställer om. Det började nog för över 20 år sedan.

Han hade ansvar att utbilda sin personal att bli bättre på att inte klicka på vadsomhelst, att kanske inte låta alla vara inloggade sådär osv. Dock precis som dom säger så har Google OCKSÅ ett ansvar att sköta sin sida bättre. Kolla videon istället så förklarar han det väldigt fint.

Går det inte att låsa session cookies till maskinen via TPM eller dylikt? Anti-Cheat bolagen verkar vara väldigt duktiga att beräkna fram ett maskin-id från hårdvaran som är installerad i systemet. Men jag är blott en lekman så någon annan här kanske har bättre koll?

Nej, därför att webservern inte har tillgång till det.

Tekniskt sett är det inte omöjligt att göra, men det skulle kräva lokal mjukvara som först pratar med TPM och till exempel installerar certifikat på ett VSC eller liknande, sen kan webbläsaren använda det certet för auth. Då skulle man kunna se till att det är samma dator och att användaren kan pinkoden till certet

Men det kräver en helt annan nivå av infrastruktur att få till och inget som kan lösas av bara webbläsaren och webbtekniker

Det stod i videon att googles är tidsbegränsade och han bara tog upp det som ett exempel.

Väldigt konstigt att session Tokens inte är låsta till specifik dator/enhet. Typ att när session token skapas så läser den av serie nr eller whatever vad vet jag av datorn/moderkort/(insert enhet). Så den bara funkar på den specifika enheten den skapades på.
Och Hur i helvette tillåts en session token köras på olika IPn.
Om en token är skapad på LTTs (ja eller hos vem som helst) IP adress o sen helt plötsligt kopplar samma token upp från en helt annan IP-range tom kanske från annat land. Att den inte blir blockad då.

OTP är ju inte heller det, framförallt TOTP kan ju enkelt köra exakt samma QR-kod på 10 enheter utan att serversidan kan se någon skillnad alls

Kan inte clienten signera session token när den skapas och sedan skicka den till serven? Behöver servern veta mer än att ”session token xxx” och att den är signerad och måste ha den signaturen för att vara giltig?

Ett program som bara läser sessiondata är ju inte direkt suspekt. Denna funktion har ju de flesta webbläsare för att kunna importera inställningar från andra webbläsare... Att sedan skicka data till en server är ju inte heller suspekt, exempelvis för att kontrollera om det finns en ny version, eller för att skicka data till ett API. Som sagt, bägge aktiviteterna är helt normala, så det är nog svårt för ett antivirus att flagga ett sådant program som skadligt.

Skärmsläckare är helt vanliga exekverbara filer (.exe-filer), men i tidigare versioner av Windows gick det bara att välja .scr-filer som skärmsläckare.

I Windows 11 verkar det inte längre gå välja 3-partsskärmsläckare, vilket jag personligen tycker är bra, med tanke på risken.

Och varför filändelser är dolda som standard, för kända filtyper, är ju helt obegripligt med tanke på hur det ökar risken för att någon av misstag eller okunskap öppnar en exekverbar fil.

Att man tillåter samma token från flera enheter och IP-adresser tror jag beror på att man vill göra användarupplevelsen så smidig som möjlig. Att tvingas logga in varje gång man byter enhet är irriterande och speciellt sociala medier gör nog allt för att minimera irritationsmomenten så mycket som möjligt.

Och för mobilanvändare som använder mobildata, så byts nog IP-adressen ganska frekvent, så att tvingas logga in efter att man åkt igenom en tunnel där man tappar uppkopplingen, och vid återanslutning får en ny IP-adress, skulle nog de flesta reta sig rätt mycket över

Jo för att kolla på content o sånt ja.
Men för stora admin grejer som att byta namn på en kanal, radera videos osv borde det ju inte funka så. Åtminstonde borde man ju få skriva in password o 2FA igen om man ska göra sånna stora förändringar.
Eller t ex om man ska ändra 10-100-1000 videos samtidigt.
Men för att scrolla social media o lägga upp nån bild hit o dit så nej.

Jag håller med till fullo.

Sen vore det ju bra om man som användare kunde välja om man vill kunna logga in med samma token mellan olika enheter eller om ens token ska vara knutet till den specifika enheten och/eller IP-adressen.

Man skulle kunna byta processen mot någon form av Public-key authentication, men det skulle kräva stöd för det i webbläsaren, samt att många system (speciellt hemma byggen) inte har TPM.

Sen har du också frågan på hur många nycklar som systemets TPM kan lagra; lagrings kapaciteten är inte särskilt stor.

Därefter måste du fortfarande ha något som bestämmer när din "session token" ska förnyas och hur denna session token ska se ut (servern måste skicka något) - så länge som en sådan refresh inte gjorts är du sårbar för en replay-attack och det räcker med att stjäla den signerade session token. Detta är lösbart, men har en viss overhead.

Tack för bra förklarat!
Kan man inte göra någon form av DH handskakning när Session kakan ska skickas över där clienten bekräftar sin identitet?