Hvad er LDAP-injektionsangreb, og hvordan man forebygger dem

Kodeinjektionsangreb er nogle af de mest almindelige og vellykkede onlineangreb. Webapplikationer, mobilapps, desktopprogrammer, API s, databaser , webservere osv. kan alle være sårbare over for kodeinjektionsangreb, hvis de accepterer brugerinput uden korrekt validering.

Et af de mest almindelige kodeinjektionsangreb er LDAP-injektion, og det er det, vi vil diskutere i dette indlæg. Vi vil se på, hvad LDAP er, hvordan LDAP-injektion virker, og give tip til at afbøde dette angreb.

Hvad er LDAP?

LDAP står for Lightweight Directory Access Protocol. Det er en katalogtjenesteprotokol, der bruges til at slå kataloglister i en LDAP-database, oftest brugernavne og adgangskoder. Som navnet antyder, er LDAP meget let, og på grund af det skalerer det meget godt og bruges af et massivt antal organisationer i dag.

En LDAP-mappe består af attributter baseret på LDAP-skemaet. Hver post i skemaet/kataloget er forsynet med en unik identifikator kaldet et Distinguished Name (DN). Nedenfor er et eksempel på en post for den falske bruger, Johnnyny Theguy.

|_+_|
|_+_|
|_+_|
|_+_|
|_+_|
|_+_|
|_+_|
|_+_|
|_+_|
|_+_|
|_+_|
|_+_|

Mange organisationer bruger LDAP til single sign-on at give medarbejderne adgang til flere apps inden for virksomhedens netværk uden at kræve, at de logger ind på hver enkelt app. Men ud over blot at validere brugerlegitimationsoplysninger, bruges LDAP til at besvare forespørgsler om information og inkluderer også forskellige kommandoer, der bruges til at administrere LDAP-databaserne. Og det giver mening i betragtning af mængden af ​​information (ud over blot brugernavne og adgangskoder), som LDAP-databaser indeholder – hvilket også fremhæver farerne ved LDAP-injektionsangreb.

LDAP-forespørgsler

De LDAP-forespørgsler, der sendes til serveren, omtales som LDAP-søgefiltre og er konstrueret ved hjælp af præfiksnotation. En typisk LDAP-forespørgsel involverer normalt følgende:

• Sessionsforbindelse : Brugeren opretter forbindelse til LDAP-serveren.
• Anmodning : Brugeren sender en forespørgsel til serveren (for eksempel et brugeropslag).
• Respons : LDAP-protokollen forespørger i biblioteket, lokaliserer de anmodede oplysninger og giver dem til brugeren.
• Færdiggørelse : Brugeren afbryder forbindelsen til LDAP-serveren.

Når de er inde i databasen, kan brugere formulere forespørgsler for at udføre operationer over LDAP-serveren. Nedenfor er en liste over almindelige handlinger, som LDAP-databasen/serveren kan udføre:

• Tilføje : Bruges til at tilføje nye data til databasen.
• Bind (godkend) : Bruges til godkendelse og kryptering.
• Slet : Bruges til at slette data fra databasen.
• Søg og sammenlign : Søgeoperationen bruges til at søge efter og læse poster.
• Modificere : Bruges af LDAP-klienter til at anmode LDAP-serveren om at foretage ændringer i eksisterende poster
• Afbind : Bruges til at lukke forbindelsen.

Inden for sine forespørgsler understøtter LDAP følgende metakarakterer:

• & Boolesk OG
• | Boolean ELLER
• ! Boolean IKKE
• = Lige med
• ~= Ca
• >= Bedre end
• <= Mindre end
• * Enhver karakter
• () Gruppering af parenteser

Her er nogle eksempler på LDAP-forespørgsler.

En typisk anmodning om brugergodkendelse (dvs. et brugerlogin) vil se sådan ud:

|_+_|

Hvis de afsendte legitimationsoplysninger svarer til dem på LDAP-serveren, vil brugeren Johnny blive godkendt.

Andre eksempler ville være:

Find alle brugere, der skal ændre deres adgangskode, næste gang de logger på:

|_+_|

Denne forespørgsel ville returnere en liste over alle brugere fundet i databasen, som har attributten pwdLastSet med værdien: 0.

Find alle brugere med 'pass' eller 'pwd' i deres beskrivelse

|_+_|

Denne forespørgsel ville returnere en liste over alle brugere fundet i databasen, som har pass- eller pwd-attributterne anført.

LDAP injektion

Nu hvor vi forstår, hvad LDAP er, og hvordan det virker, lad os vende vores opmærksomhed mod LDAP-injektion.

Et LDAP-injektionsangreb kan være fuldstændig ødelæggende for din organisation. Det er på grund af mængden af ​​information af høj værdi, en LDAP-database kan indeholde. Vi taler om navne, brugernavne, adgangskoder, e-mailadresser, telefonnumre, jobtitler, tilladelser osv.

Læg dertil, at et LDAP-injektionsangreb kan betyde mange ting. Med andre ord er LDAP-injektionsangreb multi-vektoreret. En angriber kan udnytte et usikkert LDAP-system på mange forskellige måder. De kunne indsætte ondsindet kode, der giver dem mulighed for at se alle brugernavne og adgangskoder indeholdt i databasen. Eller de kan tilføje sig selv som bruger i LDAP-databasen med systemadministratortilladelser. En angriber kan endda helt omgå kravet om brugernavne og adgangskoder. Kernen i et LDAP-injektionsangreb er at forsyne serveren med en forespørgsel, der vil narre serveren til at validere forespørgslen som sand eller gyldig.

Mange faktorer spiller ind for at få et LDAP-injektionsangreb til at lykkes eller mislykkes: Angriberens videns- og færdighedsniveau, organisationens it-sikkerhedsforanstaltninger og oplysningerne i LDAP-databasen, for eksempel. Men under alle omstændigheder vil et vellykket LDAP-injektionsangreb typisk være en stor gevinst for angriberen og en betydelig smerte for den kompromitterede organisation.

Lad os se på et par eksempler på, hvordan dette kan opnås.

Eksempler på LDAP-injektionsangreb

Omgå godkendelse med '&'-metategn

Lad os tage vores første forespørgselseksempel ovenfor på et brugerlogin:

|_+_|

På en sårbar LDAP-database kunne en ondsindet aktør helt omgå godkendelsesmekanismen ved at lave en ondsindet forespørgsel ved at indsætte metategn & mellem brugeren og adgangskodeattributterne for forespørgslen. Det ville se sådan ud:

|_+_|

Fordi LDAP kun analyserer de to første attributter, bliver sætningen ækvivalent med:

|_+_|

Hvis ovenstående forespørgsel blev udført på en sårbar LDAP-database/server, ville resultatet vende tilbage som sandt, og vores ondsindede bruger 'hvad som helst' ville blive autentificeret.

Omgå godkendelse med metategnene '*' og '|'

Lad os bruge et lignende eksempel som ovenfor ('cn' står for almindeligt navn):

|_+_|

Vi kan opnå det samme som ovenfor ved at bruge * og | metakarakterer. Hvis vi indstiller brugernavnsværdien til |_+_|, bliver søgefilteret:

|_+_|

Fordi LDAP kun analyserer de to første attributter, returneres ovenstående forespørgsel altid som sand. Denne forespørgsel ville gøre det muligt for en hacker at omgå LDAPs godkendelsesmekanisme uden korrekt inputvalidering.

Visning af alle brugere i databasen med '*'

Forespørgslen nedenfor er en LDAP-søgeforespørgsel.

|_+_|

Ovenstående præfiksfilternotation instruerer forespørgslen om at finde en LDAP-node med det angivne brugernavn og adgangskode. Men hvis LDAP-databasen er sårbar over for LDAP-injektion, kan en angriber erstatte cn'et og adgangskoden i ovenstående eksempel med *, som sådan:

|_+_|

Det ville ændre forespørgslens tilsigtede betydning, og databasen ville returnere en liste over alle brugere.

Risici forbundet med LDAP-injektion

De skader, der kan opstå fra LDAP-injektionsangreb, ligner andre injektionsangreb. At injicere kode i en server indebærer evnen til at indhente information og ændre information. Derfor kan LDAP-injektionsangreb føre til følgende:

Lækker følsomme data

Som vi så med vores sidste eksempel, er det muligt at manipulere LDAP-forespørgsler sendt til en sårbar server for at vise utilsigtet information. I vores eksempel ovenfor viste vi, hvordan en ondsindet forespørgsel kunne få databasen til at udlæse listen over alle brugere i databasen.

Men hvis serveren er sårbar over for LDAP-injektion, kan den blive manipuleret til at udlæse andre følsomme data. LDAP-databaser har en tendens til at gemme flere data end blot brugernavne og adgangskoder - som allerede ville være skadelige nok, hvis de blev lækket. På grund af det kunne en angriber lave LDAP-forespørgsler for at få følsomme oplysninger som e-mail-adresser, telefonnumre og endda personnumre. Så oven i kompromitterede konti og uautoriseret adgang til virksomhedens ressourcer (hvilket kan være ødelæggende), kan LDAP-injektion også føre til identitetstyveri, målrettet phishing kampagner osv. Nasty.

Denial of service-angreb

LDAP-injektionsangreb kan også føre til ligetil og meget effektive lammelsesangreb (DoS). . Dette angreb kan monteres mod det program, der interagerer med biblioteksserveren, eller mod selve biblioteksserveren. Hvis en angriber kan lave nok ondsindede LDAP-forespørgsler, der er meget tidskrævende og ressourcekrævende, kan den forbruge alle de tilgængelige ressourcer, så andre anmodninger ikke kan komme igennem.

Antag desuden, at applikationen er designet til at opbevare alle poster returneret fra en søgeforespørgsel i hukommelsen. I så fald kan en forespørgsel, der er beregnet til at returnere mange flere poster end forventet, føre til, at applikationen bruger al sin tilgængelige hukommelse til at behandle denne anmodning. Resultatet af det ville være, at applikationen går ned.

Ændrede filer og datakorruption

Vi så, hvordan en ondsindet udformet forespørgsel kunne afsløre utilsigtede data for angriberen. Men det er også muligt at narre databasen til at opdatere utilsigtede filer, enten med junk, for at ødelægge filen eller ved at redigere adgangskoden til en, der er sat af angriberen. Hvis angriberen kan narre programmet til at søge efter de forkerte poster, kan de narre det til at opdatere forkerte poster, hvilket kan forårsage datatab eller korruption.

Sådan forhindres LDAP-injektionsangreb

Nu hvor du kender truslerne, er her nogle forholdsregler, du kan tage for at forhindre LDAP-injektionsangreb.

Gennemtving inputvalidering

Med andre ord: stol ikke på brugerinput. Uanset typen af ​​bruger (godkendt, intern eller offentlig), skal du betragte dette input som upålidelig. Hvis det er muligt, skal du forhindre dine applikationer i at kopiere brugerkontrollerbare data til LDAP-forespørgsler. Hvis det ikke er muligt, skal du sørge for at validere brugerinput mod en liste over tilladte strenge eller tegn. Og denne validering bør altid finde sted på serversiden, selvom inputtet tidligere var valideret på klientsiden.

Du kan bruge et stærkt regulært udtryksmønster til at validere strukturerede input som CPR-numre, telefonnumre og e-mailadresser. Input såsom brugernavne skal valideres mod et godkendt sæt af tegn, der udelukker LDAP-metategn. De tegn, der skal blokeres, omfatter ( ) ;, * | &= og hvidt rum

Escape input med kodning

Undgå brugerkontrollerede inputstrenge, så eventuelle kontroltegn i inputtet ikke ændrer den tilsigtede betydning af LDAP-søgefilteret. For eksempel i en Java-applikation kan metategnene i en LDAP-forespørgsel indtastes med omvendte skråstreg som escape-tegn. På denne måde føjes ikke-pålidelige inputs til en søgeforespørgsel som bogstavelige strengværdier, ikke som LDAP-prædikater.

Det anbefales også kraftigt at bruge eksisterende biblioteker til at undslippe – skriv ikke dit eget, da du risikerer at introducere utilsigtede sårbarheder.

Implementer princippet om mindste privilegium

Princippet om mindste privilegium er en it-sikkerhedspolitik, der siger, at man kun skal tildele de minimum nødvendige rettigheder til en bruger, der kræver adgang til en ressource. Disse rettigheder bør også være gældende i den kortest mulige varighed. Specifikt skal den LDAP-konto, der bruges til at binde biblioteket i et program, have begrænset adgang. Kun autoriserede LDAP-forespørgsler bør udføres mod LDAP-serveren.

Afslut

Så det er ins og outs af LDAP-injektionsangreb. De er ret grimme, og ligesom mange (hvis ikke de fleste) onlineangreb kan deres konsekvenser være katastrofale. Som det ofte er tilfældet med denne slags angreb, er desinficering af brugerinput den mest afgørende afbødende foranstaltning her. Ikke at rense dine brugeres input er som at have hoveddøren til dit hus ulåst - alle kan blot dreje knappen og komme ind. Det er ikke, hvad du vil med en webapplikation/server. Forhåbentlig vil tipsene, der er skitseret ovenfor, hjælpe dig med at undgå dette scenario.

Som altid, vær sikker.