Developing Strategies to Protect SS7 from Manipulation and ... filefor the IP world & SIGTRAN Not surprisingly, in the carriers‘ endeavour to consolidate everything-over-IP SS7 t

Developing Strategies to Protect SS7from Manipulation and Abusefrom Manipulation and Abuse

Enno Rey, [email protected]

Who I am

“Old-school networker“ with vast carrier background.

Started working on Layer 2–4 in the early 90s.

With special focus on security since 1997With special focus on security since 1997.

(Co-) Author of several books, articles and whitepapersand regular speaker on international conferences(incl. Black Hat, Hack In The Box, FutureNet).

Founder (2001) and CTO of a highly specialized information security consultancy [www.ernw.de] with 12 employees, based i H id lb /G d Li b /PTin Heidelberg/Germany and Lisbon/PT.

2

IT-Symposium 2008 04.06.2008

www.hp-user-society.de 1

Agenda

Quick overview of SS7 functions and components

Draw the curtain... for the IP world & SIGTRAN

Again some terms and conceptsAgain some terms and concepts

What are the risks?

Notes from the field

Mitigating controlsMitigating controls

MAPsec anyone?

Summary & Outlook

3

Introduction

€76 million

That‘s the sum Vodafone Greece fi d i th fwas fined in the course of

The Athens Affair.

A large wiretapping scandal performed with the help of rogueperformed with the help of roguesoftware running on some switching equipment.g q p

4

IT-Symposium 2008 04.06.2008


So what‘s the point here?

Think about it...

Devices with switching functions... and wiretapping capabilities... got manipulated and abused by some intruder(s).

Telco blamed for failing to protect its network.

To understand the link to SS7 some basics needed:

5

General notes on SS7

SS7 = Signaling System 7

Out-of-band connection control for telephone calls, fax services, data services (ISDN) etc.

in contrast to in-band signaling that uses the same physical path for both signaling and calls.

A set of protocols

Principal organization: ITU-Tp g

Mostly based on packet switching technologyunlike e g the telephone calls themselves that are (have been) basedunlike e. g. the telephone calls themselves that are (have been) basedon circuit switching.

6

IT-Symposium 2008 04.06.2008


Topology and terms

The typical SS7 architecture: segregation of signaling (control network) and subscriber communication (telephone network)

Switching Office / Signal Switching Point (SSP)

network) and subscriber communication (telephone network)

Point (SSP)position: the interface between the subscriber and the carrierf ti i lifunctions: signaling + subscriber communication

Signal Transfer Point (STP)position: control networkfunction: forwarding of control messagesmessagesmay be SSP at the same time

7

SS7 – Layered approach

Derived from the OSI modelUses its own protocol stack

Layer4+ (“application layer“ – theactual signaling)

Layer1 3: Message Transfer Part 1 3(“network layer“ – has little to do withthe actual signaling, rather with thetransport of the signaling messages)

8

IT-Symposium 2008 04.06.2008


Real life SS7 “security“

Existing trust relationships amongst telcosClosed networks

Nearly no additional security measures.

9

Draw the curtain...for the IP world & SIGTRANfor the IP world & SIGTRAN

Not surprisingly, in the carriers‘ endeavour to consolidate thi IP SS7 t th IP ld teverything-over-IP SS7 moves to the IP world, too.

SIGTRAN ki t IETF ibl f tSIGTRAN working group at IETF responsible for a new setof standards and protocols.So far a n mber of RFCs iss ed mainl 2719 & 4166So far a number of RFCs issued, mainly 2719 & 4166.

F d id it b f l ti il blFrom vendor side quite a number of solutions availablethat incorporate “classical SS7“ plus IP/SIGTRAN stacks.

10

IT-Symposium 2008 04.06.2008


The SIGTRAN Protocol Architecture

3) Adaptation Sublayer, another set of protocols,the interface between the new transportprotocol and the SS7 signaling applications

2) Stream Control Transmission Protocol (SCTP)

protocol and the SS7 signaling applications(SCTP User Application).

2) Stream Control Transmission Protocol (SCTP),the new transport protocol, developed for thisspecial purpose but good for other things, too(Layer4 protocol)

1) Standard IP without any special features.

(Layer4 protocol).

11

Stream Control Transmission Protocol (SCTP)(SCTP)

• Assumes the role of SCCP (instead of TCP)• RFC 2960• Position in the protocol stack: between IP and the

d t ti bl ( ) idi i t f t i liadaptation sublayer(s), providing interfaces to signaling.

• SCTP s TCP common feat res• SCTP vs. TCP, common features:– reliable transport– sequencing of packetssequencing of packets– connection oriented

12

IT-Symposium 2008 04.06.2008


SIGTRAN “security“ discussion

SCTP has some features to provide better security than TCPmainly 4-way handshake with cookiesprotects availability

To protect other security goals (confidentiality integrity)To protect other security goals (confidentiality, integrity)additional means needed.

There‘s even a “dedicated security RFC“ out there: Security Considerations for Signaling TransportSecurity Considerations for Signaling Transport(SIGTRAN) Protocols [RFC 3788]

Might address the wrong goals, in the wrong way.Is IETF‘s security advice followed by carriers anyway (RFC 3013 etc.)?Do “telephony engineers“ even know there‘s something like IETF?

13

Hypothesis

Converting from SS7 to SIGTRAN will (re-) introduce a bunch of security problems (long known in the IP world)bunch of security problems (long known in the IP world).

To understand those (and address them in an appropriateTo understand those (and address them in an appropriateway) a quick risk analysis is needed:

AssetObjectivesThreats & VulnerabilitiesRisksRisksMitigating Controls

Simplied asset here: signaling data as a whole.For a more extensive RA example see [1].

14

IT-Symposium 2008 04.06.2008


Risk

ISO/IEC GUIDE 73:2002

“Combination of the probability of an event and itsconsequence“consequence

wherewhere

Probability = extent to which an event is likely to occurEvent = occurrence of a particular set of i tcircumstances

Consequence = outcome of an event

15

Security Goals

RFC 3871, sect. 1.4:

A secure network is one in which:

o The network keeps passing legitimate customer traffic (availability).o Traffic goes where it is supposed to go, and only where it is supposed to goo Traffic goes where it is supposed to go, and only where it is supposed to go(availability, confidentiality).o The network elements remain manageable (availability).o Only authorized users can manage network elements (authorization).o There is a record of all security related events (accountability).o The network operator has the necessary tools to detect and respond too The network operator has the necessary tools to detect and respond toillegitimate traffic.

16

IT-Symposium 2008 04.06.2008


Threats...

On protocol levelPoorly designed protocols may lead to breach of conf/int/availPoorly designed protocols may lead to breach of conf/int/availBad implementations suffering from buffer overflows etc.Protocol complexity may lead to bad firewall configuration

On connection levelOn connection levelEavesdropping / Call Monitoring (Breach of confidentiality)Data Corruption / Modification (Breach of integrity)Denial-of-Service (Loss of availability)

By attackDue to misconfiguration (e.g. insufficient resources/prioritization)

On device levelOn device levelSystem compromise=> Eavesdropping / Call redirection / Billing fraudD i l f S i (L f il bilit )Denial-of-Service (Loss of availability)

By attackDue to misconfiguration

17

... & Vulnerabilities

On protocol levelDesigned without security in mind

No appropriate filtering / firewall support

On connection level(Nearly?) no encryption by default

Existing security mechanisms not used due to deployment problems

On device levelDesigned/assembled/configured without security in mind

Unsecure default configurationsUnsecure default configurationsSegregation of duties principle may be violated

18

IT-Symposium 2008 04.06.2008


A very simple (_exemplary_) RA

Source Likelihood Rating of & Consequence(s)

Risk Mitigating ControlsCo seque ce(s)

Bad protocol implementations

2 4Loss of availability

8 Choice of platform,Patch management

(e.g. see [2])g

Eavesdroppingon “SIGTRAN

2 5Billing fraud

10 Network design,Access controlon SIGTRAN

traffic“Billing fraud,Violation of regulations

Access control

Device 3 5 15 Secure managementDevicecompromise

3 5Billing fraud,Violation of regulations

15 Secure management,Monitoring & Logging

g

19

Notes from the field

Due to some experience in carrier d d i ispace we regard device compromise

as a major threat.

We have access to some statistical data on SCTP use in the Internet thatdata on SCTP use in the Internet thatwas collected in a recent research project.p j

20

IT-Symposium 2008 04.06.2008


Some statistics

Within a given IP space approx. 0.2% of the hosts “speak SCTP“% f CAbout 60% of those are Cisco network devices

About 25% based on Solaris, rest mostly Linux/AIX/*BSD

Some devices do not respond to “any TCP traffic from Internet“.Amongst the responding onesAmongst the responding ones

75% have telnet listening to the Internet30% have SSH open to Internetp20% reachable on HTTP interface10% have SNMP enabled with RO community “public“

21

Interesting observations

Quite some nodes responded which had no TCP ports open at allopen at all

Obviously they are protected by some packet filter/ACL/firewallStill reachable by SCTP. Were you aware of that?Buffer overflow in SCTP implementation could thus lead to full system compromise.

A couple of devices additionallyff SIP/H 323/ th i li toffer SIP/H.323/other signaling prots.

Strong indicator of actual use for signaling/call transfer use.

Some boxes seem vulnerable to full system compromise.

22

IT-Symposium 2008 04.06.2008


Conclusions

Management interfaces might impose the Achilles‘ heel of some devicesthe Achilles heel of some devicesthat are part of a given SS7/SIGTRAN infrastructure.


Risk Mitigating Controls

Bad protocol 2 4 8 Choice of platformBad protocolimplementations (e.g. see [2])

2 4Loss of availability

8 Choice of platform,Patch management

Eavesdropping 2 5 10 Network design,pp gon “SIGTRAN traffic“

Billing fraud,Violation of regulations

gAccess control

Devicei

3 5Billi f d

15 Secure management,compromise Billing fraud,

Violation of regulations

Monitoring & Logging

23

Mitigating Controls

The “basic building blocks of network security“ should work here:

Access Control / Authentication Isolation / SegmentationRestriction / FilteringEncryptionHardening of Infrastructure ServicesHardening of Infrastructure ServicesSecure ManagementLogging / Monitoring

Policy

Always remember: Operations is key!

24

IT-Symposium 2008 04.06.2008


Some notes – Restriction & Filtering

Usually there‘s no need for inbound SCTP/SIGTRAN traffic f kfrom unknown sources.This might even apply to “other signaling traffic“ as well.

Filtering SCTP (e g from broadband segments) is easFiltering SCTP (e.g. from broadband segments) is easy:

access-list $number deny 132 any $our devicesaccess list $number deny 132 any $our_devices

25

Some notes – Secure Management

Restriction of source addresses authorized for mgmt access.

Choice of protocols (SSH vs. telnet, HTTPS vs. HTTP,p ( , ,SNMPv3 vs. community-based SNMP). See also [4].

Use of good passwords and personalized accountsUse of good passwords and personalized accounts(for accountability).

In short: all the basic stuff from RFC 3013…

26

IT-Symposium 2008 04.06.2008


Some notes – Logging & Monitoring

“It's impossible to overstate the importance of logging.“

[from the IEEE Spectrum article on the Athens Affair]

In fact Vodafone was mainly fined for destroying evidence.In fact Vodafone was mainly fined for destroying evidence.You do log + monitor extensively for compliance reasons,don‘t you? ;-)y ; )Ask yourselves: would you notice if the software or configuration of a network device was modified?

27

MAPsec anyone?

Proposed standard (3GPP TS 33.200) to encrypt communications between networkencrypt communications between networkelements.Covers the transport security of the MAP protocol itself as well as the securityprotocol itself, as well as the securitymanagement procedures.

Co ld protect confidentialit and integrit ofCould protect confidentiality and integrity oftraffic between nodes.However important pieces (e.g. key mgmt) not

t l t l t d di dyet completely standardized.

Some networks tried to deploy... and removed p yit due to performance bottlenecks.

28

IT-Symposium 2008 04.06.2008


Summary & Outlook

SS7 will be replaced by its IP based counterpart (SIGTRAN) in the (near) future Security wise this will bring(SIGTRAN) in the (near) future. Security-wise this will bringa paradigm shift from a “walled garden“ to the “open IP world“, with associated risks.

Devices and their management interfaces might be the k t i t ithi th l d Gi th i t iweakest point within the landscape. Given the wiretapping

capabilities of most devices breaches can then have large impact on call privacy.p p ySo far the public discussion seems to have overlooked this focus.

If deployed correctly, the risks can be mitigated.

29

Questions?

30

IT-Symposium 2008 04.06.2008


Thanks for your attention!

31

Final Wisdom

Whatever you do... always remember the following two:

Ross Callon in RFC 1925:

“Some things in networking can never be fully understood by someoneSome things in networking can never be fully understood by someonewho neither builds commercial networking equipment nor runs an operational network.“

=> If really interested in this stuff get your hands on some devices ;-)

Si li it P i i l f RFC 3439Simplicity Principle from RFC 3439:

“The implication for carrier IP networks then, is that to be successfulwe must drive our architectures and designs toward the simplestwe must drive our architectures and designs toward the simplestpossible solutions.“

32

IT-Symposium 2008 04.06.2008


References

[1] ERNW document Voice-over-IP Risk Analysis:http://www.ernw.de/content/e7/e183/e1088/download1090/voip_risk_analysis_ger.pdf

Examples include:

http://sunsolve.sun.com/search/document.do?assetkey=1-26-103101-1http://cve mitre org/cgi bin/cvename cgi?name=CVE 2006 1858http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-1858http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3745

Sherr et.al.: Signaling vulnerabilities in wiretapping systems:http://www.crypto.com/papers/wiretap.pdf[4] On SNMP: http://www.ernw.de/content/e7/e181/e671/download690/ERNW_026_SNMP_HitB_Dubai_2007 ger pdf2007_ger.pdfPhilippe Langlois: SCTPscan - Finding Entry Points to SS7 Networks & Telecommunication Backboneshttp://www.blackhat.com/presentations/bh-europe-07/Langlois/Whitepaper/bh-eu-07-p p p g p planglois-WP.pdfRFC 2804 IETF Policy on Wiretapping

33

Voice-over-IP Risk Analysis

Enno Rey CISSP/ISSAP CISAEnno Rey, CISSP/ISSAP, [email protected]

IT-Symposium 2008 04.06.2008


Risk


“Combination of the probability of an event and itsconsequence“

where

Probability = extent to which an event is likely to occurProbability extent to which an event is likely to occurEvent = occurrence of a particular set of circumstancesConsequence = outcome of an eventConsequence outcome of an event

Voice-over-IP Risk Analysis 2

Risk Analysis


“systematic use of information to identify sources and to estimate the risk“

Source: item or activity having a potential for a consequenceSource: item or activity having a potential for a consequence

Risk analysis provides a basis for risk evaluation, risky ptreatment and risk acceptance.Information can include historical data, theoretical analysis, informed opinions, and the concerns of stakeholders.


IT-Symposium 2008 04.06.2008


Security Objectives VoIP

AvailabilityConfidentialityConfidentialityPrivacyIntegrity (?)

- of calls/transported data- of billing data/arrival time of voice mails/state of communication participants/etc.

Compliance with regulations (Privacy protection, Lawful interception, 911 calls, other)p g ( y p p )

Prevention/avoidance ofidentity spoofingy p g- of caller/callee (both may lead to social engineering attacks)=> billing fraud=> other fraud (telephone banking)

covert channels (Skype)


VoIP – Threats (“Sources“)

Threats on protocol levelThreats on connection levelThreats on gateway levelThreats on endpoint level

Remote control of hosts / covert channels


IT-Symposium 2008 04.06.2008


Threats on protocol level

TP1: Poorly designed protocols may lead to breach of f/i t/ ilconf/int/avail

TP2: Bad implementations suffering from buffer overflows etc.TP3 P t l l it l d t b d fi ll fi tiTP3: Protocol complexity may lead to bad firewall configuration


Example:Bad implementation with buffer overflowBad implementation with buffer overflow


IT-Symposium 2008 04.06.2008


Threats on connection level

TC1: Eavesdropping / Call Monitoring (Breach of confidentiality)TC2: Data Corruption / Modification (Breach of integrity)Denial-of-Service (Loss of availability)TC3 b tt kTC3: - by attackTC4: - by misconfig. (e.g. insufficient resources/prioritization)


Threats on gateway level

Note: term “gateway“ applies to any central component like gateways gatekeepers call managers (CM) session bordergateways, gatekeepers, call managers (CM), session bordercontrollers (SBC), SIP proxies/registrars/redirectors etc.

TG1: System compromise=> Eavesdropping

C ll di ti=> Call redirection=> Billing fraud

Denial-of-Service (Loss of availability)TG2: - by attackyTG3: - by misconfiguration


IT-Symposium 2008 04.06.2008


Threats on endpoint level

TE1: System compromise=> Eavesdropping=> Eavesdropping=> Call redirection=> Billing fraud

TE2: Denial-of-Service (Loss of availability)b tt k- by attack

TE3: VoIP endpoint as attack vector for malware spreadTE3: VoIP endpoint as attack vector for malware spread(applies particularly to softphones)

TE4: Covert channels


Vulnerabilities

Vulnerabilities on protocol levelVulnerabilities on connection levelVulnerabilities on gateway levelVulnerabilities on endpoint level


IT-Symposium 2008 04.06.2008


Vulnerabilities on protocol level

Designed without security in mindProtocols work with highly dynamic port assignments


Example:Dynamic port assignmentsDynamic port assignments


IT-Symposium 2008 04.06.2008


Vulnerabilities on connection level

Nearly no encryption by defaultSRTP not used due to inter-vendor keymgmt incompatibilites


Vulnerabilities on gateway level

Designed/assembled/configured without security in mindUnsecure default configurationsSegregation of duties principle may be violated


IT-Symposium 2008 04.06.2008


Example:Components with “teething problems“Components with teething problems


Vulnerabilities on endpoint level

Unsecure default configurationsPoorly implemented (see Shawn Merdinger‘s research)Softphones may be prone to buffer overflowsIsolation of softphones‘ traffic may be difficult


IT-Symposium 2008 04.06.2008


Example:Softphones may be prone to buffer overflowsSoftphones may be prone to buffer overflows


Toolbox of Mitigating Controls

Mitigating Controls are taken from/named accordingly to C C it i t t t i lCommon Criteria to use exact terminology.

Only those relevant to VoIP were chosenOnly those relevant to VoIP were chosen.

In the course of the risk analysis itself they will be referencedIn the course of the risk analysis itself they will be referencedjust by their class name. This means some of the controls listed in this document, in that class, can/should be implemented to , , pmitigate the respective risk.


IT-Symposium 2008 04.06.2008


Toolbox of Mitigating Controls,based on Common Criteria v3 1 Part 2based on Common Criteria v3.1, Part 2

Class FAU: SECURITY AUDITClass FAU: SECURITY AUDITFAU_GEN "Security audit data generation“FAU_STG "Security audit event storage“FAU_SAR "Security audit review“FAU_SAA "Security audit analysis“

CLASS FCO: COMMUNICATIONFCO NRO "N di ti f i i “FCO_NRO "Non-repudiation of origin“FCO_NRR "Non-repudiation of receipt"



Class FCS: CRYPTOGRAPHIC SUPPORTFCS CKM "C t hi k t“FCS_CKM "Cryptographic key management“FCS_COP "Cryptographic operation"

CLASS FDP: USER DATA PROTECTIONFDP_ACC "Access control policy“FDP_ACF "Access control functions" FDP_DAU "Data authentication“FDP IFC/FDP IFF "Information flow control policy / functions”FDP_IFC/FDP_IFF Information flow control policy / functionsFDP_SDI "Stored data integrity“FDP UCT/FDP UIT "Inter-TSF user data confidentiality / _ _ yintegrity transfer protection“


IT-Symposium 2008 04.06.2008



Class FIA: IDENTIFICATION AND AUTHENTICATIONFIA AFL "A th ti ti f il "FIA_AFL "Authentication failures"FIA_UAU "User authentication" FIA UID "User identification"FIA_UID User identification

CLASS FMT: SECURITY MANAGEMENTFMT_MOF "Management of functions in TSF“FMT_MSA "Management of security attributes“FMT MTD "Management of TSF data“FMT_MTD Management of TSF dataFMT_REV "Revocation“FTM SMF "Specification of Management Functions“_ p gFMT_SAE "Security attribute expiration“FMT_SMR "Security management roles"



Class FPT: PROTECTION OF THE TSFClass FPT: PROTECTION OF THE TSFFPT_RPL "Replay detection“FPT_STM "Time stamps“FPT_TDC "Inter-TSF TSF data consistency“

CLASS FRU: RESOURCE UTILISATIONFRU_FLT "Fault tolerance“FRU PRS "Priority of service“FRU_PRS Priority of serviceFRU_RSA "Resource allocation"


IT-Symposium 2008 04.06.2008



Class FTA: TOE ACCESSClass FTA: TOE ACCESSFTA_MCS "Limitation on multiple concurrent sessions" FTA_TAB "TOE access banners“FTA_TAH "TOE access history“FTA_TSE "TOE session establishment“

CLASS FTP: TRUSTED PATH/CHANNELSFTP ITC "Inter TSF trusted channel"FTP_ITC Inter-TSF trusted channel


Risk Analysis

Protocol levelConnection levelGateway levelEndpoint level


IT-Symposium 2008 04.06.2008


RA, Methodology used

Numbers for likelihood and impact were chosen on a scale from one to five.Rating of impact is based on a mixture of several factors (breach of/loss ofRating of impact is based on a mixture of several factors (breach of/loss ofconfidentiality/integrity/availability, violation of regulations).The impact rating largely depends on individual/environment/objectives/ settings Your mileage might varysettings. Your mileage might vary...

Nevertheless some notes:- non-compliance nearly always leads to a “5“non compliance nearly always leads to a 5- loss of availability rarely gets a “5“(5 only used for “disaster“ cases, which are out of scope here)

- sometimes rating of impact depends on host count/scale concernedg p p

Assignment of numbers to respective threads is based on “VoIP security common body of knowledge“ and author‘s experience/research.common body of knowledge and author s experience/research.Here the risk is calculated by simple multiplication (see BS 7799-3, 5.7).


RA Protocol Level


Risk Mitigating ControlsConsequence(s)

TP1,Poor protocol

1 5Breach of con/int,

5 Class FCS,Class FDPPoor protocol

designBreach of con/int,Non-Compliance

Class FDP

TP2,I l t t

1 5C i f

5 Class FAU,Cl FDPImplementat.

leading to BOCompromise of

componentsClass FDP

TP3, 3 3 9 Class FDP,TP3,Bad firewall config

3 3Larger possible attack surface

9 Class FDP,Stateful firewalls/ALGs


IT-Symposium 2008 04.06.2008


RA Protocol Level, Notes

Since Oulu University Secure Programming Group research [1] on SIP and H 323 their common implementations can be considered lessSIP and H.323 their common implementations can be considered lessvulnerable.

Presently most major firewalls are able to cope with SIP, H.323 and RTP without huge problems but still additional proprietary ports( f ti t CM SBC) d d f tl(e.g. for connections to CM or SBC) needed frequently.


RA Connection Level



TC1,Eavesdrop. /

2 5Breach of conf.,

10 Class FCS,Class FDP,

Call Monitor. Non-Compliance NW-SegmentationTC2,Data

2 5Breach of conf

10 Class FCS,Class FDPData

ModificationBreach of conf.,Non-Compliance

Class FDP,NW-Segmentation

TC3, 3 4 12 Class FRU,DoS by attack Loss of service NW-Segmentation,

SLAsTC4 2 4 8 Class FRUTC4,DoS due to misconfig

2 4Loss of service

8 Class FRU,Class FMT,Operational procedur.


IT-Symposium 2008 04.06.2008


RA Connection Level, Notes

Most important tools to eavesdrop VoIP connections include:itvomit

wiresharkcain & abelcain & abeloreka


RA Gateway Level



TG1,System

3 5Breach of conf.,

15 Class FMT,Class FDP,

compromise Non-Compliance Hardening & OpSecTG2,DoS by attack

3 4Loss of service

12 Class FRU,Class FTADoS by attack Loss of service Class FTA

TG3, 2 4 8 Class FRU,DoS due to misconfig

Loss of service Class FMT,Operational Procedur.


IT-Symposium 2008 04.06.2008


RA Gateway Level, Notes

Special attention should be paid toSNMP- SNMP

- Default passwords (mgmt access, configured users)Apply usual hardening steps before going productive and (pen-) test!Apply usual hardening steps before going productive and (pen ) test!

Bad protocol implementations may have side effects on devices p p ypurportedly not running VoIP at all (see for example [3]).


RA Endpoint Level



TE1,System

2 4Breach of conf.,

8 Class FMT,Class FDP,

compromise Non-Compliance Hardening & OpSecTE2,DoS by attack

1 3Loss of service

3 Class FRU,Class FRADoS by attack Loss of service Class FRA

TE3, 3 5 15 Class FRU,Malwa. spread Loss of service,

BackdoorsClass FMT,Operational Procedur.

TE4 3 5 15 FAU SAA (IDS)TE4,Covert chann.

3 5Breach of con/int corporate level

15 FAU_SAA (IDS),Desktop OpSec“Do not use Skype!“


IT-Symposium 2008 04.06.2008


RA Endpoint Level, Notes

Special attention should be paid to- SNMP- SNMP- Open Ports/running services (e.g. Telnet)See presentations and advisories of Shawn Merdinger.

(Strong) Authentication is your friend here.

802.1x in the meantime available for some hardphones,check preferred vendor.

Remember trunking/DTP security problems when usingCisco “Voice VLANs“...

Did I already mention? ;-) Do not run Skype!Why? See [2] and [4].


Questions & Answers


IT-Symposium 2008 04.06.2008


References

[1] Oulu University Secure Programming Group:http://www ee oulu fi/research/ouspg/http://www.ee.oulu.fi/research/ouspg/

[2] Hackers call on Skype to spread Trojan:http://www.theregister.co.uk/2006/12/20/skype_trojan/

[3] Cisco Security Advisory: Vulnerabilities in H.323 Message Processing:http://www.cisco.com/en/US/products/products_security_advisory09186a00801ea156.shtml

[4] Biondi/Desclaux: Silver Needle in the Skype:http://www.secdev.org/conf/skype_BHEU06.handout.pdf

NIST Special Publication "Security Considerations for Voice Over IP Systems“:NIST Special Publication Security Considerations for Voice Over IP Systems :http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdfNIST IPTel/VoIP Security Technical Implementation Guide:http://csrc.nist.gov/pcig/STIGs/VoIP-STIG-V2R2.pdfNIST IPTel/VoIP Checklist:http://csrc.nist.gov/pcig/CHECKLISTS/voip-checklist-v2r2-2-20060519.pdf


Voice-over-IP Security 70

Beispielkonfiguration Cisco

!

interface FastEthernet0/1

switchport mode dynamic desirable

switchport voice vlan 200

mls qos trust cos

auto qos voip trust

priority-queue out

spanning-tree portfast

!

IT-Symposium 2008 04.06.2008



Die Attacke

� 1. Kabel vom IP Telefon ziehen und mit Laptop verbinden

� 2. Voice VLAN ID sniffen� CDP Pakete mitlesen und Voice VLAN ID extrahieren

� Wireshark� tshark

� 3. Voice VLAN Interface auf Laptop erzeugen� 802.1q Implementierung für Linux

� Voice VLAN Interface erstellen� Per DHCP IP Adresse auf dem VLAN Interface beziehen


VoIP Hopper – Das Tool

� VoIP Hop Validierungs-Tool [7]

� Automatische: � Suche nach Voice VLAN ID� Erstellung des Subinterfaces� IP-Adressen-Zuweisung per DHCP

� Hilft bei der Überprüfung der Konfiguration

IT-Symposium 2008 04.06.2008



VoIP Hopper - Tool


Nochmals der Hinweis

� (Aushandelbare) Trunk-Ports stellen ein gravierendes L2-Sicherheitsproblem dar� Ggf. allowed-vlans einschränken

IT-Symposium 2008 04.06.2008



Angriffe gegen Devices/Zentralkomponenten

� Eines der grössten VoIP-Risiken� Siehe Risiko-Analyse

� Viele Devices haben Lawful Interception Fähigkeiten� Athens Affair (siehe SS7 Präsentation)� SNMP ...

� Es gelten die „üblichen Sicherheits-Regeln“ zum Schutz von NW-Devices...


Cisco Call Manager Web-Interface

IT-Symposium 2008 04.06.2008



SNMP, Some of those “private candidates“

� xxx.yyy.192.204,some.name.here.com.country

"Cisco UBR 10012","Cisco Internetwork Operating System Software IOS (tm) 10000 Software (UBR10K-K8P6U2-M), Version 12.3(17b)BC3, RELEASE SOFTWARE (fc1) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2006 by cisco Systems, Inc. Compiled Fri 27-Oc“


SNMP private, Operator Space

IT-Symposium 2008 04.06.2008



Cisco uBR 10000 – Actions!

� One could easily get config file � and a nice little surprise can be found...

� Ever heard of CALEA?� Cisco uBR 10000 supports a special MIB called

CISCO-TAP2-MIB� What do you think can be done with this lovely one?� You got it... ;-)

� Subvert/disable CALEA at given times� Redirect traffic? => DoS?


Cisco uBR 10000 & CALEA

CISCO-TAP2-MIB DEFINITIONS ::= BEGIN-- From file: "CISCO-TAP2-MIB.my"{...]cTap2MediationDestAddress OBJECT-TYPE

SYNTAX InetAddress-- Rsyntax OCTET STRING(SIZE(0..255))

ACCESS read-writeSTATUS mandatoryDESCRIPTION

"The IP Address of the Mediation Device's network interface

to which to direct intercepted traffic."

::= { cTap2MediationEntry 3 }

IT-Symposium 2008 04.06.2008



Zusammenfassung

� Beim Einsatz von VoIP können Sicherheits-Probleme auftreten� Zur realistischen Einschätzung ist eine Risiko-Analyse

notwendig.

� Segmentierung des VoIP-Verkehrs ist nicht immer notwendig und kann sogar zu neuen Problemen führen.

� Der Sicherheit von zentralisierten VoIP-Devices kommt grosse Bedeutung zu.


Ceterum censeo

Für „fortgeschrittene Leser“

IT-Symposium 2008 04.06.2008



Fragen?


Danke für Ihre Aufmerksamkeit!

IT-Symposium 2008 04.06.2008



Quellen

[1] Oulu University Secure Programming Group:http://www.ee.oulu.fi/research/ouspg/

[2] vomit:http://vomit.xtdnet.nl/

[3] Ofir Arkin: Cracking SIP:

http://www.sys-security.com/archive/conferences/csw/core02/CSW_Final.zip

[4] Ofir Arkin: The Trivial Cisco IP Phones Compromise:http://www.sys-security.com/archive/papers/The_Trivial_Cisco_IP_Phones_Compromise.pdf

[5] Enterprise IP Telephony Securing Voice Today:http://pacug.peer-tech.com/download/CCM%20Security.ppt

� http://www.securityfocus.com/bid � Shmoocon-Präsentation v. Shawn Merdinger


Weitere Links

� NIST Special Publication "Security Considerations for Voice Over IP Systems":� http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf

� NIST IPTel/VoIP Security Technical Implementation Guide� http://csrc.nist.gov/pcig/STIGs/VoIP-STIG-V2R2.pdf

� NIST IPTel/VoIP Checklist� http://csrc.nist.gov/pcig/CHECKLISTS/voip-checklist-v2r2-2-20060519.pdf

� BSI Studie zur Sicherheit von Voice over Internet Protocol� http://downloads.bsi-fuer-buerger.de/literat/studien/VoIP/voipsec.pdf

� Kapitel 6 aus ISBN 1-58705-139-7 (Salvatore Collora: Cisco CallManager Best Practices)

� Cisco WP "Security in SIP-Based Networks"� www.cisco.com/en/US/tech/tk652/tk701/technologies_white_paper09186a00800ae41c.shtml � Asterisk Encryption: http://www.voip-info.org/wiki/view/Asterisk+encryption � http://www.voipsa.org/Activities/VOIPSA_Threat_Taxonomy_0.1.pdf

IT-Symposium 2008 04.06.2008


Documents

Developing Strategies to Protect SS7 from Manipulation and ... filefor the IP world & SIGTRAN Not surprisingly, in the carriers‘ endeavour to consolidate everything-over-IP SS7 t