Dus je hebt misschien gekregen a Slack wachtwoord reset prompt. Bij ongeveer een half procent van Slacks gebruikersbestand was hun wachtwoordhash mogelijk zichtbaar gemaakt door een vreemde bug. Bij het verzenden van gedeelde uitnodigingskoppelingen werd de wachtwoordhash naar andere leden van de werkruimte verzonden. Het is een beetje moeilijk om erachter te komen hoe dit exacte probleem is ontstaan, aangezien wachtwoord-hashes nooit naar gebruikers op deze manier mogen worden verzonden. Mijn gok is dat andere gebruikers een statusupdatepakket kregen toen de link werd gemaakt, en een logische fout in de code resulteerde in het verzenden van te veel statusinformatie.

Het bewijs suggereert dat de eerste persoon die de bug opving, een onderzoeker was die het probleem half juli onthulde. Slack lijkt een gezond wachtwoordbeleid te gebruiken, waarbij alleen gehashte, gezouten wachtwoorden worden opgeslagen. Dat klinkt misschien als een ontbijtrecept, maar het betekent alleen dat wanneer je je wachtwoord typt om in te loggen om te verslappen, het wachtwoord door een cryptografische hash in één richting gaat en de resultaten van de hash worden opgeslagen. Zouten is het toevoegen van extra gegevens, om te maken een voorberekeningsaanval onpraktisch. Slack verklaarde dat zelfs als deze bug werd gebruikt om deze hashes vast te leggen, ze niet kunnen worden gebruikt om rechtstreeks te authenticeren als een getroffen gebruiker. Het normale advies over het aanzetten van 2-factor authenticatie geldt nog steeds, als extra beveiliging tegen misbruik van gelekte informatie.

En Tu Twilio

Niet te worden overtroffen, Twilio heeft zojuist een lopend probleem onthuld, maar dit was een actieve social engineering-aanval. Het begon als een gerichte phishing-campagne tegen Twilio-medewerkers, en toen medewerkers voor de valse inlogpagina vielen, gebruikten de aanvallers de vastgelegde inloggegevens om toegang te krijgen tot interne tools en toegang tot eindgebruikersgegevens. Van bijzonder belang is dat deze phishing-pogingen succesvol waren omdat ze waren gericht op bekende Twilio-medewerkers, gebruikmakend van de juiste telefoonnummers en namen of gebruikersnamen bevatten. Het is gemeld dat andere bedrijven, namelijk Cloudflare en Cicso, soortgelijke aanvallen ervaren. Het is mogelijk dat er een lek was in een gedeelde provider, waardoor het gericht vissen mogelijk was.

Meer over het CPU-kwetsbaarheidsnachtmerriesfront

De leiding is van Intel (PIC-lek), een nieuw soort processorbug. Dit is geen speculatieve uitvoeringsfout - we misleiden de CPU niet om te handelen op geheugen dat zal worden teruggedraaid. Dit lijkt meer op lezen uit een niet-geïnitialiseerd geheugen en daar de geheimen van een ander proces vinden. Dat is eigenlijk precies het soort bug waar de onderzoekers naar op zoek waren, omdat ze opzettelijk buffers en caches vulden met een bekend patroon en vervolgens probeerden te lezen van onzinnige geheugenlocaties op zoek naar die patronen. Als een geheugenuitlezing hun kanariegegevens retourneerde, was er iets interessants aan de hand.

Dit was precies wat er gebeurde bij het lezen van I/O-adressen die waren toegewezen aan de Advanced Programmable Interrupt Controller (APIC). Bepaalde bytes binnen het APIC-bereik zijn gereserveerd en het proberen om ze te lezen roept ongedefinieerd gedrag op. Op veel CPU-modellen betekent dit dat het systeem vastloopt en/of dat de CPU volledig crasht. Op sommige processors werkte het lezen, maar omdat de APIC eigenlijk geen gegevens op deze adressen verzendt, wordt oude cache-inhoud geretourneerd. Dit is een zeer interessant resultaat, maar houd er rekening mee dat het daadwerkelijk uitvoeren van de aanval toegang op rootniveau tot het systeem vereist. Dat maakt het eigenlijk zinloos, omdat de kernel al willekeurig geheugen kan lezen, toch?

Er is een belangrijke uitzondering op de regel van Kernel-ziet-alles. Intel's SGX enclave-technologie is speciaal ontworpen om geheugengebieden te beschermen tegen zelfs de kernel. In de praktijk betekent dit DRM-sleutels en SGX-beveiligde virtuele machines. Lekkage van DRM-sleutels vormt geen bedreiging *voor* de eindgebruiker, dus het is niet iets om u zorgen over te maken. En de verzameling mensen die met SGX beveiligde VM's draaien, is waarschijnlijk vrij klein.

SQUIP

AMD mist het plezier niet, SQUIP deze week openbaar maken (whitepaper). Het is een nieuw zijkanaal dat de processtatus afleidt van de wachtrij van de planner. Simultaneous MultiThreading (SMT) is de techniek die door moderne processors wordt gebruikt om twee threads met instructies in een enkele verwerkingskern in te voeren. Omdat verschillende instructies verschillende componenten van de CPU gebruiken, resulteert SMT in een hogere doorvoer dan traditionele one-thread-per-core-arrangementen. Een nadeel is dat de activiteit van de ene thread een impact kan hebben op de prestaties van de andere. Voor het uitvoeren van live audioverwerking was een van de aanbevelingen bijvoorbeeld om SMT uit te schakelen om gegevensonderschrijdingen te voorkomen. Voor de beveiligingsmensen is er een voor de hand liggend neveneffect, dat een proces een beetje informatie kan leren over wat zijn broer of zus doet op de CPU-kern. Er zijn een handvol methoden geweest om dit effect te detecteren en ervan te profiteren, en wat SQUIP met zich meebrengt, is een nieuwe methode om de broer of zus-thread te bespioneren.

In AMD Zen-processors zijn er meerdere rekenkundige logische eenheden (ALU's) per CPU-kern, maar slechts één van die eenheden kan vermenigvuldigen, delen en cyclische redundantiecontrole (CRC) uitvoeren. SQUIP zet veel verzoeken voor vermenigvuldigingsbewerkingen achter elkaar in de wachtrij en geeft vervolgens een rdpru instructie, Lees Processor Register. Het is specifiek op zoek naar de waarde van de Actual Performance Frequency Clock Counter (APERF). Er is hier een eigenzinnig gedrag dat de sleutel is tot de aanval. Er zijn aparte wachtrijen voor elk van de ALU's, evenals de hoofdwachtrij voor de kern. De hoofdwachtrij duwt instructies naar de afzonderlijke subwachtrijen, maar als de volgende doelwachtrij vol is, stopt de hoofdwachtrij totdat de volgende instructie naar de juiste component kan worden verzonden. Als de ALU1-wachtrij vol is+1, wordt de rdpru oproep is vertraagd. Zodra die instructie het einde van de primaire CPU-wachtrij bereikt, kan deze onmiddellijk worden uitgevoerd op een van de andere ALU's. Dit stelt in wezen een kansarm proces in staat om te zien hoeveel vermenigvuldigingsinstructies worden uitgevoerd door zijn broer of zus, zelfs als die broer of zus zich bijvoorbeeld in een andere VM bevindt.

Dus we kunnen vermenigvuldigingsinstructies bepalen. Wat levert dat ons precies op? Het voorbeeld waar de onderzoekers naar zochten was RSA's square-and-multiply, waarbij elk bit van de geheime sleutel twee of drie vermenigvuldigingen zal activeren, afhankelijk van de waarde van dat gegeven bit. Door de SQUIP-techniek over veel runs (meer dan 50,000) te gebruiken, is het mogelijk om de waarde van de geheime sleutel af te leiden. Het is een briljant stukje werk, maar waarschijnlijk van beperkt gebruik in de echte wereld. Dit is tenminste de mening van AMD, omdat hun advies is om best-practice coderingstechnieken te gebruiken om dit probleem te verhelpen.

Microsoft Office en symbolen

Het is weer zo'n "is de hel bevroren?" momenten, zoals Microsoft kondigt de release aan van foutopsporingssymbolen voor Microsoft Office. Wat zijn debug-symbolen precies, vraag je? Zie ze misschien als een routekaart naar wat er in een binair bestand staat. Wanneer een programma crasht, vertellen foutopsporingssymbolen welke functie werd uitgevoerd toen de crash plaatsvond, en misschien zelfs de naam van de variabele die de boosdoener was. Hoewel dit niet zoveel informatie is als een volledige bronversie, biedt het echt veel transparantie over wat er binnen een bepaald programma gebeurt. Stel je voor wat een Ghidra-decompilatie van Office zou kunnen opleveren. En dat is een beetje het punt. Microsoft wil dat onderzoekers exploiteerbare bugs vinden en rapporteren. Bovendien maken derde partijen plug-ins en integraties voor Office, en betere debugging maakt beide taken eenvoudiger.

VMWare

[Steven Seeley] van Source Incite vond in mei een verzameling VMWare-kwetsbaarheden, en wanneer ze worden samengevoegd, vormen ze een indrukwekkende RCE om kwetsbaarheidsketen te rooten. Ten eerste is er een eigenaardigheid die waarschijnlijk een functie is. Wanneer een beheerder een dashboardkoppeling maakt in de vRealize Manager-toepassing, kan iedereen met een token dat in die koppeling is ingesloten, toegang krijgen tot het dashboard zonder een geldig account. Hoewel het in wezen alleen-lezen toegang is, is er een tweede probleem, waarbij een API-aanroep om een ​​nieuwe gebruiker aan te maken de normale authenticatiecontroles omzeilt.

Dat volgende probleem is toevallig gevoelige informatie die in de logs terechtkomt, en dat het systeem logtoegang toestaat aan een minder bevoorrechte gebruiker, of helemaal geen gebruiker, in dit geval! De betreffende logregel bevat een Basic-autorisatiestring. Basisverificatie is alleen wachtwoord en ID die door een Base64-codering worden uitgevoerd. Zoals aangetoond in deze aanvalsketen, is het echt geen goed idee om te gebruiken. Hoe dan ook, dit maakt een wachtwoordreset mogelijk voor de beheerder, waardoor een aanvaller beheerderstoegang tot het systeem krijgt. admin kan de SSH-poort inschakelen en inloggen. Dus een aanvaller heeft admin en SSH, maar dat is nog steeds geen root.

De volgende is een sudo regel waarmee elke gebruiker een specifiek Python-script met sudo kan uitvoeren - wat betekent dat het script als root wordt uitgevoerd. Dat script kijkt naar een omgevingsvariabele om zijn binaire bestanden te vinden, en die variabele is triviaal om in te stellen. Stel de variabele zo in dat het script dat als root wordt uitgevoerd een script uitvoert dat u hebt geschreven, en u kunt alles doen, zoals uw account volledige sudo-rechten geven. De volledige exploitketen heet DashOverschrijven, en er zijn patches beschikbaar voor de drie kwetsbaarheden die in het spel zijn. Goed gedaan [Steven] voor de vondst.

SELinux

Als je in RedHat-land speelt, ben je waarschijnlijk bekend met SELinux, al was het maar als het vervelende dat je uitzet om software te laten werken. Velen van ons systeembeheerders die op RHEL en zijn klonen werken, worden gebruikt om het tijdelijk uit te schakelen als een eerste stap voor probleemoplossing. Nou, [esp0x31] zou willen dat je die gewoonte heroverweegt, wat het argument maakt dat SELinux een handig hulpmiddel kan zijn voor systeemverharding. Het bericht beschrijft hoe je een bestandscontext voor een bepaald programma kunt instellen en de toegang vervolgens strikt kunt beperken tot alleen bestanden met die context. Moet deze applicatie over UDP kunnen praten? Als dat niet het geval is, voegt u een regel toe die het maken van een UDP-socket verhindert. Een geweldige tip is de newrole commando, dat je in het SELinux-domein plaatst dat je zojuist hebt gedefinieerd — perfect om je nieuwe regels te bashen op zoek naar een maas in de wet.

Bits en bytes

Het Point-to-Point Protocol in Windows heeft een fout, CVE-2022-30133, waar het verzenden van verkeer naar poort 1723 kan leiden tot het uitvoeren van willekeurige code. Het enge hieraan is dat het potentieel wormbaar is en dat de poort opzettelijk kan worden blootgesteld aan internet, aangezien dit een vroege VPN-oplossing in Windows was. Yoiks.

X-as-a-Service is een van de populairste manieren om geld te verdienen, en het criminele element is aan boord gesprongen. We hebben ransomware-as-a-service gehad en nu is er command&control-as-a-Service. Is het aansturen van de schat aan machines in uw botnet gewoon teveel moeite? Voor een laag maandelijks bedrag doen deze jongens het voor je, en het wordt geleverd met een gelikt dashboard en alles. We leven echt in de moderne tijd.

Rsync heeft een fout, waar een kwaadwillende server willekeurige bestanden kan schrijven op een verbindende client. Dit kan ook worden gebruikt in de vorm van een man-in-the-middle-aanval. Zoeken een release van 3.2.5 in de komende dagen, die de fix zal bevatten.

Van 5.4 miljoen Twitter-accounts werden privégegevens verwijderd en verkocht, dankzij een zero-day in de webcode van Twitter. Het gevoelige deel was het e-mailadres of telefoonnummer dat werd gebruikt om het account te verifiëren. Voor de meesten van ons zou het alleen maar vervelend zijn om daaraan te ontsnappen. Gewoon een andere, maak er weer een paar spammerslijsten van. Er zijn een handvol Twitter-accounts die om een ​​goede reden anoniem worden beheerd, en dit soort lekkage zou een behoorlijk probleem kunnen zijn, als slechte acteurs de punten met elkaar konden verbinden. Met dank aan [app-le-bees] voor het wijzen op deze in onze Discord!