Les 5 configuracions d'Active Directory que trobem trencades en gairebé totes les nostres auditories internes

En gairebé totes les auditories internes que fem, el domini acaba caient. I gairebé mai no és per una fallada sofisticada ni per un dia zero exòtic. És per un grapat de configuracions que es repeteixen empresa rere empresa, que es van anar acumulant durant anys i que ningú no va tornar a mirar.

Són errors de configuració, no de programari, així que no apareixen en cap butlletí de pedaços. Però un atacant amb una posició inicial sense privilegis els troba en qüestió de minuts. Aquests són els cinc que més vegades ens obren la porta.

Comptes de servei que es poden kerberoastear

A Active Directory, qualsevol usuari autenticat pot demanar un tiquet de servei per a un compte que tingui un SPN associat. Aquest tiquet va xifrat amb la contrasenya del compte de servei, així que qui el demana se’l pot endur a casa i intentar trencar-lo offline, sense fer soroll i sense bloquejos de compte.

El problema és que molts comptes de servei es van crear fa anys amb contrasenyes curtes o reutilitzades i sovint tenen privilegis alts. Un atacant sense privilegis demana el tiquet, el trenca al seu propi equip i apareix amb un compte de servei que sovint és administrador d’alguna cosa important.

La correcció passa per fer servir comptes de servei administrats (gMSA), que roten la contrasenya de manera automàtica amb longituds impossibles de trencar. On no es pugui, feu servir contrasenyes llargues i aleatòries de més de 25 caràcters. Convé a més revisar quins comptes mantenen un SPN que ja no es fa servir.

Comptes sense preautenticació de Kerberos

Hi ha una opció als comptes d’usuari que es diu “no requerir preautenticació Kerberos”. Quan està activada, qualsevol pot demanar al controlador de domini una dada xifrada amb la contrasenya d’aquest compte, un altre cop per trencar-la tranquil·lament a fora.

Sol estar posada en comptes antics, en integracions amb sistemes Unix o en aplicacions que en el seu dia la van necessitar i ningú no va revertir. Cadascun d’aquests comptes és una contrasenya que un atacant pot atacar offline des del primer minut, sense ni tan sols tenir credencials vàlides.

La correcció és directa. Reviseu quins comptes tenen activada aquesta opció i desactiveu-la en tots els que no la necessitin de debò, que solen ser gairebé tots. Als pocs que l’hagin de conservar, poseu-los una contrasenya llarga i aleatòria.

Contrasenyes en text clar on no haurien de ser-hi

Aquest és dels que més ens sorprèn continuar trobant. Apareix gairebé sempre.

D’una banda, el camp de descripció o de notes dels comptes d’usuari, on algú va apuntar la contrasenya “per recordar-la” fa anys. Qualsevol usuari del domini pot llegir aquests camps. De l’altra, les preferències de directiva de grup (GPP) que guardaven contrasenyes al recurs SYSVOL xifrades amb una clau que Microsoft va publicar fa més d’una dècada, així que desxifrar-les és trivial. El SYSVOL el llegeix qualsevol que estigui autenticat.

La correcció és buscar i esborrar. Hi ha eines que recorren les descripcions de tot el domini i el SYSVOL a la recerca d’aquests restes. El que aparegui s’elimina, es rota la contrasenya afectada i s’estableix com a norma que les credencials no viuen en atributs ni en scripts.

Permisos excessius sobre objectes privilegiats

El control d’un domini no sempre es guanya sent administrador. De vegades n’hi ha prou amb tenir permisos perillosos sobre els comptes o els grups correctes.

En gairebé tots els dominis que auditem hi ha comptes normals, sense pinta de privilegiats, que tanmateix poden canviar la contrasenya d’un administrador, modificar qui pertany a un grup privilegiat o reescriure els permisos d’un objecte crític. Són permisos com GenericAll o WriteDACL que es van delegar malament en algun moment o que es van heretar sense que ningú ho planifiqués. Per a un atacant són una autopista, perquè encadenant dos o tres d’aquests permisos arriba a administrador del domini sense explotar cap vulnerabilitat.

La correcció és la més laboriosa de la llista. Cal mapar qui té permisos sobre què, sobretot als comptes i els grups privilegiats, per retallar després tot el que no estigui justificat. Les eines que dibuixen aquestes relacions ajuden a veure els camins que un atacant seguiria.

Delegació sense restriccions

La delegació a Kerberos permet que un servei actuï en nom d’un usuari per accedir a un altre servei. És útil i de vegades necessària, però té una variant perillosa que anomenem delegació sense restriccions.

Quan un servidor té activada la delegació sense restriccions, guarda a la memòria els tiquets de qualsevol usuari que s’hi connecti, inclosos els d’un administrador del domini. Si un atacant controla aquest servidor, o aconsegueix que un administrador s’hi connecti, es queda amb un tiquet que li dona el domini sencer. I aquesta mena de delegació es continua trobant activada en servidors que mai no la van necessitar.

La correcció és eliminar la delegació sense restriccions allà on no calgui, que és gairebé sempre. On la delegació sigui necessària de debò, es fa servir la variant restringida, que limita a quins serveis concrets es pot delegar. Els comptes més sensibles, a més, es marquen com que no es poden delegar mai.

Què tenen en comú aquestes cinc

Cap d’aquestes cinc coses és una vulnerabilitat en el sentit clàssic. No hi ha cap pedaç que les tanqui, no surten en un escàner automàtic dels que puntuen amb colors i gairebé sempre conviuen amb un compliment perfectament en regla. Són configuracions, decisions que algú va prendre fa anys i que el temps va convertir en forats.

Per això les trobem una vegada i una altra. I per això un escaneig automàtic gairebé mai no les veu. Cal que algú miri el domini com el mira un atacant, encadenant permisos i relacions en lloc de revisar una llista. És justament la diferència que explicàvem a per què passar una auditoria de compliment no significa estar segurs.

Si fa temps que ningú no mira el vostre Active Directory amb aquests ulls, el més probable és que almenys dues o tres d’aquestes cinc estiguin esperant.

---

Si voleu que auditem el vostre Active Directory des de la posició d’un atacant intern, escriviu-nos a [email protected].