Nossa análise sobre a vulnerabilidade de dia-zero do Adobe Flash usada na campanha Pawm Storm mais recente revela que as técnicas de mitigação introduzidas pela Adobe não foram suficientes para proteger a plataforma.
Usada na Pawn Storm visando certos ministérios de relações exteriores, a vulnerabilidade identificada como CVE-2015-7645 representa uma mudança significativa nas táticas de exploits anteriores. É importante observar que a Adobe lançou o boletim APSB15-27 para resolver essa vulnerabilidade; a versão mais recente do Flash (19.0.0.226) não está mais vulnerável.
Informações anteriores
A Adobe introduziu várias técnicas de mitigação para as explorações do Flash no começo desse ano, trabalhando juntamente com o Google Project Zero. Essas técnicas de mitigação focaram em reduzir exploits de Vector.<*>, porque um Vector.<*> era frequentemente usado para conseguir ler e escrever partes arbitrárias da memória. Isso permite que várias técnicas de segurança, como DEP/ASLR/CFG/EMET, sejam ignoradas e consigam a Execução de Código Remoto (RCE – Remote Code Execution) dentro do processo do navegador.
Depois que essas mitigações foram estabelecidas, os exploits no mundo real diminuíram, mas não desapareceram completamente. Essa vulnerabilidade mais recente é o exploit de dia-zero descoberto no mundo real depois que essas mitigações foram adicionadas.
Como a CVE-2015-7645 foi usada na Pawn Storm
Como relatamos anteriormente, a Pawn Storm usou um exploit de dia-zero para visar muitos ministérios de relações exteriores em todo o mundo. Os alvos recebiam emails spear-phishing contendo URLs levando ao exploit. Os emails (especialmente os assuntos e strings de URLs) eram elaborados para sugerir que eram relacionados aos artigos de notícias sobre eventos recentes)
O exploit é baixado quando a vítima clica na URL no email. O exploit, que foi detectado como SWF_OLOLO.A, então baixa um arquivo DLL (“marlou.fel”) detectado como TROJ_SEDNIT.D. O TROJ_SEDNIT.D, que baixa outro arquivo DLL (“mgswizap.dll”) detectado como TSPY_SEDNIT.D. As variantes SEDNIT são conhecidas como os malware usados em todas as campanhas Pawn Stom.
Analisando a causa raiz da vulnerabilidade
Essa vulnerabilidade em particular é de um novo tipo, que podemos chamar de Method Confusion. É a vulnerabilidade do Flash mais interessante que já analisamos.
A amostra do exploit do SWF foi ofuscada. Depois da ofuscação e análise, descobri que o bug estava localizado no método writeObject do objeto ByteArray. Ao processar o ba.writeObject(some_obj), se o some_obj for um objeto de um tipo que implementa a interface flash.utils.IExternalizable, ele chamará o método do writeExternal de IExternalizable.
O método writeExternal deve ser implementado na definição do some_obj class. Porém, se houver um campo de propriedade também chamado writeExternal e definido de uma maneira incomum, o writeExternal da propriedade ocultará o método do writeExternal.
A definição complicada pode ser algo como a imagem abaixo:
Figura 1. Definição classe personalizada
Depois que o método writeExternal é oculto pela propriedade do writeExternal, ele fará com que o binding_id do método tenha um valor errado. No ba.writeObject(some_obj), ele precisa obter primeiro a função binding_id do writeExternal. Ele então usará isso para obter a estrutura de ambiente do método usando uma sentença, tal como methods[binding_id].
Depois de obter o ambiente do método, ele pode ser JITed para o código nativo, que então é chamado.
Esses são os passos simplificados para chamar o método writeExternal no ba.writeObject(some_obj):
- Encontrar o nome de busca da função binding_id do writeExternal no espaço de nomes público
- Obter a estrutura de ambiente do método por meio do methods[binding_id]
- JIT o ambiente do método para o código nativo e chamá-lo.
Você pode encontrar o código relativo no projeto de código aberto AVMPlus. No construtor ClassInfo, ele descobrirá que a m_functionBinding usa o espaço de nomes público e a string kWriteExternal.
Figura 2. Obter o trecho do código de vinculação da função (function binding code snippet) do kWriteExternal
Figura 3. Encontrar o trecho do código do cursor (pointer code snippet) do MethodEnv
A sentença chave na figura acima é MethodEnv* method = obj->vtable->methods[id].
Nós sabemos que a ID de ligação da função (function binding id) do writeExternal está errada depois de ter sido ocultada pela propriedade do writeExternal porque ao fazer a busca encontraremos a propriedade pública do writeExternal.
Isso significa que os exploits agora podem construir uma definição de classe personalizada para obter o valor da função binding_id desejado.
A partir do código fonte do AVMPlus, podemos ver que ele irá ler o método a partir do obj->vtable->methods[id]. O valor da id pode ser controlado, portanto os exploits podem controlar a leitura do MethodEnv*. A partir desse ponto, a vulnerabilidade se tornou um caso de leitura fora do limite; os exploits podem controlar o layout da memória para estabelecer um MethodEnv* de sua escolha no slot da função de id falsificada.
O exploit então usa outro método AS3 definido em personalização, a ser chamado usando o ksome_externalizable_obj como esse cursor. Parece ser um caso de confusão de tipo, agora.
Resumindo, os passos desse exploit são:
- Definir classe A que implementa o utils.Iexternalizable. A Classe A define o método writeExternal e a propriedade do writeExternal dentro do espaço de nomes público. Controlar o pedido da propriedade do writeExternal para controlar a binding_id da função falsa.
- Definir classe B e definir o método B com o código malicioso que deve ser chamado. Os novos objetos dessa classe são usados para controlar o layout da memória e garantir que a estrutura de ambiente do método B seja alocado na binding_id falsa.
- Criar um novo externalizable object a partir da classe A e depois usar o writeObject(externalizable_object) para acionar a vulnerabilidade.
- O método B será chamado e o agressor pode manipular esse cursor do externalizable_object nesse método.
Indo para além do Vector.<*>
Aqui está como o agressor usou essa vulnerabilidade: A amostra sobrescreveu o campo de comprimento de um objeto baseado em ByteArray como 0Xfffffff6. Usou-o para ler e escrever em locais de memória arbitrários. As mitigações para o Vector.<*> são inúteis aqui, já que o comprimento do ByteArray não está protegido.
Os agressores não dependem do Vector.<*> como alvo para explorações no futuro. Como esse ataque mostrou, existem outros objetos que podem ser usados ( ou abusados) pelos agressores. A Adobe deve proteger o comprimento do ByteArray e outros objetos que podem ter a propriedade de comprimento.
Detalhes da depuração (debugging)
Eu construí uma prova de conceito (PoC) simplificada que demonstra a vulnerabilidade e a depurei. Primeiro, eu configurei a propriedade do objeto writeExternal para ser a 28º propriedade. A PoC não controla o layout da memória do slot do binding_id, portanto ele lerá um cursor de ambiente de método lixo e causará uma falha.
Eu usei uma extensão windbg para ajudar a depurar essa PoC. Essa extensão pode ajudar e estabelecer um ponto de interrupção nos métodos AS3. Com isso, eu posso invadir facilmente o MethodEnv* method = obj->vtable->methods[id].
Figura 4. Saída do depurador (debugger)
Conclusão
As mitigações podem diminuir os exploits mas não são mágicos. A história provou que vulnerabilidades boas ou perfeitas podem burlar as mitigações, fazendo com que seja muito importante que os usuários tenham uma defesa em multicamadas contra esses exploits de dia-zero. As tecnologias da Trend Micro protegem os usuários desses exploits de dia-zero, oferecendo proteção para todas as diferentes camadas dentro de uma infraestrutura.
A Sandbox existente com o mecanismo Script Analyzer, que faz parte do Trend Micro™ Deep Discovery, pode ser usada para detectar ataques usando o Dia-Zero do Adobe Flash por seu comportamento, sem qualquer mecanismo ou atualizações de vacinas.
As soluções Trend Micro Deep Security e Vulnerability Protection, por outro lado, protegem os sistemas dos usuários dessas ameaças que podem se aproveitar do dia-zero do Adobe Flash com a regra DPI 1007119 – Arquivo SWF Malicioso Identificado do Adobe Flash.
As hashes SHA1 de arquivos relacionados a essa ameaça são:
- 2DF498F32D8BAD89D0D6D30275C19127763D5568 – detectada como SWF_OLOLO.A
- 20F5A9C0E1D2AEF36D15CA149FE71AC6B2A9AF1E – detectada como TROJ_SEDNIT.D
- A5FCA59A2FAE0A12512336CA1B78F857AFC06445 – detectada como TSPY_SEDNIT.D
Com análise adicional de Stanley Liu
Atualizado em 17 de outubro, 19:29 PDT (UTC-7) para adicionar as hashes SHA1 relacionadas a essa exploração mais recente do Flash.
