Cadeia combinava CSP permissiva, XSS armazenado, ausência de token CSRF e fragilidade no fluxo de SSO para executar ações em nome do usuário e alcançar aplicações como Jira e Bitbucket.
| Componente | Conta Atlassian conectada por SSO a serviços como plataforma de treinamento, Jira, Confluence, parceiros e possível acesso ao Bitbucket. |
| Vetor | Encadeamento de XSS armazenado no parâmetro options._training_credit_account, ação induzida no carrinho, falta de token CSRF e manipulação de fluxo SSO. |
| Impacto | Execução de ações em nome do usuário, tomada de conta em aplicações Atlassian conectadas e risco condicionado de acesso a repositórios Bitbucket. |
| Prioridade | Validar correção aplicada, revisar sessões e integrações SSO, auditar atividades em Jira e Bitbucket e reduzir permissões persistentes em contas colaborativas. |
| Artefatos | Subdomínio training[.]atlassian[.]com, diretivas CSP permissivas unsafe-inline e unsafe-eval, parâmetro options._training_credit_account e cookie JSESSIONID. |
| Mitigação | Aplicar controles contra XSS e CSRF, endurecer CSP, limitar redirecionamentos e revisar emissão, escopo e prioridade de cookies de sessão. |
Uma cadeia de falhas em serviços Atlassian permitia transformar uma vulnerabilidade de aplicação web em tomada de conta dentro de um ambiente integrado por SSO. O ponto inicial estava no subdomínio training[.]atlassian[.]com, usado para cursos e créditos de treinamento. O ambiente aceitava um fluxo de carrinho no qual itens do tipo training_credit adicionavam o parâmetro options._training_credit_account à requisição. Esse parâmetro era vulnerável a XSS armazenado, o que permitia que código controlado pelo invasor fosse persistido e executado quando o fluxo do carrinho fosse processado pelo usuário alvo.
A gravidade vinha do encadeamento. A vulnerabilidade de XSS não era tratada como um evento isolado de interface, mas como uma etapa para alcançar o fluxo de autenticação federada. A política de segurança de conteúdo do subdomínio estava permissiva, com diretivas como unsafe-inline e unsafe-eval, o que reduzia a capacidade do navegador de bloquear execução de script injetado. Além disso, a ausência de token CSRF no fluxo do carrinho permitia induzir ações sem uma confirmação transacional forte do usuário autenticado. Com esses elementos juntos, a exploração podia executar ações em nome da vítima e avançar para etapas ligadas ao SSO.
O cenário se enquadra em risco de cadeia de suprimentos porque plataformas colaborativas como Jira, Confluence e Bitbucket concentram código, tickets, documentação, decisões operacionais e integrações entre equipes. Uma conta comprometida nesse tipo de ecossistema não representa apenas acesso a um painel administrativo: ela pode servir como ponto de apoio para abrir tickets, influenciar comunicações internas, acessar dados que não deveriam ser vistos por terceiros e, quando houver permissões suficientes, alcançar repositórios de código. O contexto também descreve que uma correção foi implantada após divulgação responsável, o que desloca a resposta defensiva para validação de exposição histórica, revisão de logs e fortalecimento de controles similares.
O primeiro elo técnico estava na combinação de CSP fraca e XSS armazenado. Uma CSP com unsafe-inline e unsafe-eval permite classes de execução que normalmente seriam restringidas em uma configuração mais defensiva, principalmente quando a aplicação processa conteúdo vindo de parâmetros de requisição. No fluxo analisado, a adição de créditos de treinamento ao carrinho incluía options._training_credit_account, e esse campo foi identificado como ponto de injeção. Como o XSS era armazenado, a carga não dependia apenas de refletir conteúdo em uma resposta imediata: ela podia ser persistida no estado do fluxo e disparada quando a vítima interagisse com o carrinho.
A etapa seguinte dependia da falta de proteção CSRF no carrinho. Em um desenho robusto, ações que alteram estado deveriam exigir token imprevisível, vinculado à sessão e validado no servidor. Sem esse controle, uma página externa poderia induzir o navegador da vítima autenticada a enviar requisições que adicionassem o item malicioso ao carrinho. O contexto informa que o encadeamento também contornava uma proteção SameSite configurada como Strict, o que reforça a importância de não tratar cookies com SameSite como substituto completo para CSRF token, validação de origem e desenho transacional seguro.
Após conseguir executar ações no contexto do usuário, a análise avançou para o fluxo de SSO. O comportamento de redirecionamento e a prioridade de caminho associada ao cookie JSESSIONID permitiam controlar um identificador de sessão sem informação útil no backend. Quando uma página de perfil era acessada com essa condição, o usuário era redirecionado para autenticação. O fluxo de autorização envolvia provedores e parâmetros de redirecionamento usados para navegar entre serviços Atlassian. A fragilidade descrita não deve ser interpretada como uma simples falha de login, mas como uma composição de estado de sessão, caminho de cookie e redirecionamento que podia ser alinhada ao XSS inicial para ampliar o controle sobre a conta.
Com a conta Jira nas mãos, o alcance potencial se estendia a interações com Bitbucket. O contexto descreve uma rota em que um ticket Jira poderia conter link para infraestrutura controlada pelo invasor, gerando e-mail automático do domínio Atlassian para a vítima. Esse mecanismo poderia aumentar a credibilidade da isca por vir de um fluxo legítimo da plataforma. O risco sobre Bitbucket era condicionado às permissões da conta e à resposta do usuário, mas o impacto técnico citado incluía acesso a repositórios, alteração de código, exposição pública de código e implantação de backdoors em projetos quando o invasor conseguisse obter acesso suficiente.
A superfície principal era formada por contas Atlassian usadas em ambientes de trabalho colaborativo e conectadas por SSO entre produtos. Isso inclui organizações que utilizavam serviços como Jira e Confluence para gestão de projetos, documentação e colaboração, além de usuários com relações de acesso a plataformas de treinamento e parceiros. O subdomínio de treinamento funcionava como ponto de entrada porque aceitava operações de carrinho e créditos, mas o risco real emergia quando esse ponto se conectava ao restante da identidade Atlassian.
A exposição mais sensível recaía sobre usuários com acesso amplo ou permissões relevantes em aplicações internas. Uma conta com privilégios de leitura em documentação pode expor informações operacionais; uma conta com capacidade de abrir ou manipular tickets pode influenciar fluxos de trabalho; uma conta com acesso a repositórios Bitbucket pode afetar código-fonte. O contexto não confirma exploração ativa em clientes nem lista versões ou tenants específicos afetados, portanto a leitura defensiva deve se limitar ao modelo de falha descrito e aos serviços nomeados. Ainda assim, qualquer organização que dependa de SSO entre aplicações colaborativas deve tratar esse caso como exemplo de como uma falha em uma aplicação periférica pode atravessar fronteiras de confiança.
Também há uma dimensão temporal importante: a descoberta ocorreu em 16 de novembro de 2020 e a publicação original associada ao caso é de 24 de junho de 2021. Como a correção foi descrita como implantada, o foco operacional não é reproduzir a cadeia, mas verificar se há sinais históricos de abuso, revisar controles equivalentes em integrações próprias e confirmar se aplicações internas não mantêm padrões semelhantes de CSP permissiva, ausência de CSRF e redirecionamentos SSO pouco restritos.
- Contas Atlassian autenticadas por SSO e usadas para transitar entre serviços colaborativos.
- Fluxo de treinamento em
training[.]atlassian[.]comcom carrinho, créditos e parâmetrooptions._training_credit_account. - Serviços Jira e Confluence como aplicações conectadas ao mesmo ecossistema de identidade.
- Bitbucket como superfície condicionada quando a conta comprometida também possui permissões sobre repositórios.
A investigação defensiva deve começar pelos registros de identidade e sessão. Eventos relevantes incluem redirecionamentos anômalos entre serviços Atlassian, mudanças inesperadas em cookies de sessão, sequência incomum de acesso ao subdomínio de treinamento seguida por autenticação em Jira e atividades de conta fora do padrão normal do usuário. Como a cadeia depende de ações realizadas no navegador da vítima, logs de proxy, EDR e navegador corporativo podem ajudar a reconstruir a ordem de eventos: visita a página externa, requisições para o carrinho, carregamento do conteúdo armazenado e transição para autenticação federada.
No lado de aplicação, equipes devem procurar valores incomuns em parâmetros relacionados a créditos de treinamento, principalmente entradas que contenham marcações ou padrões compatíveis com tentativa de execução de script. O objetivo não é publicar ou reaproveitar payloads, mas identificar quando campos esperados para dados de conta ou metadados de treinamento receberam conteúdo incompatível com seu tipo. Também é relevante revisar eventos em que ações de carrinho ocorreram sem navegação humana coerente, sem referenciador esperado ou em sequência temporal alinhada a acessos vindos de domínios externos.
Em Jira, a caça deve observar tickets criados por contas que normalmente não abrem solicitações daquele tipo, mensagens contendo links externos não usuais, mudanças de comportamento logo após autenticação SSO e e-mails automáticos enviados a partir de fluxos legítimos com conteúdo suspeito. Em Bitbucket, a atenção deve ir para convites, alterações de permissão, clonagens incomuns, criação ou modificação de chaves, mudanças em visibilidade de repositórios, commits não esperados e alterações em arquivos sensíveis de build, dependências ou pipelines. O contexto não fornece IoCs maliciosos confiáveis para publicação; por isso, a defesa deve priorizar padrões comportamentais e correlação entre identidade, aplicação e repositório.
- Acesso ao
training[.]atlassian[.]comseguido por fluxo SSO e atividade em Jira dentro de janela curta. - Parâmetros de carrinho com conteúdo incompatível com dados de créditos ou conta de treinamento.
- Tickets Jira criados com links externos incomuns e e-mails automáticos subsequentes para usuários internos.
- Eventos Bitbucket de alteração de código, permissão, visibilidade ou chaves logo após atividade anômala da conta.
- Sessões com redirecionamentos repetidos, cookies de caminho específico e autenticações sem interação esperada do usuário.
A primeira medida é confirmar que a correção do fornecedor está aplicada e que os ambientes Atlassian usados pela organização não dependem de configurações legadas. Como a falha foi descrita como corrigida após divulgação responsável, a resposta prática deve incluir validação de status, revisão de acessos históricos e análise de contas com permissões elevadas. Para organizações que usam Atlassian Cloud ou integrações Atlassian com identidade corporativa, a equipe de segurança deve revisar eventos antigos próximos ao período de exposição, especialmente em contas de administradores, mantenedores de repositório, líderes técnicos e usuários com acesso a dados sensíveis.
No plano de engenharia, o caso reforça controles clássicos que continuam decisivos em ambientes federados. CSP deve ser restritiva e baseada em origens explicitamente necessárias, sem liberar execução inline ou avaliação dinâmica quando a aplicação processa dados de usuário. Fluxos que alteram estado, como carrinhos, créditos, preferências e integrações, devem validar token CSRF, origem, método HTTP e intenção do usuário. Campos como options._training_credit_account devem passar por validação de tipo, normalização e codificação de saída apropriada ao contexto HTML, JavaScript ou atributo em que forem renderizados.
Para SSO, a mitigação deve incluir controle estrito de redirect_uri, validação de estado, escopo mínimo, cookies com caminho e domínio cuidadosamente definidos e monitoramento de fluxos silenciosos de autenticação. A prioridade de cookies por caminho precisa ser testada em cenários de colisão, porque um cookie mais específico pode alterar o comportamento observado pelo navegador e criar divergência entre o estado visto no cliente e o estado real no backend. Essas verificações devem fazer parte de testes de segurança em qualquer ambiente que una aplicações distintas sob a mesma identidade.
Em repositórios, a contenção deve considerar que uma conta colaborativa comprometida pode deixar efeitos persistentes. É necessário revisar alterações em código, configurações de pipeline, credenciais de CI/CD, chaves de deploy, webhooks e permissões adicionadas durante a janela suspeita. Caso haja indício de acesso indevido, a organização deve revogar sessões, rotacionar segredos expostos a repositórios ou pipelines, remover integrações não reconhecidas e revalidar histórico de commits por responsáveis técnicos. A meta é eliminar persistência e reduzir a possibilidade de que uma tomada de conta temporária tenha introduzido mudanças duradouras.
- Confirmar correção aplicada e revisar logs históricos de contas com acesso a Jira, Confluence e Bitbucket.
- Endurecer CSP removendo permissões desnecessárias como execução inline e avaliação dinâmica quando possível.
- Exigir token CSRF e validação de origem em todos os fluxos que alteram estado do usuário.
- Validar rigorosamente parâmetros de SSO, redirecionamentos, escopos e prioridade de cookies por caminho.
- Auditar repositórios, pipelines, webhooks, chaves e permissões associadas a contas que apresentaram atividade anômala.
0 Comentários