0
0
Recentemente decidi investigar o tipo de pedidos que receberia se tivesse aberto o SSH ao mundo. A seguir, os resultados dessa investigação.
Primeiro algum fundo.
O serviço SSH estava sendo executado em um Raspberry Pi e era o único dispositivo na conexão com a internet. A conexão à internet em si era um serviço padrão de banda larga residencial DSL. Em nenhum momento era um domínio apontando para o IP. Qualquer pedido da SSH foi especulativo.
Nesta fase, eu só estava interessado nas tentativas de login em vez do que estava tentando ser feito se uma conexão tivesse sido estabelecida. Registrei os pedidos por pouco mais de 7 dias.
Não vou entrar em como registrei os pedidos da SSH neste artigo, cobri isso no meu outro artigo “How I Set Up My SSH Honeypot“.
Os Pedidos
O honeypot SSH ficou online por pouco mais de 7 dias. Durante este tempo testemunhei um total de 129396 tentativas de registro. Inicialmente, isso pode soar excessivo, no entanto, deixe-me rapidamente quebrar isso.
O gráfico a seguir demonstra os 20 melhores hosts solicitados (o número de suportes é um ID único para cada host).
Como o gráfico demonstra, a grande maioria dos pedidos realmente veio de três anfitriões. Esses três responderam por 116209 das solicitações (cerca de 90% de todas as solicitações). Os pedidos destes foram muito sustentados, como pode ser mostrado no gráfico a seguir:
Excuse the period section, they are hourly slots. Each of the larger chunks is a prolonged attack from hosts 28, 41 and 136.
Desculpe a seção de períodos, são caça-níqueis por hora. Cada um dos pedaços maiores é um ataque prolongado dos anfitriões 28, 41 e 136.
O comportamento que esses três anfitriões demonstraram difere muito dos outros. A maioria dos anfitriões estava tentando credenciais muito direcionadas (mais sobre isso em um momento) esses três anfitriões estavam realizando um ataque de dicionário ao usuário raiz. A seguir, uma lista dos 20 melhores usuários que foram tentados.
root - 127111
admin - 188
0 - 79
pi - 73
test - 52
user - 44
support - 33
odroid - 28
ftpuser - 26
postgres - 25
ubnt - 24
guest - 23
ubuntu - 18
Administrator - 16
ftp - 14
oracle - 14
vagrant - 14
webmaster - 14
administrator - 13
dietpi - 13
A China, não só teve a maioria dos pedidos por anfitrião, mas também superou o número total de anfitriões vindos do país:
Agora, sobre as senhas que foram tentadas. Isso é muito mais uniformemente espalhado, como você pode esperar, como os anfitriões chineses estavam realizando um ataque de dicionário em raiz, eles raramente duplicaram senhas. A seguir está a lista das 20 principais senhas:
admin - 102
0 - 83
123456 - 67
password - 53
1234 - 41
raspberry - 39
root - 37
ubnt - 35
administrator - 30
welc0me - 29
guest - 26
openelec - 26
test - 25
pi - 23
alpine - 21
default - 21
12345 - 19
postgres - 19
alex - 16
ftpuser - 16
A segunda senha mais solicitada foi 0 (zero), porém acredito que isso seja um erro na parte dos atacantes. A maioria veio do mesmo host junto com o nome de usuário 0 (zero). Não acredito que seja um problema de registro, mas sim um problema na parte dos atacantes, não enviando a carga correta. Se acoplarmos esta lista junto com as combinações exclusivas de nome de usuário/senha, ele pinta uma imagem interessante:
0 - 0 - 79
admin - admin - 72
root - root - 32
root - welc0me - 29
root - openelec - 26
pi - raspberry - 24
pi - pi - 20
root - None - 20
ubnt - ubnt - 20
admin - password - 19
guest - guest - 19
test - test - 18
root - 1234 - 16
root - 123456 - 16
root - admin - 16
root - password - 16
root - libreelec - 15
O que eu acho particularmente interessante são os tipos de dispositivos que estão sendo sondados para, por exemplo, 44 tentativas no Raspberry Pi’s (através de 2 conjuntos de credenciais no top 20, mais outwith). Só posso assumir que estes se tornaram alvos populares devido à facilidade de desenvolvimento sobre eles (uma nota lateral, o honeypot SSH foi hospedado em um Raspberry Pi). Outro alvo são os sistemas de home theater (libreelec e openelec). Esses tipos de aplicações não devem exigir gerenciamento remoto, portanto, o fato de que eles estão mostrando em tais listas sugere que eles estão regularmente em equipamentos configurados por miss permitindo portas através do roteador.
Minha intenção original era identificar os tipos de dispositivos para os quais as credenciais tentadas são destinadas, no entanto, uma vez que os ataques entraram a todo vapor, isso se tornou uma tarefa impossível.
A seguir, alguns dos pedidos mais incomuns:
Username: root
Password: toor
Por que: Este é o nome de usuário padrão para Kali Linux, uma distribuição geralmente usada para potes de mel e hacking etc.
Username: pi
Password: raspberryraspberry993311
Por que: Claramente apontado para um Raspberry Pi, mas uma senha muito estranha. O Google tem 365 resultados ao procurá-lo, predominantemente outras pessoas que executaram potes de mel, bem como dicionários destinados a ataques como este. Ah, claro, que senha tem a hashtag obrigatória no Twitter.
Username: root
Password: %username%1234567890-=
Por que: Havia uma série de senhas que tinham um padrão semelhante (começando com %nome de usuário%). Eu sugeriria que este era um script configurado miss realizando o ataque. Suspeito que %o nome de usuário% era um espaço reservado em um modelo.
Username: root
Password: peng@163.com]shao*peng@163.com
Por que: Mais uma vez isso parece um modelo que deu errado, no entanto, eu me pergunto se havia um usuário de admin chamado peng nos servidores do 163.com, ou peng simplesmente é um usuário do serviço?
Username: root
Password: 19790715
Por que: Houve um número muito grande de solicitações que seguiram esse mesmo formato. A senha começaria sempre entre 1971 e 1981. Ao investigar, parece que são datas. Todos se encaixam no formato YYYYMMDD sem exceção. Nem todas as datas foram cobertas (mas os anos foram) e cada combinação foi tentada 6 vezes. Havia evidências de anos fora com este intervalo, mas não datas completas. Pessoas entre 38 e 48 anos têm mais chances de usar sua data de nascimento como senha? Suspeito que não, mas uma observação interessante.
Username: root
Password: masterFindfileCopypathBlasting_dictionary/renkoutop.txt
Por que: Você esperaria que este fosse alguém que cometeu um erro em seu script, passando a URL do arquivo em vez de iterar o conteúdo. No entanto, você estaria errado. Uma rápida pesquisa no Google mostra resultados semelhantes em outras listas de senhas encontradas. É possível que tenha sido um erro no início, mas as pessoas que fazem listas de senhas a encontraram em uma raspagem de logins tentados?
Conclusão
Deixar serviços como o SSH aberto pode resultar em um grande número de solicitações desse tipo. Independentemente de você ser Joe bloggs em uma conexão doméstica ou Microsoft executando um servidor Office 365. Certifique-se de bloquear quaisquer portas que você não precisar. Suspeito que qualquer outro porto de serviço veria tráfego semelhante.
Gostaria de salientar que, embora uma proporção muito grande dos pedidos veio da China (e especificamente de um pequeno número de anfitriões), isso não significa que foi um miscreant chinês tentando invadir o dispositivo. Embora pudesse ter sido, é tão provável que o dispositivo seja um servidor ou dispositivo que foi comprometido. Claramente, esses agressores têm um desrespeito pelo tráfego sendo notado, caso contrário, os pedidos teriam sido estrangulados.
Se você está interessado em dar uma olhada nas solicitações você mesmo, eu compilei um arquivo CSV com cada solicitação individual sobre Github Gist. No entanto, ofusquei os IP de conexão e substituí por um ID único (identificado como host_id). Se importar em um banco de dados, a seguinte estrutura de tabela será suficiente:
CREATE TABLE honeypot (
id int(11) NOT NULL AUTO_INCREMENT,
username varchar(250) DEFAULT NULL,
password varchar(250) DEFAULT NULL,
`when` datetime DEFAULT NULL,
country varchar(250) DEFAULT NULL,
host_id int(11) DEFAULT NULL,
PRIMARY KEY (id)
);
Eu também escrevi um artigo intitulado “How I Set Up My SSH HoneyPot” que descreve os passos dados e alguns dos takeaways.
FONTE: MEDIUM