Fernando, boa noite Essa função é criada quando o invasor tem acesso ao usuário postgres. A partir dai, o invasor pode usar o comando copy para ler arquivos do Linux para o banco de dados, criar funções que criam arquivos e por ai vai. Te passei o link do site, pois suspeitava desse problema.
Confira esse vídeo demonstrando como realizar o hack no PostgreSQL para você entender o que o invasor pode ter feito: https://www.youtube.com/watch?v=n9i5kjPDg2M Sempre é bom entender quais a técnicas que estão sendo utilizadas para invasão e assim buscar formas efetivas de melhorar a proteção do SGBD PostgreSQL, ainda mais quando o banco de dados está disponível na web. Como falei anteriormente na empresa onde encontrei o exploit começaram a reclamar de lentidão. Por incrível que pareça, constatei que o pg_hba.conf estava aberto para todos os usuários em todos os bancos e com o método de conexão trust. Não preciso nem explicar o resto. Em 22 de dezembro de 2015 08:42, Flavio Henrique Araque Gurgel < [email protected]> escreveu: > > Verificando o que os colegas comentaram, identifiquei o possível >> problema. >> >> http://unix.stackexchange.com/a/248010 >> >> Havia a função exec111 no database postgres, essa função tentava >> executar um arquivo no /tmp, porem esse arquivo não existe lá. >> >> Alterando todas senhas. >> > > Eu acrescentaria os gerúndios abaixo: > Congelando a máquina fora da rede, fazendo dump completo, instalando novo > servidor limpo para os dados, com mais proteção e restaurando o dump nele > pra colocar o serviço em produção em seguida. > > E se tiver grana pra tal, fazer uma análise forense pra entender de onde > pode ter vindo. > > []s > Flavio Gurgel > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
