Translate

Mostrar mensagens com a etiqueta cyber security. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta cyber security. Mostrar todas as mensagens

segunda-feira, 14 de junho de 2021

💀🔥 “Seu RACF está auditado… ou você só roda comando manual?”

 

Bellacosa Mainframe comenta sobre auditoria racf e segurança mainframe

💀🔥 “Seu RACF está auditado… ou você só roda comando manual?”

🧠 Checklist automatizado com JCL + REXX (nível banco, zero ilusão)

“Se sua auditoria depende de humano…
ela já falhou.”


🧠 📜 A verdade que ninguém te conta

No mundo real (banco, fintech, governo):

👉 Auditoria manual = teatro
👉 Auditoria automatizada = sobrevivência

E aqui entra a dupla lendária do mainframe:

  • JCL → orquestra
  • REXX → pensa, filtra, decide

💡 Curiosidade Bellacosa:

Antes de SIEM moderno… o mainframe já fazia auditoria automatizada com SMF + REXX.


⚙️ 🧬 Arquitetura do “scanner RACF”

👉 Fluxo real:

  1. JCL executa comandos RACF
  2. Output vai para dataset
  3. REXX lê dataset
  4. Aplica regras de auditoria
  5. Gera relatório (ou alerta)

🧨 1. JCL — o motor da auditoria

🔥 Exemplo prático (coleta de evidências)

//AUDITRAC JOB (ACCT),'RACF SCAN',CLASS=A,MSGCLASS=X
//STEP1 EXEC PGM=IKJEFT01
//SYSTSPRT DD DSN=&&RACFOUT,DISP=(,PASS),
// SPACE=(CYL,(5,5)),UNIT=SYSDA
//SYSTSIN DD *
SETROPTS LIST
SEARCH CLASS(USER) MASK(*) SPECIAL
RLIST DATASET * AUTHUSER(*)
/*

💥 O que isso faz:

  • lista configurações RACF
  • identifica usuários privilegiados
  • expõe acessos indevidos

🧠 2. REXX — o cérebro da auditoria

🔥 Exemplo prático (detecção de risco)

/* REXX */
parse arg dataset
"EXECIO * DISKR" dataset "(STEM LINES. FINIS"

do i = 1 to lines.0
if pos('SPECIAL', lines.i) > 0 then do
say 'ALERTA: usuário com SPECIAL -> ' lines.i
end

if pos('*PUBLIC', lines.i) > 0 then do
say 'RISCO CRÍTICO: acesso público detectado -> ' lines.i
end
end

💀 Resultado:

  • identifica risco automaticamente
  • elimina análise manual

🧬 3. Regras que um banco REAL usa

👉 Não é só listar — é interpretar

✔️ Nenhum *PUBLIC em dataset crítico
✔️ SPECIAL limitado
✔️ APF controlado
✔️ UID 0 auditado
✔️ FACILITY revisada
✔️ STARTED TASK mapeada


⚙️ 4. Evolução hardcore (nível enterprise)

👉 Automatização completa:

  • agendado via JES2 / scheduler
  • output versionado
  • comparação diária (drift detection)
  • envio de alerta (email / SIEM)

💡 Easter egg:

Drift de segurança é mais perigoso que invasão direta.


🧠 5. Comparação inteligente (ontem vs hoje)

🔥 Ideia poderosa

REXX pode comparar execuções:

if linha_hoje \= linha_ontem then
say 'ALTERAÇÃO DETECTADA!'

💥 Isso detecta:

  • privilégio adicionado
  • acesso aberto
  • mudança suspeita

🧾 6. Output estilo auditor (nível banco)

👉 Não basta log — precisa ser auditável

Exemplo:

[CRITICAL] USER HACKER HAS SPECIAL
[HIGH] DATASET PROD.FINANCE WITH *PUBLIC READ
[MEDIUM] NEW APF LIBRARY DETECTED

💣 7. Onde mora o perigo real

👉 Não está no código… está na omissão

🔥 Problemas comuns:

  • script roda mas ninguém lê
  • alertas ignorados
  • baseline inexistente

💡 Insight:

Auditoria sem ação é só documentação bonita.


🧠 8. Easter eggs de quem vive isso

💡 IKJEFT01 é o “shell invisível” do z/OS
💡 REXX consegue parsear RACF melhor que muita ferramenta cara
💡 JES spool é fonte de ouro pra auditor
💡 dataset temporário mal protegido = vazamento


⚔️ 9. Fluxo real de ataque vs auditoria automatizada

👹 Ataque:

  1. ganha acesso
  2. eleva privilégio
  3. altera RACF
  4. mantém persistência

🛡️ Auditoria automatizada:

  1. detecta alteração
  2. gera alerta
  3. compara baseline
  4. bloqueia rapidamente

🏦 Realidade nível banco

👉 Banco não confia em:

  • print de tela
  • comando manual
  • auditor humano

👉 Banco confia em:

  • automação
  • evidência
  • histórico

💀🔥 Frase final Bellacosa

“Se o seu RACF muda e você não percebe…
quem percebe é o atacante.”

sábado, 1 de maio de 2021

💀🔥 “Seu RACF está seguro… ou você só acha?”

 

Bellacosa Mainframe alerta sobre riscos no racf mal configurado

💀🔥 “Seu RACF está seguro… ou você só acha?”

🧠 Checklist de Auditoria RACF nível banco (com segredos que ninguém te conta)

“RACF não falha…
quem falha é quem confia demais nele.”


🧠 📜 Contexto histórico (o começo de tudo)

O RACF nasceu nos anos 70 junto com o z/OS (antes MVS).

👉 Naquela época:

  • segurança era controle de acesso
  • hoje é sobrevivência digital

💡 Curiosidade:

RACF foi um dos primeiros sistemas do mundo a implementar controle centralizado de identidade — antes do conceito de IAM moderno.


💀🔥 O CHECKLIST QUE SEPARA AMADOR DE BANCO


🧨 1. *PUBLIC — o vilão silencioso

👉 Procure:

// quem tem acesso aberto?
RLIST DATASET * AUTHUSER(*)

💥 Red flag:

  • datasets críticos com:
ID(*PUBLIC) ACCESS(READ ou UPDATE)

🔥 Insight Bellacosa:

80% das falhas começam aqui.


🧠 2. Usuários com SPECIAL / OPERATIONS

👉 Liste:

SEARCH CLASS(USER) MASK(*) SPECIAL

💥 Risco:

  • acesso total ao RACF

🎯 Dica senior:

  • separar:
    • ADMIN ≠ AUDITOR

⚙️ 3. Grupos com autoridade excessiva

👉 Verifique:

LISTGRP * OMVS

💥 Problema:

  • grupo herdando privilégio indevido

🔥 Easter egg:

Um grupo mal configurado é pior que um usuário root.


🧬 4. Programas APF e AC=1

👉 Verifique APF:

D PROG,APF

💥 Risco:

  • execução em modo supervisor

🎯 Ataque clássico:

  • inserir loadlib malicioso

🔐 5. Password Policy (o calcanhar de aquiles)

👉 Cheque:

SETROPTS LIST

💥 Problemas comuns:

  • senha simples
  • sem expiração
  • sem history

🔥 Curiosidade:

Já vi banco com senha “123456” em ambiente produtivo.


🌐 6. FACILITY class (o “backdoor oficial”)

👉 Verifique:

RLIST FACILITY *

💥 Risco:

  • permissões ocultas

🎯 Exemplo crítico:

  • BPX.* (Unix System Services)

🧑‍💻 7. USS (Unix no mainframe = Linux feelings)

👉 Verifique:

LISTUSER USER OMVS

💥 Risco:

  • UID 0 (root)

🔥 Insight:

USS é o ponto favorito de pivot de atacante moderno.


🧾 8. Logging / SMF (sem isso você está cego)

👉 Cheque:

  • SMF 80 (RACF)
  • SMF 30 (jobs)

💥 Problema:

  • logs incompletos

🎯 Dica:

  • integrar com SIEM

🧠 9. Started Tasks (STC) — privilégio invisível

👉 Verifique:

RLIST STARTED *

💥 Risco:

  • tarefas com privilégios elevados

🔥 Easter egg:

STC mal protegido = root invisível rodando 24x7


🔗 10. Integrações externas (o novo campo de batalha)

👉 Verifique:

  • CICS
  • z/OS Connect

💥 Risco:

  • acesso indireto ao core

🎯 Realidade:

O ataque não entra pelo mainframe… entra pela API.


💀🔥 CHECKLIST RÁPIDO (modo auditor)

✔️ Nenhum dataset crítico com *PUBLIC
✔️ SPECIAL restrito e auditado
✔️ APF controlado
✔️ Senha forte e rotacionada
✔️ SMF ativo e monitorado
✔️ USS sem UID 0 indevido
✔️ FACILITY revisada
✔️ STC mapeado
✔️ Integrações seguras


🧠💣 Fluxo real de ataque (pra abrir a mente)

  1. credencial fraca
  2. acesso TSO/FTP
  3. enumeração RACF
  4. exploração (APF / FACILITY / USS)
  5. persistência
  6. exfiltração

🧬 Easter Eggs que só senior percebe

💡 RACF não protege dataset não catalogado direito
💡 APF + AC=1 = execução nível kernel
💡 FACILITY é mais perigosa que DATASET
💡 USS é o “Linux escondido” do mainframe


🏦 Realidade nível banco

👉 Banco não confia em RACF…
👉 Banco audita RACF o tempo todo


🔥 Frase final estilo Bellacosa

“Se você não auditou seu RACF hoje…
alguém pode estar usando ele melhor que você.”

 

quinta-feira, 1 de abril de 2021

🧠 💥 Coletânea de ataques hacker em ambiente IBM Mainframe

 

Bellacosa Mainframe apresenta alguns casos de ataques hackers em mainframe

🧠 💥 Coletânea de ataques hacker em ambiente IBM Mainframe

🧪 1. 1965 — O primeiro “hack” da história (IBM 7094 – CTSS)

👉 Sistema: IBM 7094 (CTSS – Compatible Time Sharing System)

O que aconteceu:

  • Um bug no editor criou um arquivo temporário com nome fixo
  • Dois usuários simultâneos causaram:
    • exposição do arquivo de senhas (!)

Impacto:

  • Senhas ficaram visíveis para qualquer usuário

📌 IMPORTANTE:
👉 Isso é considerado o primeiro vazamento de credenciais da história

✔️ Lição:

  • Controle de concorrência e isolamento são fundamentais


🧠 2. 1967 — Primeira invasão de rede (IBM APL Network)

👉 Ambiente: rede experimental IBM APL

O que aconteceu:

  • Estudantes exploraram workspaces compartilhados
  • Conseguiram navegar além do escopo permitido

Impacto:

  • Primeira invasão “não autorizada” documentada em rede

✔️ Lição:

  • Segurança lógica > segurança física


💣 3. 2007 — Primeiro hack documentado em z/OS moderno

👉 Caso citado em estudos de segurança mainframe

Possível alvo:

  • Banco europeu (ex: Nordea Bank)

O que aconteceu:

  • Uso de vulnerabilidades em ambiente z/OS
  • exploração via acesso indireto (provavelmente aplicações)

✔️ Lição:

  • Mainframe moderno também é atacável


🏦 4. 2012 — Caso Nordea Bank / Governo Sueco (O MAIS CLÁSSICO)

👉 Ambiente: IBM z/OS

O que aconteceu:

  • Hackers usaram:
    • z/OS emulado
    • exploração de vulnerabilidades (0-day)
  • Conseguiram:
    • escalar privilégios (SPECIAL)
    • modificar APF
    • acessar dados sensíveis
    • transferir dinheiro (~$850k)

Impacto:

  • Um dos raros casos confirmados de invasão real em mainframe

✔️ Técnica usada:

  • privilege escalation
  • persistência (APF)
  • exfiltração de datasets

✔️ Lição:

  • RACF mal configurado = porta aberta


🏴‍☠️ 5. 2012 — Hacker do Pirate Bay (caso judicial)

👉 Hacker: cofundador do Pirate Bay

O que aconteceu:

  • Invasão de mainframe
  • Roubo de dados governamentais

Impacto:

  • considerado o maior caso de hacking de mainframe na Dinamarca

✔️ Lição:

  • ameaça real não é só técnica — é também judicial/legal


🧾 6. Casos indiretos (2014–2015) — Dados de mainframe expostos

👉 Empresas:

  • Home Depot
  • Anthem
  • Experian

O que aconteceu:

  • Ataque NÃO começou no mainframe
  • MAS:
    • dados críticos estavam no mainframe
    • foram exfiltrados via sistemas distribuídos

Impacto:

  • milhões de registros vazados

✔️ Insight poderoso:
👉 O mainframe NÃO foi invadido diretamente
👉 mas foi comprometido indiretamente

✔️ Lição:

  • o risco está na integração (APIs, middlewares)


⚠️ 7. Casos IBM i (AS/400) — “Nunca foi hackeado” (mito quebrado)

👉 Realidade:

  • já houve invasões documentadas

Problema comum:

  • permissões abertas (*PUBLIC *ALL)
  • falta de auditoria

✔️ Lição:

  • segurança default ≠ segurança real


🧨 8. Engenharia social e insider (o ataque mais comum)

👉 Segundo especialistas:

  • A maioria dos ataques não é “hack remoto hollywoodiano”
  • São:
    • insiders
    • credenciais roubadas
    • acesso legítimo abusado

✔️ Lição:

  • RACF + auditoria > firewall


📊 9. Estatística brutal (realidade do mercado)

👉 Apenas 0.1% dos mainframes reportaram breach direto

✔️ Tradução Bellacosa:

  • extremamente seguro
  • MAS quando falha → impacto é gigante


🧠 🔥 Padrões REAIS dos ataques em Mainframe

🧩 Vetores mais comuns

  • má configuração de RACF / ACF2 / Top Secret
  • credenciais roubadas
  • aplicações CICS vulneráveis
  • integração com sistemas distribuídos
  • insiders

⚙️ Técnicas usadas

  • privilege escalation (SPECIAL / OPERATIONS)
  • manipulação de APF
  • execução de REXX malicioso
  • leitura de datasets (PII)
  • exfiltração via FTP / TCP/IP stack

💀 MITO vs REALIDADE

MitoRealidade
Mainframe não é hackeávelÉ, mas difícil
Só ataque externoMaioria é interna
RACF resolve tudoDepende da configuração
Isolado = seguroIntegração quebra isso

🧠 Conclusão estilo Bellacosa

👉 O mainframe NÃO é invulnerável
👉 Ele é mal compreendido

💡 A verdade:

“Mainframe não cai por brute force…
cai por negligência.”


PS: Nunca se esqueça que o inimigo pode estar dentro do castelo. E os demonios riem quando fazemos planos infaliveis.