O que a configuração do registro EnableLinkedConnections faz em um nível técnico?

13

Nota: o problema básico para mim é poder acessar um compartilhamento de rede que eu (usuário administrador do Win 7) configurou quando eu executo um programa elevado. Normalmente, o programa elevado não terá acesso aos meus compartilhamentos de rede não elevados.

De acordo com a Microsoft , a configuração do Registro EnableLinkedConnections permitirá que processos elevados acessem o compartilhamento de rede do usuário atualmente conectado (não -elevado) processo explorador.

Esta explicação faz algum sentido:

[...] When you’re a member of the Administrators group and you log in, your account is busted down to a non-privileged user by UAC. This running context is completely separate from the context you get when you right-click Command Prompt and launch as an administrator. As you’ll probably have noticed, network drives connected in one context are not visible in the other. [...]

Este tópico do fórum pergunta sobre as vulnerabilidades aberto por esta configuração. A resposta dada links para um artigo sobre a desabilitação de prompts UAC (ou assim eu entendo).

A questão agora é: o que a configuração do registro EnableLinkedConnections faz ou permite em um sistema Windows 7, uma vez que não estamos executando em um ambiente de domínio .

Edit: Uma coisa que eu estou especificamente interessado é se essa configuração afeta apenas as unidades de rede (visibilidade de) ou se tem outras implicações.

    
por Martin 20.09.2010 / 09:05

2 respostas

15

Não tendo acesso ao Windows, é difícil dizer qualquer coisa que não seja especulação. Esse aviso de lado, eis o que consegui ler lendo isto:

O UAC cria dois tokens de segurança no logon: o token elevado que contém as associações de grupo completas do usuário, e o token restrito que tem a participação do grupo" Administradores "removida. Cada token contém um ID exclusivo local exclusivo (LUID) que identifica a sessão de logon. São duas sessões de logon separadas e distintas.

A partir do Windows 2000 Server SP2, as unidades mapeadas (que são representadas como links simbólicos no namespace do gerenciador de objetos) são marcadas com o LUID do token que as criou (você pode encontrar algumas referências da Microsoft a esse comportamento neste artigo do KBase , e você pode aprender mais sobre a mecânica do recurso nesta postagem de blog ). A essência do recurso é que as unidades mapeadas criadas por uma sessão de logon não estão acessíveis para outra sessão de logon.

A configuração do valor EnableLinkedConnections aciona um comportamento no serviço LanmanWorkstation e no subsistema de segurança LSA (LSASS.EXE) para fazer com que o LSA copie unidades mapeadas por um dos tokens dos usuários no contexto do outro token. Isso permite que as unidades mapeadas com o token elevado fiquem visíveis para o token restrito e para o inverso. Não há qualquer peculiaridade do comportamento desse recurso com relação a um ambiente de domínio versus ambiente não-domínio. Se os usuários estiverem executando com contas de "Administrador" em um ambiente sem domínio, seus tokens restritos e tokens elevados terão, por padrão, mapeamentos de unidade independentes.

Em termos de vulnerabilidade, a documentação oficial da Microsoft parece estar faltando. Eu encontrei um comentário e uma resposta de um funcionário da Microsoft perguntando sobre as potenciais vulnerabilidades em uma conversa sobre o UAC a partir de 2007. Dado que o resposta vem de Jon Schwartz, que, na época, foi intitulado "UAC Architect", eu tendem a considerar sua resposta com credibilidade. Aqui está a essência de sua resposta para a seguinte pergunta: "... eu não encontrei nenhuma informação para descrever o que está realmente acontecendo tecnicamente ou se isso abrir algum tipo de brecha no UAC. Você pode comentar?"

Technically, it opens a small loophole since non-elevated malware can now "pre-seed" a drive letter + mapping into the elevated context -- that should be low-risk unless you end up with something that's specifically tailored to your environment.

Pessoalmente, não consigo pensar em uma maneira de "explorar" essa lacuna, na medida em que "semear" o token elevado com um mapeamento de unidade ainda exigiria que o usuário realmente elevasse e executasse algo malicioso dessa unidade "semeada" mapeamento. Eu não sou um pesquisador de segurança, no entanto, e talvez eu não esteja me aproximando disso com uma boa mentalidade para desenvolver explorações em potencial.

Desviei-me usando o valor EnableLinkedConnections em meus sites de clientes, continuando a tendência que começamos quando os clientes começaram a implantar o Windows NT 4.0 - fazendo com que os usuários fizessem logon com contas de usuário limitadas. Isso funciona bem para nós há anos e continua a funcionar bem no Windows 7.

    
por 29.09.2010 / 19:17
1

Simplificando, vincula suas credenciais de superusuário às suas credenciais normais. É claro que é mais complexo, mas basicamente, até mesmo a sua conta de "administrador" no Windows 7 não é um administrador, mas precisa fazer o equivalente a SUDO no Linux para executar uma infinidade de operações. Ao mapear uma unidade de rede, você precisa fazer isso, mas a unidade de rede só é mapeada para o superusuário, não para o usuário normal. Essa configuração do registro vincula as credenciais de superusuário às suas padrão para fins de unidades mapeadas. Dessa forma, ambos podem acessar a unidade mapeada em vez de apenas o superusuário.

    
por 20.09.2010 / 10:02