De veiligheidswereld hield begin deze week onze adem in voor: de grote aankondiging van OpenSSL-kwetsbaarheid. Blijkt dat het twee afzonderlijke problemen zijn, beide gerelateerd aan het afhandelen van punycode, en ze zijn gedowngraded naar hoge ernst in plaats van kritiek. Punycode is trouwens het systeem voor het gebruik van niet-ASCII Unicode-tekens in domeinnamen. De eerste kwetsbaarheid, CVE-2022-3602, is een bufferoverflow die vier willekeurige bytes naar de stack schrijft. Met name wordt de kwetsbare code pas uitgevoerd nadat de keten van een certificaat is geverifieerd. Een kwaadaardig certificaat moet ofwel correct worden ondertekend door een certificeringsinstantie of handmatig worden vertrouwd zonder geldige handtekening.

A paar bronnen hebben de details uitgewerkt van deze kwetsbaarheid. Het is een fout voor één fout in een lus, waarbij de bufferlengte eerder in de lus wordt gecontroleerd dan de lengtevariabele wordt verhoogd. Vanwege de logische slip kan de lus mogelijk één keer te vaak worden uitgevoerd. Die lus verwerkt de Unicode-tekens, gecodeerd aan het einde van de punycode-string, en injecteert ze op de juiste plaats, waardoor de rest van de string over een byte in het geheugen wordt geschoven. Als de totale uitvoerlengte 513 tekens is, is dat een overloop van één teken. Een Unicode-teken neemt vier bytes in beslag, dus er is een overloop van vier bytes.

Hoe exploiteerbaar deze overflow is, hangt af van wat er in die vier bytes zit. Toen Datadog-onderzoekers de kwetsbaarheid op Linux testten, ontdekten ze dat in wezen elk gecompileerd binair bestand hier een sectie van 4 bytes vrij geheugen had, dat pas na de overloop werd geïnitialiseerd. Met andere woorden, op die binaire bestanden is deze kwetsbaarheid volkomen goedaardig. In Windows werd dat gedeelte van het geheugen anders behandeld door de compiler, vanwege verschillende optimalisaties. Hier bevat het een stapel kanarie. Dat is een speciale waarde die bestaat tussen de laatste buffer op de stapel en de aanwijzer- en retourwaarden. Aan het einde van een functie die een stapelkanarie gebruikt, wordt de waarde gevalideerd voordat deze terugkeert naar de bovenliggende functie, en de processen crashen als ermee is geknoeid. Het idee is dat een bufferoverloop die het retouradres overschrijft de kanariewaarde niet kan voorspellen, en kanaries hebben de neiging om opzettelijk terminatorbytes zoals 0x00 op te nemen om exploit nog moeilijker te maken. Merk op dat de Linux-binaries ook stack-canaries gebruiken, wat misbruik zou voorkomen, maar vanwege de geheugenlay-out en de beperkte overlooplengte worden deze nooit gewijzigd.

Het tweede opgeloste probleem was CVE-2022-3786, en Checkpoint Security probeerde dit uit te leggen. In het geval van Punycode gevolgd door een punt, wordt die punt toegevoegd aan het einde van de uitvoertekenreeks, mogelijk voorbij het einde van de buffer. Het is het omgekeerde van de vorige kwetsbaarheid. Hier is de lengte van de overloop bijna willekeurig, maar de waarde is beperkt tot alleen het puntsymbool. Als gevolg hiervan is dit strikt een Denial of Service-probleem.

Gelukkig valt de lucht niet naar beneden met deze kwetsbaarheden, maar er kunnen nog steeds onverwachte gevallen zijn waarin OpenSSL niet wordt gecompileerd met stack-canaries, of de crash kan worden gebruikt als onderdeel van een meer gecompliceerde exploitketen, dus zorg er toch voor dat u de bijgewerkte of gebackporteerde patch als u de kwetsbare bibliotheek gebruikt, versies 3.0.0-3.0.6.

Beveiligingsonderzoekers wenden zich tot de duistere kant?

De wet van de krantenkoppen van Betteridge is hier zeker van toepassing. Dit verhaal is gewoon vreemd, aangezien iemand een ransomware-aanval heeft gelanceerd, die ook protestware is, en ook beweert het werk te zijn van een aantal opmerkelijke beveiligingsonderzoekers. Dus, zit Bleeping Computer echt achter deze ransomware-campagne die ook protesteert tegen het gebrek aan steun voor Oekraïne vanuit het Westen? Oef, er valt hier veel uit te pakken.

Ten eerste lijkt het niet eens ransomware te zijn, aangezien er geen manier is om een ​​decoderingssleutel te kopen. Dus eigenlijk is het een wisser. De naam die in de wisserbrief wordt gebruikt, is "Azov", een special forces-regiment in Oekraïne met een excentriek neonazistisch verleden, dat toevallig inspeelt op de Russische retoriek over hun oorlog daar. Dan beweert het briefje afkomstig te zijn van hasherezade, en geeft een overzicht van verschillende Twitter-handgrepen van beveiligingsonderzoekers. Dan noemt de Krim en klaagt over onvoldoende hulp voor Oekraïne. jEr is een specifieke boodschap voor de mensen van de VS, die president Biden uitroept, oproept tot revolutie en dan de slogan 'Keep America Great' laat vallen. Dan geeft een bericht aan Duitsland, behulpzaam door Google Translate gehaald, ons: "Jij! Een man uit Duitsland, kom op, kom naar buiten!
Maar dat is een catastrofe die Biden hen heeft gebracht. Hoe leuk was het toen Merkel erbij was?” En dan nog bizarder, het briefje eindigt met de hashtag "#TaiwanIsChina", wat een slogan lijkt te zijn van de door de CCP gesponsorde retoriek rond Taiwan.

Het is moeilijk om erachter te komen wat er precies aan de hand is met deze campagne. Het is duidelijk niet wat het beweert te zijn. Een pro-Russische of anti-Russische hacker die steun probeert te krijgen? Iets heel anders, de geopolitiek gebruiken als dekking? De infecties lijken allemaal het gevolg te zijn van SmokeLoader, een van de malware-as-a-service-botnets. Betaal wat geld, duw je payload naar machines op het botnet. Ter herinnering: als u of iemand die u kent toch wordt geraakt door een van deze campagnes, willen wetshandhavingsinstanties hiervan een verslag krijgen. Om de criminelen achter deze ondernemingen te lokaliseren en te vervolgen, hebben ze om te beginnen een aantal concrete zaken nodig. En hoezeer het ook lijkt alsof ransomware-criminelen nooit gepakt zullen worden, ze worden geïdentificeerd en gepakt.

Project Zero Weerstaat het om het XML4Shell te noemen

[Felix Wilhelm] een Java-probleem gevonden, en tot onze gedeelde vreugde voelde hij niet de behoefte om er een "4shell" -naam voor te verzinnen. Dit verhaal begint met SAML, Security Assertion Markup Language, het op XML gebaseerde protocol dat een groot deel van de single-sign-on-ondersteuning van het web mogelijk maakt. U wilt website X bezoeken, een Service Provider (SP) en uw account gebruiken van website Y, uw Identity Provider (IdP). De SP genereert een SAML-verzoek, in de vorm van een XML-document, en uw browser stuurt dat document naar de IdP. De IdP bevestigt dat je daar wel een account hebt en stuurt een XML-handtekening terug via de browser. Aangezien het een duidelijk potentieel probleem is dat de browser van de gebruiker degene is die de aanmeldingsgegevens verwerkt, worden de gegevens zelf geverifieerd als onderdeel van de handtekening. Het hele proces is ingewikkeld en een van de complexiteiten is dat een handtekening verwijzingen naar andere handtekeningen kan bevatten. Voordat de handtekening volledig is geverifieerd, moet het ondertekende XML-document mogelijk verschillende transformatieve stappen doorlopen en wordt de taal eXtensible Stylesheet Language Transformations (XSLT) ondersteund. Ja, het is een turing-complete taal in je SAML-objecten. En als de code voor de verificatie niet is ingeschakeld secureValidation, wordt de code gecompileerd in Java-code voor de prestatieverbetering.

Een deel van dit compilatieproces is het converteren van waarden in de XSLT-invoer naar de Java-constantenpool. Die pool heeft een beperkte grootte en het compilatieproces voert de grenscontrole niet correct uit. Wat gebeurt er als je voorbij het einde van het zwembad schrijft? Die gegevens worden opgevat als klassevelden - velden zoals methodedefinities. Doe het werk om geldige waarden te maken voor de drie velden die deze overloop zal klonteren, en je hebt de mogelijkheid om willekeurige bytecode uit te voeren. Dit werkt in theorie voor elke Java-toepassing die XML-handtekeningen verwerkt. Het grote voorbehoud is dat secureValidation schakelt alle XSLT-transformaties uit, maar dat was alleen standaard ingeschakeld in JDK 17.

urlscan.io heeft geheimen

De service van urlscan.io is eigenlijk best handig. Geef het een weblink en het zal het laden, een voorbeeld van de pagina voor je bekijken en er wat statistieken over uitspugen. Heeft iemand een rare link gestuurd en wil je die niet openen op je computer? Hier is uw oplossing. Het enige dat u in gedachten moet houden, is dat, tenzij u de scan expliciet als privé markeert, de link en resultaten openbaar zichtbaar zijn. Github werd vorig jaar gebeten door per ongeluk namen van privérepository's naar de service te lekken. Dit deed [FABIAN BRÄUNLEIN] zich afvragen, hadden andere diensten een soortgelijke fout gemaakt?? Ja. Er zijn links naar privé Google-documenten, API-sleutels, Sharepoint- en Zoom-uitnodigingen en meer. Blijkbaar pushen verschillende geautomatiseerde beveiligingsservices koppelingen naar de service zonder enige gebruikersinteractie en gebruiken ze de API niet goed. Oeps.