Even after PHP2Shell, blast radius matters more than a CVSS score

El ar­tícu­lo se­ña­la que las vul­ne­ra­bi­li­da­des co­no­ci­das como PHP2Shell han pues­to en evi­den­cia la ve­lo­ci­dad con la que ocu­rren las ex­plo­ta­cio­nes en com­pa­ra­ción con la len­ti­tud en la apli­ca­ción de par­ches. Los ata­can­tes sue­len apro­ve­char fa­llas antes de que se pu­bli­quen las co­rrec­cio­nes ofi­cia­les, mien­tras que las or­ga­ni­za­cio­nes tar­dan días o se­ma­nas en so­lu­cio­nar los pro­ble­mas, ade­más de en­fren­tar­se al de­sa­fío de una gran can­ti­dad de ser­vi­cios ex­pues­tos en in­ter­net que eje­cu­tan ver­sio­nes vul­ne­ra­bles o di­fí­ci­les de ac­tua­li­zar.

Ante la im­po­si­bi­li­dad de par­chear al mismo ritmo en que se pro­du­cen los ata­ques, se ar­gu­men­ta que prio­ri­zar úni­ca­men­te la gra­ve­dad de las vul­ne­ra­bi­li­da­des me­dian­te las pun­tua­cio­nes tra­di­cio­na­les no es su­fi­cien­te. El im­pac­to real de un in­ci­den­te de­pen­de en gran me­di­da del al­can­ce que tenga el ser­vi­dor com­pro­me­ti­do y de los cre­den­cia­les, cla­ves de API o fi­chas de ac­ce­so a los que el ata­can­te pueda lle­gar tras la ex­plo­ta­ción ini­cial, ya que los agre­so­res sue­len bus­car el ca­mino más sen­ci­llo para mo­ver­se la­te­ral­men­te.

Como al­ter­na­ti­va, se pro­po­ne en­fo­car la se­gu­ri­dad en la ges­tión de iden­ti­da­des y en li­mi­tar el radio de ac­ción de las car­gas de tra­ba­jo afec­ta­das. En lugar de cen­trar todos los re­cur­sos ex­clu­si­va­men­te en la ca­ta­lo­ga­ción y re­pa­ra­ción de fa­llos, es ne­ce­sa­rio in­ven­ta­riar y res­trin­gir los per­mi­sos de cuen­tas de ser­vi­cio, to­kens y agen­tes de in­te­li­gen­cia ar­ti­fi­cial, ase­gu­ran­do que un sis­te­ma com­pro­me­ti­do otor­gue el menor ac­ce­so po­si­ble a los ata­can­tes.