Skip to main content
SAP Pentest Playbook
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  2. /
  3. SAP ABAP Platform
  4. /
  5. Reconnaissance
  6. /
  7. SNC / Encryption Posture Assessment
Edit page

SNC / Encryption Posture Assessment

Description

SAP GUI’s presentation-layer protocol (DIAG) and RFC are unencrypted by default - both protocols support compression but neither is encrypted unless Secure Network Communications (SNC) is explicitly configured on top of them. This makes checking whether SNC is actually enforced and to what quality level one of the highest-value, lowest-effort recon steps against any classic three-tier AS ABAP landscape: a target with SNC absent or weakly configured exposes SAP GUI logon credentials (the DIAG handshake carries the password) and all subsequent screen/business data to any party positioned to observe the traffic.

SNC wraps DIAG, RFC/CPIC, SAPlpd, and SAProuter connections via SAP’s GSS-API v2 implementation, using the SAP Cryptographic Library/CommonCryptoLib as the standard crypto backend (SAP Note 1848999 is the current central note for CommonCryptoLib). Protection is configured, and negotiated, as a Quality of Protection (QoP) level:

ValueMeaning
1Authentication only - no integrity or confidentiality protection
2Integrity protection - tamper-evident, still not encrypted
3Privacy protection - encrypted
8Use the value configured in snc/data_protection/use
9Use the value configured in snc/data_protection/max

The controlling profile parameters are snc/data_protection/min, snc/data_protection/max, and snc/data_protection/use (all default to 3 on current releases, but older/legacy configurations frequently leave min at 1). Per-destination QoP for an individual RFC connection is visible in SM59 -> Logon & Security -> SNC button. snc/enable (and the presence of an snc/gssapi_lib pointing at a valid crypto library) gates whether SNC is available on the AS at all; SNC being installed does not mean encryption is enforced - a QoP of 1 or 2 still leaves traffic sniffable in plaintext or tamper-and-forward-able respectively. SAProuter route strings carry their own SNC route-permission-table entries (KT/KP in saprouttab) - see SAProuter - independent of, but interacting with, application-layer SNC on the systems it fronts.

Options

  • Passive sniff first (tool/PoC) - capture DIAG/RFC traffic on any reachable network segment (span port, MITM position, or a compromised intermediate host) with Wireshark plus the SAP-Dissection-plug-in-for-Wireshark (dissects DIAG, RFC, Router, and SNC frame headers) or pysap (SNC-aware DIAG/RFC/Router parsing). If SNC is absent entirely, this immediately yields cleartext SAP GUI logon credentials and business data.
  • Where SNC is present but QoP ≤ 2, an active position still defeats it - Troopers'17 research (Martin Gallo, Core Security) demonstrated both passive unwrap-only decoding against QoP 2 (“integrity protection”, not encrypted) and full active interception/tampering (ARP/DNS spoof to gain a MITM position, then unwrap -> tamper -> rewrap -> forward) against QoP 1 (“authentication only”). Neither scenario requires breaking the underlying cryptography - only exploiting an insufficiently strict configured QoP.
  • Confirm the unencrypted-by-default baseline without sniffing - probe DIAG-protocol reachability directly on 32XX (see Default SAP Users and Passwords for the same port/logon-flow context); a successful logon over the port with no SNC negotiation observed in the handshake confirms the connection is unencrypted end-to-end.
  • Pull the live posture with any RFC foothold - snc/enable, snc/data_protection/min, snc/data_protection/max, snc/data_protection/use are all readable via PFL_GET_SINGLE_PARAMETER (function group SPFL, remote-enabled, callable by any authenticated RFC user), following the same pattern as Security-Relevant Profile Parameters. A snc/data_protection/min of 1 or 2 on a system otherwise defaulting to 3 for use/max indicates the operator has deliberately (or accidentally) permitted weaker connections to negotiate down.
  • Native SAP tcodes (defender-equivalent check) - SM59 per-destination SNC/QoP display (as above); RZ11 for individual snc/* parameter values; SNCWIZARD/STRUST for certificate/PSE-based SNC setup review.
  • Check for the “force encryption” hardening - snc/only_encrypted_gui and snc/only_encrypted_rfc (SAP Note 1690662, kernel 7.21 patch 33+) reject any inbound GUI/RFC connection that isn’t SNC-secured and negotiated at QoP 3; their absence (both default to 0, i.e. not enforced) means a downgrade to an unencrypted or QoP 1/2 connection will simply be accepted rather than rejected.
  • Assess the crypto library itself, not just its use - an outdated CommonCryptoLib/SAPCRYPTOLIB build (pre-8.5, or the deprecated 5.5 line) carries known implementation-level weaknesses independent of QoP configuration: memory leaks in SPNego (SAP Note 2253695), missing RELRO memory-corruption mitigation (SAP Note 2427966), certificate-parsing issues (SAP Note 2376742), and SHA-1 as the historical default signature algorithm (SAP Note 2275390). sapgenpse cryptinfo (OS-level, if reachable) reports the installed library version directly.
Note
SNC/QoP assessment is a network-and-configuration recon task, not an exploitation primitive in itself - the payoff (credential/business-data disclosure) comes from combining a favorable sniffing/MITM position with a confirmed weak or absent SNC configuration. Report findings in terms of the negotiated QoP actually observed, not just whether SNC is “enabled,” since an enabled-but-QoP-1/2 configuration provides materially less protection than the profile-parameter defaults suggest.

References