19/02/2016 Actualitzacions de seguretat en Drupal

Abans d'entrar en com Drupal gestiona problemes de seguretat i hi incorpora actualitzacions, ens hauríem de preguntar (i fem-ho per un moment des de la irreverència, posant en dubte les bases): per què calen actualitzacions de seguretat? Per que no es planteja una bona estratègia i disseny de l'aplicació pensant des del primer moment en assegurar-la? La resposta a aquestes preguntes requereix almenys que introduïm de forma molt simple i esquemàtica alguns dels aspectes del funcionament de la computació.

Tots els dispositius electrònics utilitzen circuits integrats de mes o menys complexitat. Als inicis de la computació, aquesta complexitat era relativament baixa. Conforme avançava la tècnica, l'ús dels circuits és convertia en una tediosa tasca, cada cop hi havia un major grau miniaturització, paral·lelisme i complexitat. Per solucionar-ho, els enginyers van decidir empaquetar certes operacions que sovint tenien els mateixos passos, en “manuals d'instruccions” que els circuits integrats sabessin interpretar. L'objectiu que es cercava era facilitar el seu us per les persones.

En aquell moment va néixer el software i els desenvolupadors. No obstant, amb el temps i conforme augmentava la demanda de noves funcionalitats, enginyers i desenvolupadors es van trobar amb el mateix problema: no era suficient empaquetar en “manuals d'instruccions”, seguia sent massa complex. Així doncs, van decidir crear “manuals de manuals”. Conforme la complexitat i la demanda de funcionalitats augmentava s'anaven creant capes i capes d'abstracció, cada una d'elles especialitzada en resoldre i facilitar la interacció amb les predecessores i amb l'usuari. 

On es solen presentar les fissures de seguretat en Drupal?

A aquestes altures us podeu estar preguntant: molt bé... I que té que veure això amb la seguretat? Doncs que cada una de les agrupacions de “manuals d'instruccions” en la seva essència està feta per una o diverses persones i per definició tots els humans són fal·libles i cometem errors. A vegades no són errors garrafals, a vegades no son ni tan sols errors, sinó omissions de comprovació, bona fé de que no s'intentarà res estrany, etc...

Moltes vegades aquests errors passen desapercebuts durant anys, les causes poden ser múltiples i molt complexes i es van acumulant entre les capes d'abstracció i així, un error en la capa de nivell inferior en pot provocar un o varis en una capa més alta, o podem tenir errors introduïts directament en una capa alta que no afectin a les capes inferiors, però siguin igualment destacables.

Drupal és una capa software de les més altes, per damunt seu només té l'usuari (ens referim a tu que estàs llegint aquest post ara mateix i ho fas gràcies a un Drupal creat per nosaltres), però internament i donat la gran complexitat del projecte Drupal (quasi mig milió d'instruccions en la seva versió 8) aquest, es dissecciona encara més en múltiples capes que permeten a empreses com la nostra parametritzar-lo, i modelar-lo al gust per oferir solucions altament específiques.

Entre tanta abstracció i modularitat apareixen els errors o problemes de seguretat i podem dir que els sospitosos habituals en relació a problemes de seguretat, Drupal son el core i els mòduls. El core és el nucli de Drupal i es un conjunt de funcionalitats (framework) que permet als desenvolupadors d'Avellana Digital realitzar tasques típiques d'una forma correcta i relativament segura; els mòduls d'altra banda són afegits que incorporen noves característiques o funcionalitats que per diversos motius no s'afegeixen al core però que ajuden, estenen o faciliten les funcionalitats que aquest no proveeix (a vegades tan sols modifiquen el comportament natural de Drupal per millorar-lo per una tasca específica). 

Les vulnerabilitats en els mòduls

En relació a la seguretat, direm que els mòduls són el vector més habitual de problemes, doncs normalment aquests són creats per persones desconegudes (amb bona fé) que durant un temps determinat el mantenen però que (habitualment) no tenen cap relació contractual ni amb l'implementador (Avellana Digital per exemple) ni amb el client (tu). En aquests mòduls (i en quasi tots) es cometen errors, que en menor o major mesura afecten a la seguretat, a la estabilitat o al rendiment de la solució. Normalment la correcció d'aquests errors corre de la mà del propi desenvolupador del mòdul i aquest és l'encarregat (si vol) de publicar la correcció (o vendre-la).

Això deixa una via oberta a que errors i fissures de seguretat perdurin en el temps preparades per a ser explotades per desconeguts remots, àvids de dubtoses intencions o d'engrandiment del propi ego. Aquests motius i en especial també els de estabilitat i rendiment, ens van portar a nosaltres, Avellana Digital, a confeccionar de forma habitual mòduls propis per als nostres clients que substituïssin i ampliessin les funcionalitats que altres mòduls brindaven (o no) augmentant la seguretat (com a experts en Drupal que som), estabilitat i rendiment de les aplicacions que entreguem als nostres clients.

Les vulnerabilitats del core

Queda pendent parlar del core, el core de Drupal a diferencia dels mòduls és un component molt sòlid (en honor a la veritat direm que el core integra també funcionalitats en mòduls, però aquests estan tan entrelligats que és mes pràctic parlar del core com un tot), molt madur, on hi intervenen desenvolupadors independents, empreses i organitzacions, que mou un volum de negoci i capital suficient per cridar l'atenció a nivell mundial. En que és tradueix això? Està més controlat, vigilat i provat, però tot hi així no lliure d'errors i donat la seva popularitat i gran implantació, contínuament bombardejat per individus o organitzacions (hacker teams) a la cerca de forats per on explotar vulnerabilitats.

Les vulnerabilitats del core de Drupal solen ser més importants no perque les tècniques per obtenir-les siguin més enginyoses (que també), sinó per que al ser una capa d'abstracció mes propera a la seva immediata antecessora, les possibilitats de mal ús i explotació de recursos de forma fraudulenta són molt mes grans i devastadores.

Drupal Security Team

Així fa ja molts anys es va crear el Security Teamel equip de persones que vetlla per detectar i sobretot corregir els problemes de seguretat que pugui tenir el core de Drupal (entre altres tasques). Aquest mateix grup és el responsable de l'anunciament públic de la descoberta de noves fissures de seguretat i de les instruccions o actualitzacions necessàries per pal·liar o disminuir el impacte. Totes les publicacionsdel equip de seguretat, les trobem periòdicament exposades drupal.org/security

Dins de tot aquest entramat encara tenim un detall interessant a comentar que és la catalogació dels errors, el que s'anomena severity (la severitat) o el «quant de mal pot fer» o «fins a on arriba un determinat problema». És una fuga d'informació? Pot tombar la web? Pot reescriure part del codi i col·locar elements que infectin als nostres visitants?

Veiem la taula de severitats que el Security Team va idear al seu dia, on s'ordenen de menor a major criticitat i malauradament hem de dir que són conceptes força tècnics, així que si tens algun dubte ens pots contactar en el següent enllaç.

Not Critical
(No crítica)
  • Classificació utilitzada per a les vulnerabilitats d'escalada de privilegis limitats i denegacions de servei locals ( DOS ). La integritat del core i els mòduls no està en perill. Requereix molts cops d'accés com a usuari del lloc.
Less Critical
(Menys crítica)
  • S'utilitza per a les vulnerabilitats de cross-site (sol·licitud falsificació), així com la vulnerabilitat d'elevació de privilegis que requereixen complexes cadenes d'esdeveniments. Aquesta classificació inclou també les vulnerabilitats que podrien exposar les dades confidencials dels usuaris locals.
Moderately Critical
(Moderada-ment crítica)
  • Vulnerabilitats explotables de forma remota que poden comprometre el sistema. La interacció ( per exemple, un administrador visualitza una pàgina en particular ) es requereix per a que aquesta exploit pugui tenir èxit. L'explotació requereix que l'usuari estigui registrat en el lloc i tengui algun permís no predeterminat, com ara la creació de contingut.
Critical
(Crítica)
  • Explotable remotament, inclou vulnerabilitats de denegació de serveis (doS) que poden comprometre el sistema, però no es requereix de l'usuari (pot ser qualsevol connectat a Internet). Vulnerabilitats que poden permetre als usuaris anònims iniciar la sessió com a usuari de la web o prendre accions administratives. Per l'explotació pot ser requerit o no algun desencadenat per part d'un usuari registrat, o en els casos en què no es requereixi la interacció el problema pot produir danys de menor severitat.
Highly Critical
(Molt crítica)
  • Vulnerabilitats explotables de forma remota que poden comprometre el sistema. Qualsevol atacant remot (no cal que sigui usuari registrat) pot realitzar el procediment d'explotació. El que en diem col·loquialment “entrar fins a la cuina”

 

Donada la taula anterior sembla que els tipus d'errors que més ens haurien de preocupar són aquells catalogats com a crítics o molt crítics, res més lluny de la veritat. Les severitats no separen en si mateixes el grau d'afectació d'una vulnerabilitat sobre el projecte desplegat en Drupal, sinó més aviat quantifiquen la dificultat o resistència que té el sistema vers un atacant per a aconseguir el seu objectiu. Així doncs, donat l'individu adequat amb els coneixements necessaris i el temps suficient, una vulnerabilitat moderada o menys crítica pot causar un dany potencial real.

Com puc minimitzar aquests riscos?

Davant d'això els professionals en Drupal com Avellana Digital, tenim previst i empaquetem solucions d'actualitzacions periòdiques per core i mòduls no tant per evitar que mai esdevingui un atac (que és impossible per ningú ni per cap organització), sinó per minimitzar-ne la probabilitat d'èxit, i de que aquest mai vingui d'un problema amb solucions publicades i no aplicades, explotades per tercers amb el conseqüent deteriorament de la imatge corporativa, la funcionalitat, la estabilitat o el rendiment de dites aplicacions.

Aquestes actualitzacions per desgràcia i donat a que normalment el comportament de Drupal es adaptat i parametritzat per a cada client d'una forma molt concreta pot derivar en el mal-funcionament de la web, i sí, tindrem un Drupal “segur”, però que no fa el que volem que faci de la forma en que ho hauria de fer, per això és important que les actualitzacions és realitzin amb les majors garanties i per professionals solvents que assegurin que el transit de versions i correccions no sigui traumàtic.