PSA: Shell Clássico é agora Menu Shell Aberto – e um aviso

Nova informação para usuários e partes interessadas da ferramenta Shell Clássico do Windows: O projeto de acompanhamento já foi renomeado novamente e agora se chama Menu Shell Aberto. Aqui estão algumas informações e uma dica porque eu (atualmente) diria ‘tenha cuidado”.

Há um software que se mantém no foco das atenções através da renomeação. Eu classificaria o projeto Shell Clássico nesta categoria, pois este projeto foi renomeado novamente.

>

alguns antecedentes

O desenvolvedor do Shell Clássico, Ivo Beltchev, parou de desenvolver o software há algum tempo. Mas ele deu o código fonte para a comunidade para manutenção posterior. Eu bloguei sobre isso dentro do meu blog alemão.

Mas o que não é tão bom para o meu gosto: No momento, o projeto produz atualmente apenas manchetes devido a múltiplas renomeações. Por um curto período a ferramenta foi chamada Classic Start. Então a comunidade decidiu renomeá-la no final de julho de 2018 para NeoClassic-UI/Menu. Talvez existam boas razões, não sei, nunca foram mencionadas.

O próximo novo nome …

E agora o projeto foi renomeado para Open-Shell-Menu. O arquivo de instalação atual é agora chamado OpenShellSetup_4_4_126.exe, mas a funcionalidade provavelmente não foi alterada. O projeto está disponível no GitHub, mas nem todos os links estão funcionais ainda. O atual Nightly Build está disponível aqui, que expira após 6 meses.

O lado escuro deste projeto: Segurança

Beside the ‘a sack rice fell over in China, please continue, nothing to see’, eu gostaria de salientar que você deve manter suas mãos longe desta ferramenta (pelo menos, até que os desenvolvedores tenham consertado algumas coisas fundamentais). Porquê este aviso?

Estou em contacto com o hacker de chapéu branco Stefan Kanthak (ver) desde há algum tempo (a Microsoft inscreve-o no Top 100 do MSRC 2017 e também noutras listas, como os Top 100 Finders em 2015). pesquisador em 2015 (ver).

Stefan Kanthak postou um comentário alemão, destacando algumas questões críticas. Aqui está um breve trecho:

• Para conveniência, os desenvolvedores entregam um instalador .exe (ao invés de um arquivo .msi). Este instalador precisa ser executado com privilégios administrativos para instalar o software. O instalador desempacota os arquivos necessários em um diretório TEMP (desprotegido). Problema: Se houver malware no sistema que atualmente roda apenas com os direitos de uma conta de usuário restrita, a armadilha é ativada.
• Este malware pode notar o processo de desempacotamento (há APIs do Windows que podem relatar isso e chamar uma ‘função de gancho’ do malware). Então é suficiente copiar um arquivo DLL com um determinado nome para a pasta TEMP (já que isso é desprotegido, isso é possível com direitos limitados de usuário).
• Durante o processo de instalação, o instalador tenta carregar a suposta DLL do Windows, mas acessa a DLL colocada pelo malware devido às características do Windows. E o malware imediatamente recebe direitos administrativos através da DLL.

Isso é conhecido há muito tempo como hijacking de ordem de busca de DLL, um risco potencial de segurança e deve ser absolutamente evitado. Stefan Kanthak postou alguns links e mais detalhes em seu comentário em alemão. Como conclusão: Desde que o projeto não resolvesse esses problemas, eu evitaria/teria cuidado ao usar tal software.

Addendum: Neste momento, tenho de recuar um pouco. Eu dei uma olhada no instalador (sob Windows 7). Observação interessante: O leitor alemão Martin Feuerstein apontou em um comentário, que o instalador .exe tem um interruptor para extrair os instaladores .msi – pode ser exibido com /? Então você pode descompactar o .msi e instalar a versão 32-/64-bit via .msi installer.

Há outra observação: Aparentemente o instalador .exe roda durante a descompactação apenas com direitos de usuário padrão, descompacta os arquivos .msi e chama o arquivo apropriado. O instalador .msi ativa o prompt do UAC devido às configurações dentro de seu manifesto e instala a ferramenta. Isto elimina o vector de ataque como descrito acima de acordo com o meu conhecimento actual (se o msi correcto chama o UAC pode ser verificado no prompt UAC). Se houver novas descobertas, eu as adicionarei.

Addendum 2: De acordo com Stefan Kanthak o instalador ClassicStartSetup_4_4_109.exe tem as seguintes dependências – podem ser obtidas com:

LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_109.exe

COMCTL32.dll
VERSION.dll
KERNEL32.dll
USER32.dll
ADVAPI32.dll
SHELL32.dll

E as DLLs acima dependem de GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll e
SHLWAPI.dll. Como o Windows Vista VERSION.dll não é uma “DLL conhecida” e qualquer arquivo com esse nome será carregado do diretório do aplicativo, se presente. O mesmo se aplica ao arquivo SECUR32.dll e RPCRT4.dll.

Note: Dentro das screenshots abaixo e dentro do comando sample, eu uso o antigo ClassicStartSetup_4_4_109.exe. Eu também realizo os mesmos testes com OpenShellSetup_4_4_126.exe (o mais recente build noturno) – o mesmo resultado. Também não há nenhuma assinatura digital disponível. Então eu deixei os antigos screenshots e comandos dentro do texto.

Stefan Kanthak me deixou usar algumas de suas DLLs de teste para executar ClassicStartSetup_4_4_109.exe em um ambiente de teste. Aqui está o resultado:

(Clique para ampliar)

Uma tentativa de exibir as opções resultou em um aviso, que um malware poderia ter manipulado os arquivos (caixa de diálogo na frente). Depois eu deixei o instalador .exe apenas extrair os instaladores .msi. Quando executei o instalador .msi de 64 bits, nenhum aviso foi emitido.

Mas os arquivos .msi incluídos no arquivo .exe do instalador não estão atualmente assinados digitalmente. O motivo: Eles são construções noturnas. Nesse ponto eu parei qualquer outra investigação. As compilações noturnas não são para sistemas de usuários finais. Vamos esperar, como a versão final dessa ferramenta se parece e se ela tem as mesmas vulnerabilidades descritas acima.