Lista de portas perigosas TCP/UDP

A lista abaixo mostra as portas padrões porém contraindicadas para uso. Muitos desses programas podem ser configurados para operar em outras portas. Uma lista muito mais completa pode ser encontrada no site da Simovits Consulting em http://www.simovits.com/nyheter9902.html ou na página de Raf Vantongerloo em http://home.tiscalinet.be/bchicken/trojans/trojanpo.htm.

31/tcp Agent 31, Hackers Paradise, Masters Paradise
1170/tcp Psyber Stream
1234/tcp Ultors Trojan
1243/tcp SubSeven server (default for V1.0-2.0)
1981/tcp ShockRave
2001/tcp Trojan Cow
2023/tcp Ripper Pro
2140/udp Deep Throat, Invasor
2989/tcp Rat backdoor
3024/tcp WinCrash
3150/tcp Deep Throat, Invasor
3700/tcp Portal of Doom
4950/tcp ICQ Trojan
6346/tcp Gnutella
6400/tcp The Thing
6667/tcp Trinity intruder-to-master and master-to-daemon
SubSeven server (default for V2.1 Icqfix and beyond)
6670/tcp Deep Throat
12345/tcp NetBus 1.x, GabanBus, Pie Bill Gates, X-Bill
12346/tcp NetBus 1.x
16660/tcp Stacheldraht intruder-to-master
18753/udp Shaft master-to-daemon
20034/tcp NetBus 2 Pro
20432/tcp Shaft intruder-to-master
20433/udp Shaft daemon-to-master
27374/tcp SubSeven server (default for V2.1-Defcon)
27444/udp Trinoo master-to-daemon
27665/tcp Trinoo intruder-to-master
30100/tcp NetSphere
31335/udp Trinoo daemon-to-master
31337/tcp Back Orifice, Baron Night, Bo Facil
33270/tcp Trinity master-to-daemon
33567/tcp Backdoor rootshell via inetd (from Lion worm)
33568/tcp Trojaned version of SSH (from Lion worm)
40421/tcp Masters Paradise Trojan horse
60008/tcp Backdoor rootshel via inetd (from Lion worm)
65000/tcp Stacheldraht master-to-daemon

 

Fonte: Gary Kessler – Bad Ports

10 coisas que os auditores devem saber

A ISACA postou em Fevereiro de 2017, um Infográfico sobre Auditoria de Segurança Cibernética, apontando 10 coisas que os auditores devem saber, confiram:

1 – Guias/Frameworks de levantamento existentes

Os auditores devem considerar o mapeamento do NIST “Framework for Improving Critical Infrastructure Cybersecurity” para os controles ISO27001: 2013 e COBIT 5 para reduzir o escopo da auditoria, portanto, tornando a auditoria mais gerenciável.

2 – Considerar a próxima legislação

Os auditores devem estudar como as leis atuais, como o GDPR e o PCI-DSS, poderiam ser incorporadas nos programas de segurança cibernética. Além disso, os auditores precisam entender o ambiente regulatório global e as diferenças que podem existir entre regiões geográficas (por exemplo, GDPR – PCI-DSS em toda a UE / EUA / China / Rússia / Índia / Japão, etc.).

3 – Todos os riscos são subjetivos

Para se qualificar como um “risco”, uma ameaça deve ser associada a uma vulnerabilidade que, se explorada, pode afetar negativamente um recurso de informação. Se não, não é uma ameaça. Muitos auditores se preocupam com ameaças e vulnerabilidades que não representam risco real para um bem, priorizando a conformidade com o risco e desperdiçando tempo precioso e recursos.

4 – Os usuários são (e sempre serão) o grande risco de segurança

Nosso setor é liderado por fornecedores e continuamos buscando segurança através de produtos (firewalls, IDS / IPS, criptografia, anti-malware, DLP, etc.). Investimos em produtos antes de pessoas, enquanto resultados reais e mensuráveis podem ser alcançados investindo em conscientização de segurança da informação. Para contribuir com resultados tangíveis, os auditores devem priorizar as pessoas sobre o produto. A educação de segurança cibernética é a bala de prata.

5 – Controles ainda são importantes em segurança da informação básica

Como parte da segurança geral (incluindo a segurança cibernética), esses controles fornecem uma base de referência válida de controles de segurança que ajudam a reforçar a segurança em complexidade (por exemplo, controles de acesso físicos e lógicos, aplicação de “princípio de privilégio mínimo”).

6 – Precisa de uma política de respostas a incidentes cibernéticos e um plano que é totalmente testável

Os auditores precisam avaliar se um plano adequado de gerenciamento de crises e comunicação está em vigor e claramente comunicado e testado, conforme apropriado. Isso deve permitir uma continuidade de negócios suficiente em caso de violação de segurança cibernética. O gerenciamento de crises deve incluir resposta a incidentes e forense, quando justificado. O monitoramento e a detecção proativa (com ferramentas automatizadas) devem estar em posição.

7 – A estratégia de segurança cibernética precisa de agilidade – o cenário está em mutação

A estratégia precisa ser adaptável e escalável para lidar com novos métodos de ataque, como ransomware / BYOD risk / cloud-third party risk / social media etc. Os auditores precisam estar conscientes de que esta é uma área que está mudando constantemente – não pode assumir que o que atualmente mantém o seu ambiente de TI seguro, continuará a ser seguro sempre.

8 – A conscientização em segurança cibernética depende de uma correta formação

Os funcionários precisam de educação e treinamento suficientes e oportunos para ajudar a combater a ameaça de segurança cibernética que muda constantemente. A segurança precisa ser entrelaçada no tecido em uma organização. Um dos exercícios da caixa de seleção não é suficiente.

Por exemplo:

  • Os funcionários realmente entendem as implicações de uma violação da segurança cibernética?
  • Alguma ideia foi dada a ameaças de insider de uma perspectiva de segurança cibernética?
  • Existe orientação clara sobre o uso de mídias sociais / soluções de Shadow IT / BYOD / como responder a um ataque de phishing ou ransomware?

Os funcionários são recompensados / elogiados por promoverem a segurança em uma organização – eles são incentivados?

9 – Tudo está conectado a tudo

A principal função e objetivo de qualquer dispositivo cibernético é a conectividade. Os dispositivos são como escaladores amarrados juntos no lado de uma montanha – se cair pode trazer qualquer coisa conectada a ele. O Target hack (através de uma conexão de fornecedor de HVAC) demonstra claramente a necessidade de uma visão holística de segurança cibernética. Com a chegada do IoT, é imperativo que os auditores compreendam e abordem a imagem maior.

10 – Consciente das técnicas de roubo de credenciais

Os auditores devem ter conhecimento de técnicas de ataque de roubo de credenciais (por exemplo, pass-the-hash, registro de chaves, passagem de bilhetes, representação de token e ataques de homem ao meio – MITM). Normalmente, o ataque Pass-the-Hash (PtH) e outros roubos de credenciais e reutilização de tipos de ataque usam um processo iterativo de dois estágios. Primeiro, um invasor captura as credenciais de logon da conta em um computador e, em seguida, usa essas credenciais capturadas para se autenticar em outros computadores pela rede.

Fonte e pdf original em inglês: ISACA

Petya.2017 é um wiper e não um ransomware

Ransomware-as-a-service logo será renomeado como Lure-as-a-Service

TL; DR: O ransomware foi uma atração para a mídia, esta variante de Petya é um wiper dissimulado.
Update1: poucas horas depois, a pesquisa da Kaspersky levou a uma conclusão semelhante.
Update2: adicionou mais informações sobre o comando wiper e as capturas de tela comparadas das duas chaves que confirmam visualmente a descoberta da Kaspersky e por que a rotina de cópia MBR não faz sentido.

Qual a diferença entre um wiper e um ransomware?

O objetivo de um wiper é destruir e danificar. O objetivo de um ransomware é ganhar dinheiro. Intenção diferente. Motivo diferente. Diferente narrativa. Um ransomware tem a capacidade de restaurar sua modificação, como (restaurando o MBR como no Petya de 2016, ou arquivos de descodificação se a vítima pagar) – um wiper simplesmente destruiria e excluía as possibilidades de restauração.
Ontem, fornecemos uma análise preliminar onde demonstramos que a versão 27 de junho de 2017 da Petya alavancada no SMB explora ETERNALBLUE e ETERNALROMANCE.
Hoje, passamos mais tempo para entender como os arquivos podem ser recuperados e como o MBR e MFT real estavam sendo codificados.

O setor Sloppy bloqueia modificações

Felizmente, há múltiplas análises existentes excelentes a partir de 2016 Petya que foram publicadas no ano passado em vários idiomas, como francês ou inglês [1, 2]. Hoje, a Microsoft publicou uma análise muito descritiva do Petya de 2017, mas por alguns motivos perdeu a parte abaixo.

Depois de comparar a implementação, percebemos que a implementação atual que infectou massivamente múltiplas entidades na Ucrânia foi, de fato, um wiper que acabou de destruir os 24 primeiros blocos do setor do disco enquanto se replicava. Alguns observaram que este era principalmente um Slack Space, pois apenas o primeiro setor é relevante para a maioria das máquinas – exceto poucas exceções. Observo principalmente que, uma vez que isso pode ser usado em alguns cenários, é por isso que considero isso uma sobreposição desleixada.

O primeiro bloco do setor está sendo codificado de forma reversível por XORed com a chave 0x7 e salvo mais tarde no 34º bloco. Mas, uma vez que o substitui por um novo carregador de inicialização (41f75e5f527a3307b246cadf344d2e07f50508cf75c9c2ef8dc3bae763d18ccf) de 0x22B1 bytes basicamente define v19 para 0x19 (25).

16.0: kd:x86> ? 0x22B1 - (0x22B1 & 0x1FF) + 0x1024
Evaluate expression: 12836 = 00003224
16.0: kd:x86> ? 0x00003224 >> 9
Evaluate expression: 25 = 00000019

Isso significaria que 24 blocos do setor após o primeiro bloco do setor estão sendo substituídos propositadamente, eles não são lidos ou salvos em qualquer lugar. Enquanto a versão original do Petya de 2016 lê corretamente cada bloco de setor e os codifica reversivelmente.

2016 O Petya modifica o disco de uma forma que realmente pode reverter suas mudanças. Considerando que, 2017, Petya faz danos permanentes e irreversíveis ao disco.

À esquerda, podemos ver que a versão atual do Petya claramente foi reescrita para ser um wiper e não um ransomware real.

Esquerda (2017 Petya) com o código do wiper – Direita (2016 Petya) que lê e codifica blocos de setor.

Isso significa que a seção MBR do disco é propositalmente escrita pelo novo gerenciador de inicialização 41f75e5f527a3307b246cadf344d2e07f50508cf75c9c2ef8dc3bae763d18ccf.

Não há mais endereço de e-mail para pagamento

Além disso, o endereço de e-mail de pagamento não é mais acessível se as vítimas passassem a enviar pagamentos.

Função Wiper executada em algumas condições

Após uma análise mais aprofundada, (ver Apêndice A) descobrimos também que os invasores implementaram uma função que limpa os 10 primeiros setores de `\\\\. \\ PhysicalDrive0` incluindo o MBR em duas condições:

  • Se o comando hash calculado a partir de um nome de processo em execução (“avp.exe”) retorna 0x2E214B44;
  • Se a função que substitui o MBR real retorna um erro. Provavelmente como uma maneira genérica de detectar EDR tentando impedir modificações no bootloader.

A geração do comando hash e a gestão da flag para os diferentes modos podem ser encontradas em nossa versão descompilada aqui.
UPDATE: Após uma pesquisa adicional, determinamos que o comando de hash misterioso é gerado a partir de minúsculas “avp.exe” nome do processo que correspondem ao Kaspersky Anti-Virus.

Incompatibilidade chave

Como o Kaspersky informou, a chave gerada na tela é falsa e gerada aleatoriamente. Depois de ver mais como a chave do arquivo de criptografia foi gerada, também percebemos uma inconsistência que reforça essa afirmação. Isso também pode ser comprovado comparando a “chave de instalação” exibida no README.txt e na tela – como você pode ver, o formato é claramente diferente.
À esquerda é a exibição pelo código MBR que descrevemos acima como descuido, à direita o conteúdo do README.txt com uma chave real gerada pelo ransomware.

Isso significa que, supondo que um decriptador venha a ser liberado, a entrada requerida teria que passar pelo README.txt – não da tela.

Processo de criptografia de buggy

BOOL WINAPI CryptEncrypt(
_In_ HCRYPTKEY hKey,
_In_ HCRYPTHASH hHash,
_In_ BOOL Final,
_In_ DWORD dwFlags,
_Inout_ BYTE *pbData,
_Inout_ DWORD *pdwDataLen,
_In_ DWORD dwBufLen
);

Conforme descrito por Ladislav Zezula, a flag booleana final na função CryptEncrypt é inicializada incorretamente durante a criptografia.

Chave Salsa20 define como “inválido”

A tecla Salsa20 parece ter sido modificada com um editor hexadecimal e não recompilada. O novo valor também é configurado para o valor crítico “-1n3 id-id”, que pode ser lido como “identificador secreto inválido”.

Conclusão

Acreditamos que o ransomware foi de fato uma atração para controlar a narrativa da mídia, especialmente após os incidentes do WannaCry atrair a atenção para algum grupo misterioso de hackers em vez de um atacante estatal nacional como já vimos no passado em casos que envolvem wipers como Shamoon .
O atacante tomou um ransomware existente que ele reembalou.
Ultimamente, o número de ataques contra a Ucrânia aumentou de Power Grids sendo fechado para o carro, um oficial de inteligência militar superior explodindo ontem – o dia em que Petya.2017 infectou a Ucrânia.
O fato de fingir ser um ransomware enquanto sendo de fato um ataque de Estado-nação – especialmente porque a WannaCry provou que o ransomware amplamente difundido não é financeiramente lucrativo – é, em nossa opinião, uma maneira muito sutil do atacante para controlar a narrativa do ataque.
Nota adicional, venha participar da Kaspersky & Comae amanhã quinta-feira 29 @ 10AM EST para um webinar técnico sobre o Petya – sem argumento de vendas. Nós prometemos! Apenas material técnico.

Apêndice A – Chamador

https://blog.comae.io/petya-2017-is-a-wiper-not-a-ransomware-9ea1d8961d3b?gi=6bfe48771c13