Víctor Mayoral-Vilches Cibercrime em Robótica, pesquisa da Alias Robotics que viaja para Black Hat Robôs industriais são seguros? É a dúvida com que essa análise começa, a partir da Alias Robotics, trabalhamos em conjunto com a TrendMicro em uma pesquisa sobre segurança robótica...
ElevenPaths Boletim semanal de cibersegurança 2 maio-4 junho Vulnerabilidade no SonicWall Network Security Manager A SonicWall lançou patches de segurança, para lidar com uma vulnerabilidade que afetaria as versões locais da solução de gerenciamento de firewall multiusuário do...
Nova pesquisa: descobrimos como contornar o SmartScreen através de um hijacking sem privilégios no COMElevenPaths 29 abril, 2019 A técnica de COM Hijacking é um sequestro do objeto COM e tem uma base teórica muito simples, semelhante à um sequestro de DLL: O que acontece quando um aplicativo procura por um objeto COM inexistente no computador no qual está sendo executado? Ou quando o objeto existe, mas não é encontrado na chave do registro onde foi pesquisado? Um invasor pode criá-lo com informações adulteradas, por exemplo, usando uma rota que em vez de levar à DLL solicitada, leve a vítima a uma criada pelo invasor. Pode-se assim aproveitar o padrão no qual um computador trabalha para encontrar esse objeto, contornando o SmartScreen no Windows. Pequena introduçãoO COM (Component Object Model) é um modelo de interface binária para componentes de software, ele permite a comunicação entre processos e a criação dinâmica de objetos, independentemente do idioma em que foram programados. O COM oferece um ABI (Application Binary Interface) estável que não muda com as diferentes versões dos compiladores. Esta estabilidade é muito atraente para desenvolvedores C ++, onde o código deve ser compartilhado com diferentes clientes usando diferentes versões de compiladores. Normalmente os objetos COM são compilados como uma DLL, mas a maneira de usá-los é diferenciada. Os objetos COM devem ser exclusivamente identificáveis no momento da execução e, para isso, uma identificação conhecida como GUID é usada, como por exemplo: {CB4445AC-D88E-4846-A5F3-05DD7F220288} Cada objeto COM é registrado com seu GUID correspondente, acompanhado por uma ou mais chaves que fornecem informações sobre o próprio objeto como o caminho real de sua DLL. Normalmente os objetos COM são registrados das seguintes formas no Registro: HKLM \ SOFTWARE \ Classes \ CLSID ou HKLU \ SOFTWARE \ Classes \ CLSID. Neste registro sob a chave GUID correspondente, as chaves de Registro InprocServer, InprocServer32, InprocHandler e InprocHandler32 são geralmente usadas para fornecer as rotas para a DLL do objeto. Se o objeto COM estiver sob a raiz HKEY_LOCAL_MACHINE (HLKM), significa que está disponível para todos os usuários do computador e que foi criado com permissões de administrador do sistema. Enquanto aqueles criados sob a raiz HKEY_CURRENT_USER (HCKU) são válidos para o usuário atualmente autenticado e não necessariamente criado por um administrador. A ordem de busca natural do sistema é um processo muito interessante. Um cenário comumente usado pelo sistema é o de pesquisar primeiro o ramo do usuário e depois o ramo do computador onde ele é executado. Pense em um aplicativo que, quando iniciado, precisa usar as funções do objeto COM localizado na seguinte chave do Registro: HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{CB4445AC-D88E-4846-A5F3-05DD7F220288}\InprocServer32 Porém antes de pesquisá-lo, o aplicativo primeiro irá procura a seguinte rota: HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID\{CB4445AC-D88E-4846-A5F3-05DD7F220288}\InprocServer32 Supondo que esta última chave não exista estaremos enfrentando um aplicativo vulnerável ao uso de COM Hijacking. Executar a técnica não implica mais do que criar a seguinte estrutura no registro: HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID {CB4445AC-D88E-4846-A5F3-05DD7F220288} InprocServer32 (Default) = C:\DLLsMaliciosas\miDLL.dll COM Hijacking como persistenciaA técnica de COM Hijacking com persistência tem várias vantagens em comparação com o resto das técnicas tradicionais que se infiltram na raiz. Pois normalmente é melhor ter um objeto COM nativo chamado toda vez que o sistema for iniciado. O principal problema com isso é que os objetos COM nativos geralmente são encontrados no HKCR (classes raiz) em vez de consultar o registro do usuário, desta forma um usuário por si próprio não deve ser capaz de acessá-lo.Na verdade, o HKCR é uma visualização virtual do que vemos em HKCU e HKLM. O que significa que se você quiser escrever uma chave… HKCR\CLSID\{A47979D2-C419-11D9-A5B4-001185AD2B89 Pode-se cria-la no seguinte caminho Portanto, para executar o Hijacking para o objeto COM nativo do Windows, você pode criar a esta chave como se mostra na imagem a seguir e assim dissemina-la. Devido a forma como se trabalha o HKEY_CURRENT_USER (HKCU), a permissão de administrador não se faz necessária para executar o ataque. Uma vez que a chave de registro é criada, o código contido na DLL introduzida será executado toda vez que o aplicativo vulnerável encontrar o objeto COM sequestrado e carregar a DLL maliciosa. Elevar privilégios através do Event Viewer e do Task SchedulerPara elevar os privilégios por meio de uma técnica como a do Hijacking COM você deve aproveitar um aplicativo vulnerável que é executa-lo com privilégios elevados (admin) e com alta integridade de processo. As aplicações Event Viewer e Task Scheduler invocam um processo de alta integridade e alto nível chamado mmc.exe. Este é usado por várias aplicações do Windows.As funções mencionadas procuram objetos COM na seguinte rota: HKCU\Software\Classes\CLSID\{0A29FF9E-7F9C-4437-8B11-F424491E3931}\InprocServer32 O que aconteceria se um sequestro de COM fosse feito para esse objeto? Na linha abaixo mostramos como simular o comando: powershell.exe -Command {$Path=»HKCU:\Software\Classes\CLSID\{0A29FF9E-7F9C-4437-8B11-F424491E3931}\InprocServer32″;$Name=»(Default)»;$Value=»C:\\MisDLLs\epp1.dll»;New-Item -Path $Path -Force;New-ItemProperty -Path $Path -Name $Name -Value $Value} Uma vez invocado o processo vulnerável, ele encontrará o objeto COM (apriore não contaminado) e executará a DLL maliciosa, que nesse caso é um shell meterpreter (que em suma é um payload do tipo staged) localizado em «C: \ MisDLLs \ epp1.dll»Como o processo vulnerável possui um privilégio alto (admin) e possui alta integridade, o shell fornecido passa a ter privilégios SYSTEM sem problemas. Uma técnica similar foi usada para contornar o UAC. Passando despercebido: SmartScreen é vulnerável ao Hijacking de COMHá algum tempo descobrimos como os “agressores” conseguiram contornar o SmartScreen explorando as técnicas de sequestro de DLL. Essa abordagem de Hijacking alcança efeitos semelhantes, mas de uma forma diferente. Toda vez que um programa é executado no Windows, o SmartScreen é executado para tentar nos proteger.… Não importa qual seja o programa, cada execução passa pelo SmartScreen, que consulta na nuvem se o programa pode representar um risco para o sistema ou não. Todavia o SmartScreen é vulnerável ao Hijacking do COM Veja que toda vez que um binário é executado, o SmartScreen também é executado e, toda vez que o SmartScreen é executado, vários objetos COM são pesquisados no registro sem sucesso. Entre eles: HKCU\Software\Classes\CLSID\{A463FCB9-6B1C-4E0D-A80B-A2CA7999E25D}\InprocServer32. Através de uma DLL, você pode executar um sequestro neste objeto através do seguinte comando na console do Powershell: Após a execução do script acima faz com que qualquer programa que o usuário execute acione juntamente o SmartScreen e, por sua vez, será o mesmo processo que carregará e executará a DLL maliciosa, neste caso, retornando um shell do meterpreter. Na prova de conceito, usamos simplesmente uma DLL que mostrava um Hello World, matando desta forma um processo que deveria nos proteger. Embora você também possa simplesmente usá-lo para substituí-lo o SmartScreen.\ e se tronar permanente, como no video abaixo: Nós alertamos a Microsoft sobre essa vulnerabilidade em potencial, que permitiria a persistência e o burlar de uma função de segurança. Gostou? Que saber mais? Veja o estudo completo em: COM Hijacking, a technique still alive from ElevenPaths Inovação e laboratório na ElevenPathswww.elevenpaths.com Lazarus, levante e caminhe…Se você quer mudar os hábitos de segurança dos seus colaboradores, não conte com vontade própria, mude o ambiente
Telefónica Tech Boletim semanal de Cibersegurança 21 – 27 Janeiro Killnet visando vítimas na Espanha Esta semana, o grupo hacktivista Killnet anunciou uma campanha de ataques contra a Alemanha, levando a ataques de Negação de Serviço Distribuído (DDoS) que tornaram...
Telefónica Tech Boletim semanal de Cibersegurança 14 – 20 Janeiro Vulnerabilidades críticas nos roteadores Netcomm e TP-Link Várias vulnerabilidades foram descobertas nos roteadores Netcomm e TP-Link. Por um lado, as falhas, identificadas como CVE-2022-4873 e CVE-2022-4874, são um caso de estouro de...
Telefónica Tech Boletim semanal de Cibersegurança 31 Dezembro – 6 Janeiro Cadeia de dependência do PyTorch é violada O PyTorch, uma popular estrutura de aprendizado de máquina de código aberto, alertou os usuários que instalaram o PyTorch todas as noites entre...
Telefónica Tech Boletim semanal de Cibersegurança 3 – 9 dezembro Nono 0-day do ano no Chrome O Google lançou o Chrome 108.0.5359.94 para Mac e Linux, e o 108.0.5359.94/.95 para Windows, que corrige uma vulnerabilidade de 0-day, a nona detectada...
Telefónica Tech Boletim semanal de Cibersegurança 28 outubro – 4 novembro Uso de Raspberry Robin em cadeias complexas de infecção Pesquisadores da Microsoft relataram nos últimos dias novas descobertas sobre o malware Raspberry Robin. De acordo com sua análise, esse software...
Telefónica Tech Boletim semanal de cibersegurança, 30 abril — 6 maio TLStorm 2 – Vulnerabilidades em Switches Aruba e Avaya Pesquisadores da Armis descobriram cinco vulnerabilidades na implementação de comunicações TLS em vários modelos de switch Aruba e Avaya. Especificamente, as...