Vulnerabilidade de representação do EAA da Akamai - Um aprofundamento

Nesta publicação, abordamos os detalhes técnicos do CVE-2021-28091, a vulnerabilidade que afeta a plataforma EAA (Enterprise Application Access) da Akamai. Abordamos nosso processo de investigação, correção e divulgação da vulnerabilidade. Para obter uma visão geral da vulnerabilidade, o impacto na Akamai, o impacto nos clientes da EAA e a ações necessárias, consulte nosso relatório complementar.

Visão geral

Nesta seção, mostraremos a história e a anatomia dessa vulnerabilidade. Alguns leitores podem querer pular esta seção por enquanto e ir diretamente para a seção Ações necessárias, usando esta Visão geral como referência em quaisquer avaliações que precisem realizar ou para revisões futuras.

Antes da aquisição da tecnologia EAA pela Akamai por meio de sua aquisição da Soha Systems em 2016, um recurso importante foi introduzido na plataforma, permitindo que os clientes da plataforma tomassem decisões de controle de acesso e autenticação com base nas informações de identidade fornecidas por um provedor de identidade terceirizado. A plataforma EAA oferece vários métodos para integração de identidade de terceiros. O método notável para este relatório é o suporte para o protocolo de autenticação SAML (Security Assertion Markup Language) v2.0.

O SAML é um padrão aberto amplamente usado. O SAML permite que um IdP (Identity Provider, provedor de identidade) afirme, assinando e retornando criptograficamente, a um SP (Service Provider, provedor de serviços) por meio do cliente apresentando um objeto de asserção do IdP para o SP dentro de um período definido. (Consulte a seção Histórico, abaixo, para obter mais informações.)

Quando o suporte ao IdP de terceiros foi adicionado ao EAA, os desenvolvedores selecionaram o Lasso da biblioteca de código-fonte aberto para implementar o suporte a SAML dentro da plataforma. Com base na avaliação do código feita pela Akamai em que o Lasso verifica as respostas SAML fornecidas a ele como um SP, acreditamos que, no momento da integração inicial, os desenvolvedores que implementaram o recurso IdP de terceiros fizeram isso de forma razoável com base nos casos de teste fornecidos com a biblioteca. Uma investigação mais aprofundada revelou que o pacote de testes usado para exercer a implementação da Akamai não era suficientemente rigoroso para identificar essa vulnerabilidade de representação ou pontos fracos semelhantes no processo de autenticação. Essa deficiência foi abordada como parte de nossa resposta, expandindo o conjunto de testes aplicado a novas versões do produto para incluir todas as combinações de respostas e/ou asserções assinadas válidas e inválidas, bem como asserções e respostas não assinadas. Esses novos testes fazem parte do processo de QA (controle de qualidade) padrão daqui para frente.

Nas seções a seguir do relatório, dividimos os vários pontos fracos e fatores contribuintes que compõem a vulnerabilidade geral. Nosso objetivo em fornecer esse nível de transparência é ajudar outras pessoas a entender as medidas tomadas pela Akamai e permitir que elas evitem circunstâncias semelhantes em seus próprios ambientes.

Teste e avaliação do sistema

Testes de unidade, testes de integração e testes de regressão são um aspecto crítico de qualquer SDLC (software development lifecycle, ciclo de vida de desenvolvimento de software). Embora o subcomponente que foi implementado tenha todos esses métodos de teste associados a ele, aprendemos claramente que os testes não eram suficientemente rigorosos. Além disso, esse incidente destacou uma falha em que algumas bibliotecas de terceiros são incorporadas a projetos sob a falsa suposição de que o SDLC da dependência é rigoroso e será informado por descobertas específicas do domínio, como vulnerabilidades em bibliotecas semelhantes.

Embora seja necessário um SDLC rigoroso para cada componente e cada uma de suas dependências, muitas vezes os testes incorporados no desenvolvimento de componentes e no plano de QA não são suficientes. Para complementar esses testes, avaliações contraditórias, como testes de penetração ou revisões de código de terceiros, podem ser empregadas. No caso do EAA, várias avaliações externas de segurança e vulnerabilidade da plataforma EAA foram conduzidas ao longo da vida útil do produto, muitas vezes pelos clientes. Apesar disso, o relatório que iniciou essa resposta foi quem relatou esta vulnerabilidade pela primeira vez à Akamai. A Akamai realizou avaliações direcionadas em relação a outras partes da plataforma EAA e sua aplicação ao cliente, mas esse componente específico não foi submetido a esse nível de análise.

Evitar a divulgação prematura

No início desse processo de resposta a incidentes, a Akamai começou a escrever uma notificação ao cliente de alto nível para orientar os clientes a iniciar as investigações sugeridas na seção Ações necessárias na publicação complementar. Em uma revisão de pré-publicação desse documento, a equipe da Akamai que não foi informada sobre a vulnerabilidade forneceu uma cópia das mensagens voltadas para o cliente. Dentro de uma hora após a mensagem ser enviada, nossos revisores puderam identificar o protocolo afetado (SAML), o pacote afetado (Lasso), e com alguma atividade recente do mantenedor do projeto Lasso, uma suposição sobre qual era a vulnerabilidade. Essa revelação colocou uma pausa imediata em nossos planos de notificação parcial para cumprir os princípios de divulgação responsável. 

Depois de mais conversas com nossos revisores, a equipe de incidentes pôde aprender o processo pelo qual eles fizeram essas descobertas. Uma descoberta importante relatada pelos revisores foi a mensagem de erro retornada pelo IdP quando ocorreu uma condição de erro. Até a correção da vulnerabilidade ser lançada, as falhas de SAML retornavam uma página de erro que expunha o erro do Lasso ao usuário final, conforme mostrado na imagem abaixo. Encaminhar um erro, especialmente para processos críticos de segurança como autenticação, é contrário às práticas recomendadas, e é por isso que o erro não ficará visível para os usuários finais a partir desta versão. 

O documento XML acima foi simplificado para os fins deste relatório, mas a estrutura é a mesma. O documento "principal" externo é a resposta SAML, incluindo metadados sobre a solicitação e um documento de afirmação. A Afirmação, também chamada de Afirmação SAML, são os dados que estão sendo fornecidos do IdP para o SP para uso no processo de autenticação. Várias afirmações podem estar presentes em uma única resposta SAML. No exemplo acima, o conteúdo entre colchetes do ds:Signature é uma assinatura criptográfica sobre o conteúdo do objeto principal, que é a Afirmação neste caso. O mesmo objeto de assinatura também pode ser aplicado a todo o objeto de resposta. O objetivo da assinatura é permitir que o SP valide se os dados contidos na Afirmação ou resposta são legítimos e fornecidos pelo IdP. No caso da Afirmação, a assinatura se aplica somente a todos os dados contidos na Afirmação, como um nome de usuário, um endereço de e-mail ou indicações de membros de grupo. As assinaturas aplicadas no nível de resposta aplicam-se ao conteúdo completo da resposta e a todas as afirmações contidas nela.

A verificação das várias assinaturas na resposta SAML é confiada ao SP e geralmente é configurada no momento em que o IdP é configurado para se comunicar com a aplicação. Em nossa resposta a esse problema, acreditamos que as condições de verificação padrão para respostas SAML devem ser as seguintes.

• Quando toda a resposta SAML é assinada de forma válida, todas as afirmações na resposta devem ser assinadas corretamente ou não ter assinatura. Se alguma assinatura inválida for encontrada, a verificação deverá falhar. Esse método depende do IdP ser autoritativo para todo o corpo da mensagem, que é assinado.
• Quando a resposta SAML não for assinada, todas as afirmações na resposta deverão ser assinadas corretamente, caso contrário, a verificação deverá falhar.
• Quando a resposta SAML tiver uma assinatura inválida, a verificação deverá falhar.

As condições de processamento acima são o que o patch proposto pela Akamai para o Lasso implementou.

O relatório fornecido à Akamai no início deste problema mostrou o pesquisador enviando duas afirmações SAML em uma única resposta SAML. A primeira foi assinada de forma válida, mas a segunda não foi assinada. A configuração padrão para Lasso tinha as seguintes condições de verificação padrão:

• Se a primeira afirmação SAML na resposta foi assinada de forma válida, a verificação foi aprovada, sem considerar a assinatura completa da resposta SAML como válida ou não.
• Se a primeira afirmação SAML foi assinada de forma inválida, a verificação falhou.
• Se a resposta SAML foi assinada de forma válida e nenhuma das afirmações foi assinada, a verificação foi aprovada.
• Caso contrário, a verificação falharia.

 Para complicar as coisas, quando a resposta foi considerada válida pela biblioteca, a função para recuperar a afirmação da resposta SAML retornaria a última afirmação no objeto de resposta, independentemente de ter uma assinatura válida. Por exemplo, digamos que um invasor obtenha uma resposta SAML válida com uma única afirmação de um IdP, como a anterior, e adicione o seguinte como uma segunda afirmação:

Caso o usuário fornecido seja válido para a organização, mas tenha mais privilégios, ele terá a resposta SAML combinada para envio ao SP:

Quando o Lasso tentasse validar essa resposta SAML, o resultado seria que a resposta era válida. Quando o aplicativo de chamada recuperasse a afirmação da resposta acima, a afirmação com o ID de usuário (uid) do superusuário seria retornada e provavelmente assumida como uma afirmação válida. Além do exemplo mostrado acima, se a resposta SAML em si tivesse uma assinatura válida, esse mesmo método de representação seria possível. Esse foi o caso com o processamento de respostas SAML pelo EAA. 

Condições de exploração

Para que a resposta SAML seja modificada antes do envio ao SP, uma das seguintes condições deve ocorrer:

• O cliente legítimo, controlado por um usuário autorizado válido e através do qual uma resposta SAML é redirecionada, deve alterar a resposta SAML injetando o documento de asserção adicional como parte da resposta SAML. Por exemplo, isso pode ocorrer por meio de uma extensão de navegador maliciosa ou outro malware no sistema do cliente, às vezes chamado de "ataque Man-in-the-Browser".
• Um invasor deve obter uma cópia válida de uma resposta SAML que ainda seja válida, seja por ainda ter tempo antes que a afirmação expire ou, em algumas aplicações, a afirmação ainda não foi apresentada ao SP. Por exemplo, uma parte intermediária pode interceptar e modificar uma resposta SAML por meio de um proxy, geralmente chamado de "ataque Man-in-the-Middle".
• Um cliente não autorizado conhece ou é capaz de adivinhar as informações de login de um usuário autorizado. As informações de login podem ser coletadas por meio de muitos processos, incluindo phishing, violações de senha, adivinhação ou ataques do tipo força bruta.

Cada uma das condições acima pode resultar no comprometimento da sessão de um usuário e, se a implementação do SAML for falha conforme declarado acima, o SP ficará vulnerável a um ataque de representação.

Histórico da vulnerabilidade

Essa mesma vulnerabilidade, conhecida como XML Signature Wrapping, foi relatada muitas e muitas e muitas vezes. 

A revisão dos repositórios Lasso indica que os pontos fracos na biblioteca foram incorporados à base de códigos até novembro de 2005, bem antes de nossa incorporação da biblioteca e também antes do lançamento das vulnerabilidades anteriores anunciadas para outras plataformas.

Também notamos durante a investigação que os mantenedores da biblioteca Lasso se comprometeram com o projeto logo após o aviso do problema ter sido enviado à Akamai. Em discussões com o relator, esse compromisso não estava relacionado ao relatório deles, mas foi apenas uma coincidência.

A correção proposta em 24 de fevereiro de 2021 resolveu parcialmente o impacto da exploração, mas após uma análise mais aprofundada, determinamos que não era uma correção completa, e é por isso que nosso patch foi proposto aos mantenedores.

Uma análise da resposta a incidentes da Akamai

A Akamai segue um processo formal de resposta a incidentes. Os incidentes são tratados regularmente pelo esforço cooperativo entre engenharia/desenvolvimento de sistemas, operações de rede e equipe de suporte ao cliente. Em geral, quanto mais grave o incidente, mais pessoas são envolvidas para trabalhar nele e mais ele é priorizado em relação às operações e trabalhos planejados. Em todos os incidentes, o objetivo da Akamai é: 

• Limitar o impacto do problema, 
• Garantir a operação contínua e segura de nossos sistemas,
• Garantir a segurança e o cuidado contínuos dos técnicos que respondem aos incidentes,
• Manter os clientes satisfeitos e seus dados seguros,
• Aderir a várias leis e regulamentos,
• Certificar-se de que somos capazes de aprender e melhorar com quaisquer perigos que permitiram que o incidente ocorresse.

Conforme descrevemos acima, iniciamos nosso processo de resposta a incidentes após a notificação dessa vulnerabilidade. Esse processo permitiu à Akamai alinhar recursos técnicos, comunicar-se com as partes interessadas internas e a administração, comunicar-se com as partes interessadas externas e coordenar todas as atividades relacionadas ao incidente de maneira oportuna e eficaz.

Processo de aplicação e implantação de patches

O processo de desenvolvimento de uma correção para esta vulnerabilidade e implantação do patch na rede EAA era muito semelhante ao processo normal seguido para atualizações planejadas, apenas com uma alteração muito menor e um cronograma muito mais rápido.

Dentro das primeiras horas da resposta a incidentes, preparamos um cronograma preliminar para a correção com algumas decisões importantes levadas em consideração. Após a correção estar pronta, esse cronograma era esperado para que o processo de QA levasse 3 dias após o processo padrão de QA, e a fase de implantação seria de 48 horas. Após a fase de implantação, planejamos a comunicação do problema na forma de uma publicação no blog e notificações ao cliente. Esses cronogramas poderiam ter sido acelerados, mas como não havia evidência de exploração ativa, priorizamos a estabilidade de nossa rede e asseguramos que nossos clientes permanecessem estáveis durante todo o processo.

Após a triagem inicial do problema, a equipe de engenharia abordou a correção por meio de dois caminhos, usando diferentes recursos de engenharia e QA. 

Uma equipe investigou e desenvolveu uma correção parcial para o problema, fechando o problema relatado e restringindo os requisitos no processamento de respostas SAML ao que acreditamos ser a apresentação normal de uma resposta SAML com uma afirmação. Esse método pode ter resultado na recusa de algumas respostas de alguns IdPs, mesmo que elas fossem válidas e seguras. Essa abordagem também tinha a opção de desativar a verificação mais rigorosa por cliente para permitir que o restante da base de clientes fosse protegido no caso de uma interação inesperada com um pequeno número de IdPs.

A outra equipe adotou uma abordagem semelhante à da primeira equipe, mas em vez de uma correção parcial configurável, trabalhou no que acreditamos ser uma correção completa. A abordagem da equipe foi examinada para garantir que todas as respostas SAML bem formadas e assinadas corretamente fossem aceitas, reduzindo a complexidade necessária para permitir que os clientes fossem rebaixados.

Adotamos essa abordagem simultânea porque ela permitiria que um caminho fosse bloqueado ou enfrentasse desafios de QA enquanto ainda permitia a implantação de uma correção. No final do dia 24 de fevereiro, horário do leste dos EUA, esperávamos que a correção parcial estivesse pronta para QA três dias após o início do incidente, enquanto a correção completa deveria levar mais uma semana para ser desenvolvida. O trabalho continuou durante a noite até o dia 25, onde o relatório de progresso da equipe de engenharia mostrou que a opção de correção completa estava progredindo bem e esperava-se que fosse mais rápida de desenvolver e menos complexa de testar.

Por fim, a opção de correção completa foi entregue à equipe de QA cerca de um dia antes da correção parcial. Depois que a primeira opção foi entregue à equipe de QA, uma notificação de patch para todos os clientes do EAA foi publicada, observando o prazo de implantação esperado.

Esse status permaneceu o mesmo durante o processo de QA. Um pouco antes da janela de manutenção, a correção completa recebeu aprovação da equipe de QA, abrindo caminho para a implantação.

O processo de implantação começou com um POP (Point of Presence, ponto de presença) muito leve sobre o qual  executamos um conjunto de regressão estendida com o tráfego sendo monitorado cuidadosamente para possíveis interrupções nos clientes. Outro POP levemente carregado foi atualizado, com um processo de teste reduzido e um período de monitoramento. Nas primeiras horas do dia 2 de março, os POPs que atendiam à implantação interna de EAA da Akamai foram atualizados para permitir mais testes de carga com nossos quase 8.000 usuários finais. Quando não vimos nenhum problema com nenhuma das implantações até aquele momento, o restante dos POPs foi atualizado nas 36 horas restantes da janela de manutenção, concluindo o processo de implantação antes do fechamento da janela de manutenção. 

Durante o processo de atualização, a maioria dos usuários que estavam interagindo com seus aplicativos EAA provavelmente viu uma ou mais interações de re-autenticação.  Normalmente, elas consistem em uma interrupção temporária da sessão e um redirecionamento para seu IdP para inserir suas credenciais antes de serem retornadas ao seu trabalho normal. Os usuários do Cliente EAA também podem ter observado esse comportamento. As tentativas de re-autenticação foram agrupadas por clientes EAA durante a implantação. Após a atualização do código em cada POP, o cache de sessão mantido pelo EAA foi apagado, o que, em uma janela de 5 minutos, acionaria uma re-autenticação para todas as solicitações. Uma vez autenticadas novamente, não observamos mais nenhum impacto nos usuários finais.

Gerenciamento da equipe de incidentes

Um aspecto fundamental para desenvolver, verificar e implantar com segurança a correção em nossa rede para problemas significativos como esse inclui um foco cuidadoso em cuidar da equipe que está trabalhando em um problema. O processo de gerenciamento de incidentes da Akamai e o treinamento que o acompanha incluem orientações sobre como limitar o esgotamento das equipes técnicas e de gerenciamento que respondem a um incidente. Essa orientação inclui verificar se a equipe de incidentes:

• Come (regularmente)
• Dorme (idealmente uma "noite" completa de sono)
• Dedica-se a compromissos pessoais
• Permanece saudável (vacinas contra COVID-19, exercícios físicos)

Embora remediar o incidente em questão seja urgente, descobrimos que manter o cuidado da equipe durante todo o processo ajuda a alcançar um destino mais seguro para o produto e/ou sistema afetado, além de reduzir o número de erros evitáveis e eventos que podem afetar o cliente frequentemente associado à resposta a incidentes de alto estresse.

Outro aspecto fundamental do processo de gerenciamento de incidentes da Akamai é o princípio de que estamos todos juntos nisso e não vamos culpar ninguém agora ou no futuro. A equipe de incidentes trabalha em conjunto para resolver o problema, seja ele qual for, da melhor maneira possível, focando primeiro na redução do impacto, para depois descobrir como evitar que ele aconteça novamente. A Akamai se concentra em encontrar as suposições que levaram a um incidente, aprendendo com essas suposições incompletas e fazendo as modificações apropriadas para reduzir as chances de que eventos semelhantes ocorram novamente.

Ações necessárias

Os proprietários do sistema que dependem do Lasso para sua autenticação SAML devem corrigir o mais rápido possível. Ações adicionais podem ser necessárias para investigar o impacto nos sistemas autenticados. Mais informações sobre quais ações podem ser necessárias podem ser encontradas na seção Ações necessárias da publicação complementar a este documento.

Linha do tempo