Neste post vou passar uma simples falha de segurança que ocorre quando estamos conectando em banco de dados remoto e não temos a conexão criptografada.
Irei utilizar o comando do linux tcpdump para escutar toda conexão de rede na minha máquina de banco de dados na porta 1521.
| tcpdump -As 1518 -i any port 1521 |
Fiz os teste em duas versões do banco de dados Oracle 11g e 18c. Podemos ver que a falha de segurança ocorre nas duas versões.
| [oracle@myhost]$ sqlplus system@bd_teste SQL*Plus: Release 11.2.0.4.0 Production on Mon Nov 23 15:03:01 2020 Copyright (c) 1982, 2013, Oracle. All rights reserved. Enter password: Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options SQL> create user user_teste identified by "minhasenha"; User created. |
Analisando a saída do tcpdump podemos ver em texto claro a nossa senha.
| 15:13:20.644358 IP localhost.21678 > localhost.ncube-lm: Flags [P.], seq 620:950, ack 363, win 1685, options [nop,nop,TS val 902579458 ecr 902547193], length 330 E..~.%@.@.bR........T....'#8.........r..... 5.E.5....J.........i......................^.!...............1................................................................................................................N-.............................................................1create user user_teste identified by "minhasenha".................................................................... 15:13:20.644383 IP localhost.ncube-lm > localhost.21678: Flags [.], ack 950, win 537, options [nop,nop,TS val 902579458 ecr 902579458], length 0 E..4}.@.@.............T......'$......(..... 5.E.5.E................. 15:13:20.652971 IP localhost.ncube-lm > localhost.21678: Flags [P.], seq 363:544, ack 950, win 537, options [nop,nop,TS val 902579466 ecr 902579458], length 181 E...}.@.@..V..........T......'$............ 5.E 5.E..............b.....................................................3.................................6................#.............................................................................. 15:13:20.653063 IP localhost.21678 > localhost.ncube-lm: Flags [.], ack 544, win 1713, options [nop,nop,TS val 902579466 ecr 902579466], length 0 E..4.&@.@.c.........T....'$..........(..... 5.E |
Versão 18g
Na versão 18, vou alterar a senha do usuário para ver se conseguimos ver a senha com o tcpdump.
| [oracle@myhost]/home/oracle$ sqlplus system@bd_teste SQL*Plus: Release 18.0.0.0.0 - Production on Seg Nov 23 15:23:57 2020 Version 18.3.0.0.0 Copyright (c) 1982, 2018, Oracle. All rights reserved. Conectado a: Oracle Database 18c Enterprise Edition Release 18.0.0.0.0 - Production Version 18.3.0.0.0 SQL> alter user user_teste identified by "mudeiasenha"; Usuário alterado. |
Agora vamos ao tcpdump prcurar a senha:
| 15:25:26.121773 IP localhost.10915 > localhost.ncube-lm: Flags [P.], seq 1427125228:1427125639, ack 2604883754, win 1594, options [nop,nop,TS val 1569612851 ecr 1569593608], length 411 E....M@.@.2.........*...U.3..C_*...:....... ].d3]..............i......................^.!...............2.................................................................................................................#.............................................................................................................................................2 alter user user_teste identified by "mudeiasenha".................................................................... 15:25:26.121791 IP localhost.ncube-lm > localhost.10915: Flags [.], ack 411, win 1577, options [nop,nop,TS val 1569612851 ecr 1569612851], length 0 E..4]O@.@..r..........*..C_*U.5....).(..... ].d3].d3................ |
Passando a senha de forma segura
Certo, vimos que criando dessa forma estamos fazendo da maneira insegura. Então como resolver isso? Simples, basta usando o comando password. Usando ele, a senha é enviada de forma segura, criptografada.
| SQL> password user_teste Changing password for user_teste New password: Retype new password: Password changed |
Olhando o tcpdump, podemos ver que não temos mais a senha em texto claro ela está criptografada.
| 15:34:16.832537 IP localhost.22189 > localhost.ncube-lm: Flags [P.], seq 3439:3915, ack 4177, win 1547, options [nop,nop,TS val 903835646 ecr 903788127], length 476 E.....@.@.7L........V...q/.5..7f........... 5.o.5.._...........k. ............s......... ....................................... user_teste.....AUTH_SESSKEY.............AUTH_NEWPASSWORD@...@553465285F6B246026CB86B4FC2BEBC4A5BBE78BE265EC12A0A0146CAE0FFEB4.........AUTH_TERMINAL.....pts/1.........AUTH_PROGRAM_NM(...(sqlplus@myhost (TNS V1-V3).........AUTH_MACHINE.....tjoth03.tj.ce.gov.br.........AUTH_PID.....2536.........AUTH_SID.....oracle.........AUTH_ALTER_SESSION%...%ALTER SESSION SET TIME_ZONE='-03:00'..................... 15:34:16.834641 IP localhost.ncube-lm > localhost.22189: Flags [P.], seq 4177:4326, ack 3915, win 464, options [nop,nop,TS val 903835648 ecr 903835646], length 149 E....f@.@.............V...7fq/............. 5.p.5.o......................................................................6................#.............................................................................. 15:34:16.834713 IP localhost.22189 > localhost.ncube-lm: Flags [.], ack 4326, win 1575, options [nop,nop,TS val 903835648 ecr 903835648], length 0 E..4..@.@.9'........V...q/....7....'.(..... 5.p.5.p................. |
Em resumo
Vimos a forma "errada" ou não segura de se criar ou alterar um usuário, então agora vou mostrar a forma segura. Lembrando que a senha em texto claro só pode ser vista se estiver usando uma conexão remota e sem criptografia.
Se for alterar a senha de um usuário
NUNCA use: alter user <usuario> identified by suasenha; USE: password <usuario> |
Se estiver criando um novo usuário:
NUNCA use: create user <usuario> identified by suasenha; USE: 18c/19c - create user <usuario> password <senha> menor ou igual 12.2 - create user <usuario> identified externally; password <usuario> |
Comentários