Como tornar os arquivos hackeados no repositório do Subversion editáveis novamente?

Question

Estou investigando alguns arquivos em um site que foram invadidos e o site está sob controle de versão em um repositório Subversion, mas ele não mostra os arquivos como sendo modificados. Como posso evitar que o SVN ignore os arquivos para que eu possa fazer o check-in de cópias limpas?

Estou limpando um site que foi hackeado (relativamente pequeno, alguns links de cassino foram adicionados ao cabeçalho de uma página) e o site é hospedado em uma cópia de trabalho de um repositório do SVN. (Sim, ele tem um arquivo .htaccess em funcionamento que impede o acesso às pastas .svn .) Curiosamente, o arquivo hackeado tem a data de modificação da última versão atualizada no repositório SVN, svn status mostra como não sendo modificado, svn log -v <hacked_file> não mostra commits após a última versão atualizada no repositório do SVN, svn diff <hacked_file> também não mostra diferença entre o arquivo e a última versão modificada no repo. Eu peguei alguns scripts para verificar logs & diffs entre cada versão e não há nada que modifique esse arquivo.

No entanto, notei que o nome do arquivo aparece em .svn/all-wcprops , da seguinte maneira:

K 25
svn:wc:ra_dav:version-url
V 48
/<repo>/!svn/ver/97/trunk/www.example.com/<hacked_file>
END
favicon.ico

Naturalmente, svn proplist -v <hacked_file> não produz nada e svn propget 'svn:wc:ra_dav:version-url' <hacked_file> retorna um erro dizendo que é "um wcprop, portanto não acessível aos clientes".

Eu não estou vendo nenhum objeto 'svn: ignore' e svn status --no-ignore não mostra o arquivo hackeado.

Fiz muita pesquisa e realmente não encontrei nenhuma informação no SVN 'wcprops' ou .svn/all-wcprops . É seguro excluir o arquivo all-wcprops ?

Quaisquer outras possibilidades / opções / conselhos que não sejam apagar a cópia de trabalho e verificar uma nova cópia (isso em um repositório muito grande, por isso é demorado e levaria muito tempo para revisar para ter certeza de que tudo está funcionando, especialmente porque não posso confiar que não há arquivos modificados que possam ser perdidos)? Isso é algo que provavelmente foi modificado no repositório principal do SVN?

    

Answer 1

Como outros apontaram, é melhor verificar uma nova cópia do repositório do SVN, uma vez que a cópia de trabalho é indigna de confiança e não é confiável. Então, fiz o seguinte:

• Verificamos uma nova cópia de trabalho
• Confirmado que o conteúdo do arquivo invadido estava correto conforme aparecia no repositório, sem as modificações maliciosas
• Confirmado que as modificações no arquivo invadido (e outras listadas em .svn/all-wcprops ) seriam modificadas por svn status quando editado
• Trocou as cópias de trabalho
• Ran diff -qrx .svn <hacked_working_copy>/ <new_working_copy>/ para determinar quais arquivos foram realmente alterados / adicionados na cópia de trabalho invadida, mas não são exibidos como
• Confirmado o conteúdo e copiado manualmente de todos os arquivos não confirmados, conforme necessário
• Arquivado & removeu a cópia de trabalho invadida por uma investigação / evidência adicional e a removeu

Naturalmente, outras ações & precauções estão sendo tomadas, mas a diff recursiva facilitou a identificação de arquivos questionáveis.