Securing Real-Time Communications: How SBCs Protect Your Business

1. Securing Real-Time Communications:How SBCs Protect Your Business Patrick McNeil, Product Security Lead Hendrik Scholz, Product Manager

2. The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

3. Program Agenda • What is a Session Border Controller (SBC)? • Security Threats • Debunking misconceptions • Best Practices

4. What is a Session Border Controller?

5. RFC3261 “Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests.”

6. SBCs create a service demarcation Service Provider Network • Stop Denial of Service attacks (flooding, fuzzing) • Hide topology • Encrypt endpoint communications if needed • Highly available • Provide normalization / interoperability • Secure management Internet Enterprise Data Network See RFC5853 for a full description of SBC requirements

7. Primary Threats &Fraud Types

8. Methods of Access and Abuse GSMA Fraud Forum Categories

9. PBX Compromise Common methodology enables fraud and theft of service • Scan wide IP range looking for SIP servers • Call attempt to probe for systems allowing unauthenticated calls • Brute-force user credential guessing (if required) • Call attempts to known number or “burner phone” to find dial-out prefix OPTIONS sip: 1.1.1.1 Cracked line registered and used for IRSF or wholesale fraud INVITE sip:100@ 1.1.1.1 REGISTER sip: 100@1.1.1.1 Password: 100, 101, 102, etc. INVITE sip:7817966920@ 1.1.1.1 INVITE sip:97817966920@ 1.1.1.1

10. Outbound line scanning 65 seconds between successful break-in and abuse

11. Voicemail Compromise Voicemail features used for fraud • Fraudsters manually dial passcodes until successful • Abused voicemail features • Call-through – new call originating from voicemail system • Call-back – leave voicemail with spoofed origination number and have the system ‘call back’ • Call-forwarding – all calls forwarded to IRSF or wholesale number Password: 100 101 102 103

12. International Revenue Sharing Fraud Using a compromised PBX or voicemail system • Fraudster registers revenue-share number • Profits from each inbound call to number, e.g. paid weekly • Foreign country operator provides equipment, makes prosecution/blocking difficult • Fraudster directs traffic to revenue-share number • Inflates traffic from PBXes, voicemail systems • Wangiri scam 1st Compromise System Credentials 3rd PBX routes calls to fraudster in expensive foreign market 2nd Make calls using cracked credentials

13. Wholesale Fraud Using a compromised PBX or voicemail system • Fraudster uses compromised system to forward traffic between two valid service providers for attractive rates, usually advertised on wholesale marketplace websites • Revenue paid to fraudster by operators who route calls to the fraudulent trunk; Paid daily or weekly, valid subscriber billed monthly Valid Operator Compromised System Valid Operator

14. Service overload vs Denial of Service Definition • Overload – Consumption of total capacity of one or more components in a system, thereby creating a “bottleneck” that impacts service. • Can be accidental due to outage, misconfiguration, poor engineering, or unforeseen usage spike • Denial of Service (DoS) – targeted overload where disruption of service is primary motivation • May distract from another attack • Attacks can be at different layers • Application - correctly signaled calls over the trusted call path • Transport - invalid format or state attacks – SIP floods, fuzzing, encryption renegotiation, TCP SYN, ICMP, etc.

15. Service overload Challenge – overload differentiation vs DoS • What is an attack and what is just an unexpected overload? Some normal or accidental occurrences may look like attacks • ‘Manhattan reboots’ scenario – recovery from a power outage creates avalanche of legitimate calls (alarm systems, backup modems, etc) • Misconfigured automation, call forwarding, or bad contact center rule • Mass calling event - radio station contest, phone voting for TV program

16. Denial of Service Real attacks • Application layer DoS attacks • Sometimes called Telephony DoS (TDoS) • Usually floods of calls to specific numbers with spoofed origination • Blocking difficult in network of trusted service provider peers since calls come in multiple trunks • Against business targets - usually automated, a few ‘social’ attacks • Against individuals – payday scams • Threats and extortion against individuals with an outstanding loan during business hours, to business number • May be coupled with fake call to police to nearby address • Loan information purchased from Internet clearinghouses • Manually conducted using a cheap labor pool

17. Debunking misconceptions

18. Some of the misconceptions Fabricated problems and incomplete solutions • “NULL packets” used for Denial of Service • TDoS easily stopped with <insert product here> • Fuzzing billed as “top violation” but not seen frequently • The long list of threats

19. “NULL packets” used for DoS Keep-alives cast as malicious “NULL packets” • “NULL packets” • Empty messages used to keep NAT bindings and firewall pinholes open • Sent every few seconds to minutes • Content • “\r\n\r\n” via UDP – no response required, easily filtered • Ping-Pong game (via TCP) (RFC 5626) • STUN (RFC 5389) based mechanism • Impact • No attack but required for proper network operation NAT Ping CRLF “\r\n\r\n” Pong CRLF “\r\n”

20. Fuzzing as a “top violation” Fuzzing: Syntactically or semantically invalid messages • Fuzzing requires lots of messages so it is very “noisy” • Easily detected and stopped with message thresholds and syntax enforcement • In reality, after fingerprinting target service, fuzzing done offline with test equipment to determine vulnerabilities • Attacks will be targeted and precise • Edge security device needs to inspect messaging and enforce RFC defined format • Monitoring behind edge will only see normalized traffic

21. TDoS easily stopped with <insert product here> Oversimplification of the problem • Solutions relying on premise-based equipment can only limit number or rate of calls to protect core equipment, but cannot stop the attack. • Circuit capacity can always be overwhelmed, even if stopped at your edge. • From number changes – multiple actors or adaptation to evade filters • Solutions that tear down calls based on audio identification - another call gets established immediately afterwards • Some solutions placed behind edge equipment (e.g. SBC, proxy) • Equipment has to deal with attacks

22. Detecting and stopping TDoS Placement of <insert product here> into live network • Monitoring systems often placed on private/core side of network • Cannot see attacks blocked by edge devices (SBC, proxy) • Cannot prevent the attack on edge devices • Chicken-Egg problem when placing monitoring in front + in-line • Monitoring becomes active component subject to attacks • Monitoring has to support all VoIP features or it will degrade service • Monitoring effectively becomes SBC, proxy

23. The long list of threats Restating the problem to generate fear, uncertainty and doubt

24. Address the root causes SIP Threats are related Toll Abuse TDoS L3 Fraud Unauth Access DoS / Overload • Most vendor “threats” further enumerate or restate a single issue many ways • Many threats can be eliminated through best practices vs. complicated products • If attack tools used are understood, some specific mitigations can be designed Stack Finger-print DoS Recon Scan Fuzzing Serv. Finger-print Inject-ion MITM SPAM / SPIT Phish-ing Hijack Mal-ware Media Inject. Tear-down Wan-giri

25. Best Practices

26. At the edge SBC Inspect, Block, and Limit with an SBC • Inspect & block invalid messages with IP & SIP format inspection, thresholds & blacklisting by trust level on per IP basis, rate limitations, access control lists, known attack tool signatures, etc. Enforced at the SBC hardware level by specialized ASICs. • Next protect against floods of ‘valid’ calls. Understand that all valid looking messages will make it to internal services if thresholds are not applied. • Call admission controls for number of valid calls to services interface and next-hop downstream (or upstream) • Message rate limitation by SIP method to limit call setups also by interface and next-hop • Local routing tables for routing based on SIP message or dial-plan • Blacklist from known fraudulent number prefixes if business model allows. Blacklist should include prefixes outside of valid dial-plan and contact country codes (if possible). Known fraudulent numbers are available through CFCA or GSMA membership. • Where possible, blacklist all, and whitelist known from numbers (ex: contact center transfers)

27. Real-time call analysis at the edge - Palladion Use call analysis software to identify potential attacks • Traditional fraud detection systems are CDR based after the fact which yields long reaction times • Watch real-time SIP signaling for patterns to identify start of TDoS and fraud with Palladion real-time communications monitoring software. • Overall call volume • Time of day distribution • Calling patterns by geography • Inbound or outbound call ratio changes • Traffic collection from SBC or COTS server based probe • Look at traffic before normalization/removal of attacks. • Scale monitoring to allow analysis of floods (‘wire speed’)

28. Palladion 3.0 real-time and historical analysis

29. Palladion 3.0 message flow

30. At the service Harden and limit unnecessary services • Follow vendor hardening guidelines • Don’t put PBX admin interface on the Internet • Don’t use three digit extensions (default for SIPVicious); Consider five or more digits • Limit (or eliminate) voice features that aren’t used like call forwarding, voicemail callback, and dialing out from voicemail • Block international dialing when possible, or limit dial-plan scope • Delete or administratively disable unused extensions • Audit user passwords by trying to crack them • Use TLS/SRTP with mutual certificate authentication over untrusted links

31. Stopping TDoS with your peers / providers Understand the threat profile • Have tools for identifying and blacklisting IP(s) and/or phone numbers conducting TDoS (SBCs & comm. monitoring software) • Expect attack adaptation to evade your filters. • Have clear escalation contacts for responding to attacks (DoS or TDoS). Blocking IP(s) or phone numbers will only last so long, and you need to move prevention to a prior hop. • Understand how your service provider deals with nuisance calls vs TDoS. Nuisance calls may require a police report. • Place value on business reputation. Deal with providers, peers and interconnect carriers who can articulate what they’re doing (or planning on doing) to identify and shut down TDoS sources on their network.