Bancos de dados modernos armazenam todos os tipos de dados. Do trivial ao altamente sensível. Os restaurantes que frequentamos, nossas localizações no mapa, nossas credenciais de identidade (por exemplo, números de segurança social, endereços, registros médicos, informações bancárias etc.) e tudo mais provavelmente está armazenado em um banco de dados em algum lugar. Não é à toa que os dados são tão valiosos.
As tecnologias de banco de dados avançam a um ritmo vertiginoso. Inovação, progressão, integridade e aprimoramentos estão na vanguarda como resultado direto do trabalho de engenheiros inteligentes e dedicados, desenvolvedores e comunidades robustas que apoiam esses fornecedores.
No entanto, há um outro lado da moeda. Isso, infelizmente, coexiste neste mundo orientado por dados na forma de malware, vírus e explorações em uma escala massiva e alta de todos os tempos.
Os dados também são valiosos para as partes desse lado da operação. Mas por motivos diferentes. Qualquer um deles pode ser, mas não se limita a poder, chantagem, ganho e acesso financeiro, controle, diversão, pegadinhas, malícia, roubo, vingança... Você entendeu. A lista não tem fim.
Infelizmente, temos que operar com uma mentalidade de segurança. Sem essa mentalidade, deixamos nossos sistemas vulneráveis a esses tipos de ataques. O PostgreSQL é tão suscetível a comprometimento, uso indevido, roubo, acesso/controle não autorizado quanto outras formas de software.
Então, quais medidas podemos tomar para mitigar o número de riscos para nossas instalações do PostgreSQL?
Eu sinto fortemente que promover a conscientização sobre quais ameaças conhecidas estão por aí é um bom ponto de partida para começar. Conhecimento é poder e devemos usar tudo o que temos à nossa disposição. Além disso, como podemos policiar isso que nem temos conhecimento para aumentar a segurança nessas instâncias do PostgreSQL e proteger os dados que residem nelas?
Recentemente, pesquisei 'preocupações' e 'ameaças' de segurança conhecidas, visando o ambiente PostgreSQL. Minha pesquisa abrangeu relatórios, artigos e postagens de blog recentes no primeiro trimestre de 2018. Além desse período específico, explorei preocupações conhecidas de longa data que ainda são ameaças viáveis hoje (ou seja, injeção de SQL), embora não polidas ou anunciado como 'recentemente descoberto '.
Uma oportunidade fotográfica
Um mergulho profundo nos ataques de banco de dados [Parte III]:por que a foto de Scarlett Johansson fez meu banco de dados Postgres começar a minerar Monero
A notícia desse ataque de malware astuto retornou o maior número de 'acertos' dos meus resultados de pesquisa objetivos.
Visitaremos uma das várias ótimas postagens do blog e um resumo de seu conteúdo. Também incluí postagens de blog adicionais no final desta seção, portanto, visite-as também detalhando essa intrusão.
Observações
Informações da Imperva, relata que seu banco de dados honeypot (StickyDB) descobriu um ataque de malware em um de seus servidores PostgreSQL. A rede honeypot, como a Imperva nomeia o sistema, é projetada para induzir os invasores a atacar o banco de dados para que eles (Imperva) possam aprender sobre isso e se tornarem mais seguros. Neste caso em particular, a carga útil é um malware que criptomina Monero, embutido em uma foto de Scarlett Johansson.
A carga útil é despejada no disco em tempo de execução com a função lo_export. Mas, aparentemente, isso acontece porque lo_export é uma entrada no pg_proc versus uma chamada normalmente direta (lo_export).
Detalhes interessantes diretamente da postagem do blog aqui para extrema clareza (consulte o artigo citado),
Agora, o invasor pode executar comandos do sistema local usando uma função simples – fun6440002537. Esta função SQL é um wrapper para chamar uma função da linguagem C, “sys_eval”, uma pequena função exportada em “tmp406001440” (um binário baseado em sqlmapproject), que basicamente atua como proxy para invocar comandos shell do cliente SQL.
Então, quais serão os próximos passos do ataque? Algum reconhecimento. Então começou obtendo os detalhes da GPU executando lshw -c video e continuou a cat /proc/cpuinfo para obter os detalhes da CPU (Figuras 3-4). Embora isso pareça estranho no começo, faz todo o sentido quando seu objetivo final é minerar mais de sua criptomoeda favorita, certo?
Com uma combinação de acesso ao banco de dados e a capacidade de executar código remotamente, tudo enquanto 'voando sob o radar ' de soluções de monitoramento, o invasor faz o download da carga útil por meio de uma foto de Scarlett Johansson.
(Observação:a foto já foi removida de seu local hospedado. Consulte o artigo de link para a menção.)
De acordo com o relatório, a carga útil está em formato binário. Esse código binário foi anexado à foto para passar por uma foto real durante o upload, permitindo uma imagem visível.
Veja a Figura 6 do post para o SQL responsável por utilizar wget, dd e executar chmod para permissões no arquivo baixado. Esse arquivo baixado cria outro executável que é responsável por realmente minerar o Monero. Claro, limpeza e limpeza são necessárias depois de todo esse trabalho nefasto.
A Figura 7 descreve o SQL em execução.
A Imperva recomenda monitorar esta lista de possíveis áreas de violação na seção de encerramento:
- Cuidado com chamadas diretas do PostgreSQL para lo_export ou chamadas indiretas por meio de entradas no pg_proc.
- Cuidado com as funções do PostgreSQL que chamam binários da linguagem C.
- Use um firewall para bloquear o tráfego de rede de saída do seu banco de dados para a Internet.
- Certifique-se de que seu banco de dados não tenha um endereço IP público. Se for, restrinja o acesso apenas aos hosts que interagem com ele (servidor de aplicativos ou clientes pertencentes a DBAs).
A Imperva também realizou vários testes de antivírus juntamente com detalhes de como os invasores podem localizar servidores PostgreSQL vulneráveis. Embora eu não os tenha incluído aqui por brevidade, consulte o artigo para obter detalhes completos de suas descobertas.
Leitura recomendada
- O Imperva tem 2 artigos anteriores que acompanham a Parte 3 (aquele discutido aqui). Embora não tenham como alvo o PostgreSQL fortemente como o que acabamos de encobrir, são leituras altamente informativas:
- Parte 1
- Parte 2
- O ataque de malware PostgreSQL de Scarlett Johansson
- Hackers visam bancos de dados PostgreSQL com Coinminer oculto na imagem de Scarlett Johannsson
- Um tópico do Hacker News sobre a exploração.
Detalhes, relatório e vulnerabilidades do CVE
Visitei este site, que publica as ameaças de segurança mais recentes por fornecedor e descobri 4 vulnerabilidades no primeiro trimestre de 2018. A página de informações de segurança do PostgreSQL também as lista, portanto, sinta-se à vontade para consultar esse recurso.
Embora a maioria deles tenha sido abordada, achei importante incluí-los neste post para conscientizar os leitores que podem não conhecê-los. Sinto que podemos aprender com todos eles. Especialmente nas diferentes formas de vulnerabilidades descobertas.
Eles estão listados abaixo na ordem de data de publicação:
Eu. CVE-2018-1052 data de publicação 2018-02-09 :Data de atualização 10/03/2018
Visão geral:
A vulnerabilidade de divulgação de memória no particionamento de tabelas foi encontrada no PostgreSQL 10.x antes de 10.2, permitindo que um invasor autenticado lesse bytes arbitrários da memória do servidor por meio de uma inserção específica em uma tabela particionada.
Esta vulnerabilidade foi corrigida com o lançamento do PostgreSQL 10.2 confirmado aqui. A versão 9.x mais antiga também corrigida também é mencionada, então visite esse link para verificar sua versão específica.
II. CVE-2018-1053 data de publicação 2018-02-09:Data de atualização 15/03/2018
Visão geral:
No PostgreSQL 9.3.x antes de 9.3.21, 9.4.x antes de 9.4.16, 9.5.x antes de 9.5.11, 9.6.x antes de 9.6.7 e 10.x antes de 10.2, pg_upgrade cria arquivo no diretório de trabalho atual contendo a saída de `pg_dumpall -g` sob umask que estava em vigor quando o usuário invocou pg_upgrade, e não sob 0077 que normalmente é usado para outros arquivos temporários. Isso pode permitir que um invasor autenticado leia ou modifique um arquivo, que pode conter senhas de banco de dados criptografadas ou não criptografadas. O ataque é inviável se um modo de diretório bloquear o invasor que pesquisa o diretório de trabalho atual ou se o umask predominante bloquear a abertura do arquivo pelo invasor.
Assim como no CVE-2018-1052 anterior, o PostgreSQL 10.2 corrigiu esta parte da vulnerabilidade:
Certifique-se de que todos os arquivos temporários feitos com "pg_upgrade" não sejam legíveis pelo mundo
Muitas versões mais antigas do PostgreSQL são afetadas por essa vulnerabilidade. Certifique-se e visite o link fornecido para todas as versões listadas.
III. CVE-2017-14798 data de publicação 2018-03-01:Data de atualização 26/03/2018
Visão geral:
Uma condição de corrida no script de inicialização do PostgreSQL pode ser usada por invasores capazes de acessar a conta do PostgreSQL para escalar seus privilégios para root.
Embora eu não tenha encontrado em nenhum lugar na página de links que o PostgreSQL versão 10 foi mencionado, muitas versões mais antigas são, então visite esse link se estiver executando versões mais antigas.
Os usuários do Suse Linux Enterprise Server podem estar interessados em 2 artigos vinculados aqui e aqui onde essa vulnerabilidade foi corrigida para o script de inicialização da versão 9.4.
IV. CVE-2018-1058 data de publicação 2018-03-02 :Data de atualização 22/03/2018
Visão geral:
Uma falha foi encontrada na forma como o PostgreSQL permitia que um usuário modificasse o comportamento de uma consulta para outros usuários. Um invasor com uma conta de usuário pode usar essa falha para executar código com as permissões de superusuário no banco de dados. As versões 9.3 a 10 são afetadas.
Esta versão de atualização menciona essa vulnerabilidade com um documento vinculado interessante que todos os usuários devem visitar.
O artigo fornece um guia fantástico da comunidade intitulado A Guide to CVE-2018-1058:Protect Your Search Path, que possui uma quantidade incrível de informações sobre vulnerabilidade, riscos e práticas recomendadas para combatê-lo.
Farei o meu melhor para resumir, mas visite o guia para seu próprio benefício, compreensão e compreensão.
Visão geral:
Com o advento do PostgreSQL versão 7.3, os esquemas foram introduzidos no ecossistema. Esse aprimoramento permite que os usuários criem objetos em namespaces separados. Por padrão, quando um usuário cria um banco de dados, o PostgreSQL também cria um esquema público no qual todos os novos objetos são criados. Os usuários que podem se conectar a um banco de dados também podem criar objetos no esquema público desse banco de dados.
Esta seção diretamente do guia é muito importante (veja o artigo citado):
Os esquemas permitem que os usuários usem objetos de namespace, de modo que objetos com o mesmo nome possam existir em esquemas diferentes no mesmo banco de dados. Se houver objetos com o mesmo nome em esquemas diferentes e o par esquema/objeto específico não for especificado (ou seja, esquema.objeto), o PostgreSQL decide qual objeto usar com base na configuração search_path. A configuração search_path especifica a ordem em que os esquemas são pesquisados ao procurar um objeto. O valor padrão para search_path é $user,public onde $user se refere ao nome do usuário conectado (que pode ser determinado executando SELECT SESSION_USER;).
Outro ponto importante está aqui:
O problema descrito em CVE-2018-1058 gira em torno do esquema "público" padrão e como o PostgreSQL usa a configuração search_path. A capacidade de criar objetos com os mesmos nomes em esquemas diferentes, combinada com a forma como o PostgreSQL procura objetos em esquemas, apresenta uma oportunidade para um usuário modificar o comportamento de uma consulta para outros usuários.
Abaixo está uma lista de alto nível que o guia recomenda a aplicação dessas práticas conforme estipulado para reduzir o risco dessa vulnerabilidade:
- Não permitir que os usuários criem novos objetos no esquema público
- Defina o search_path padrão para usuários do banco de dados
- Defina o search_path padrão no arquivo de configuração do PostgreSQL (postgresql.conf)
Injeção de SQL
Qualquer 'tema de segurança ' A postagem ou artigo do blog SQL não pode se rotular como tal sem mencionar a injeção de SQL. Embora este método de ataque não seja de forma alguma imaginação 'o novo garoto no bloco ', deve ser incluído.
SQL Injection é sempre uma ameaça e talvez ainda mais no espaço de aplicações web. Qualquer banco de dados SQL - incluindo PostgreSQL - é potencialmente vulnerável a ele.
Embora eu não tenha uma base de conhecimento profunda em SQL Injection - também conhecida como SQLi - farei o meu melhor para fornecer um breve resumo, como isso pode afetar seu servidor PostgreSQL e, finalmente, como reduzir os riscos de ser vítima para isso.
Consulte os links fornecidos no final desta seção, todos contendo uma riqueza de informações, explicações e exemplos nas áreas que não consigo comunicar adequadamente.
Infelizmente, existem vários tipos de injeções de SQL e todos eles compartilham o objetivo comum de inserir SQL ofensivo em consultas para execução no banco de dados, talvez não originalmente planejadas nem projetadas pelo desenvolvedor.
A entrada de usuário não sanitizada, verificação de tipo mal projetada ou inexistente (validação AKA), juntamente com a entrada de usuário sem escape, tudo pode potencialmente deixar a porta aberta para possíveis invasores. Muitas APIs de programação web fornecem alguma proteção contra SQLi:por exemplo, ORM's (Object Relational Mapper), consultas parametrizadas, verificação de tipos, etc. esses desvios e mecanismos à sua disposição.
Aqui estão sugestões notáveis para reduzir o risco de injeção de SQL da Folha de dicas de prevenção de injeção de SQL do OWASP. Certifique-se de visitá-lo para obter um exemplo completo de uso na prática (consulte o artigo citado).
Defesas Primárias:
- Opção 1:uso de declarações preparadas (com consultas parametrizadas)
- Opção 2:uso de procedimentos armazenados
- Opção 3:validação de entrada da lista branca
- Opção 4:como escapar de todas as entradas fornecidas pelo usuário
Defesas Adicionais:
- Também:Aplicação de privilégios mínimos
- Também:Como executar a validação de entrada da lista branca como uma defesa secundária
Leitura recomendada:
Incluí artigos adicionais com muitas informações para estudo e conscientização adicionais:
- O que é injeção de SQL? Este velho, mas bom, pode prejudicar seus aplicativos da web
- Injeção de SQL (Wikipédia)
- Injeção de SQL (CLOUDFLARE)
- Injeção de SQL (w3schools.com)
- Folha de dicas de prevenção de injeção de SQL
- Teste para injeção de SQL
- Vulnerabilidades de injeção de SQL e como evitá-las
- Folha de dicas de injeção de SQL
Privilégios da função Postgres
Temos um ditado para algo como "Nós somos nosso pior inimigo ."
Podemos definitivamente aplicá-lo ao trabalho no ambiente PostgreSQL. Negligência, mal-entendido ou falta de diligência são oportunidades para ataques e uso não autorizado tanto quanto aqueles lançados propositalmente.
Talvez ainda mais, permitindo inadvertidamente acesso, rotas e canais mais fáceis para as partes infratoras.
Mencionarei uma área que sempre precisa de reavaliação ou reavaliação de tempos em tempos.
Privilégios de função injustificados ou estranhos.
- SUPERUSUÁRIO
- CREATROLE
- CREATEDB
- CONCESSÃO
Esta amálgama de privilégios definitivamente vale a pena dar uma olhada. SUPERUSER e CREATROLE são comandos extremamente poderosos e seriam mais bem servidos nas mãos de um DBA ao invés de um analista ou desenvolvedor você não acha?
A função realmente precisa do atributo CREATEDB? E o GRANT? Esse atributo tem o potencial de uso indevido em mãos erradas.
Pese bastante todas as opções antes de permitir funções desses atributos em seu ambiente.
Estratégias, práticas recomendadas e fortalecimento
Abaixo está uma lista de postagens de blog úteis, artigos, listas de verificação e guias que retornaram por um 'ano atrás' (no momento da redação deste artigo) de resultados de pesquisa. Eles não estão listados em nenhuma ordem de importância e cada um oferece sugestões dignas de nota.
- Maneiras simples de proteger seus servidores Postgres de um vetor de ataque improvável:uma imagem desonesta de Scarlett Johansson
- Ajudando a proteger seu banco de dados PostgreSQL
- Não seja cabeça-dura... Fortaleça seu banco de dados PostgreSQL para garantir a segurança
- Como proteger seu banco de dados PostgreSQL - 10 dicas
- Protegendo o PostgreSQL contra ataques externos
- Privilégios e segurança do PostgreSQL - Bloqueando o esquema público
Conclusão
Neste blog, analisamos os problemas de segurança que preocupam os administradores do PostgreSQL em todo o mundo:eles incluem injeção de SQL, que é o santo graal de todos os incidentes de segurança, erros nas abordagens básicas de tratamento dados de forma segura, como a falha ao restringir adequadamente as permissões em sua infraestrutura e também alguns problemas de segurança menos conhecidos que podem ser ignorados. Quando a segurança de nossos dados está em causa, é fundamental que aceitemos e apliquemos conselhos de partes confiáveis, como Imperva e similares, que nos fornecem maneiras de nos proteger tanto de ataques básicos quanto de 0 dias (explorações que ainda não foram conhecidos antes), porque consultoria respeitável significa um bom futuro para nossos bancos de dados e infraestrutura como um todo.
Lembre-se de que as medidas de segurança que precisamos tomar dependerão muito das vulnerabilidades que queremos combater, mas, em geral, conhecer todas as defesas necessárias para combater a injeção de SQL, usando corretamente privilégios, e sempre tentar reduzir nosso nível de risco referente a vulnerabilidades é crucial. Manter-se atualizado com o que está acontecendo no espaço de segurança do PostgreSQL também nos fará maravilhas:só podemos defender bem nossos servidores (e, consequentemente, nossos dados) se soubermos o que os invasores podem estar procurando.
Se você estiver procurando por mais práticas recomendadas para melhorar a segurança ou a postura de desempenho de suas instalações PostgreSQL, recorra ao ClusterControl:como a ferramenta é desenvolvida por especialistas em banco de dados de alto nível de todo o mundo, ela fará seus bancos de dados cantarem rapidamente. O produto também vem com uma avaliação gratuita de 30 dias, portanto, não deixe de experimentar todos os recursos que o ClusterControl pode oferecer para sua empresa e experimente hoje mesmo.
Para obter mais conteúdo sobre como você deve proteger suas instâncias de banco de dados PostgreSQL, consulte o blog da Variousnines para obter conselhos:aprender como automatizar auditorias de segurança para PostgreSQL certamente será um passo na direção certa. Certifique-se de nos seguir no Twitter, LinkedIn e assinar nosso feed RSS para mais atualizações, e nos vemos na próxima.
