2. Disclaimer
• I am a programmer, not a security expert
• This has been done using best practises for
responsible disclosure
• POC code will not be disclosed (but can be easily
written in 30~ mins)
3. how would you feel if..
• You found a vulnerability that allows malicious user to
extract user creds remotely with no authentication
• Your supplier was shipping you vuln devices by default
• Your provider did not fix the problem
• The vendor did not fix the problem entirely
• All your customers were affected
• You were liable for any resulting toll-fraud
• You had to explain this to your customers after
• This is the BS I had to deal with in June 2012
4. Companies affected
• Yealink
Disclosed June 2012, patched Aug 2012, problem still exists
• Snom (disclosed today)
Disclosed today
• ****.co.uk
Disclosed 2012, problem still exists
• *****.co.uk
Not disclosed
• Many, many others
including those with QSA accreditation from ITSPA
5. Known attack vectors
• 1) Redirection service at root authority (what is it?)
http://www.888voip.com/rps-redirection-and-provisioning-service-by-yealink/
• 2) Redirection service at reseller
SIP providers, hw wholesalers
• 3) Any external facing provisioning system
HTTP, TFTP etc
6. Yealink
• V71 firmware
– RPS not enabled by default
– aes encryption optional for v71
– Still vuln if provider does not implement properly
• V70 firmware
– RPS enabled by default
– No AES encryption required
– Legacy services have not been disabled due to this
7. Yealink
• V71 fw cut using binwalk and yaffs2utils
• V70 fw cut using binwalk and unsquashfs
$ cat ./factory/Setting/autop.cfg
[ autoprovision ]
server_address = ?http://prov.yealink.co.uk/1/ap/
$ grep -R "server_address" .
./factory/Setting/autop_code.cfg:server_address = ?http://prov.yealink.co.uk/1/ap
./factory/Setting/autop_code.cfg:server_address = ?http://yealink.********
$ curl http://prov.yealink.co.uk/1/ap/0015651738ba.cfg
[ autoprovision ]
***
Jun 29 15:41:01 ap: http_client.c(712): UserAgent is yealink SIP-T20P 1.2.3.4 00:11:22:33:44:5f
Jun 29 15:41:01 ap: http_client.c(1292): query header: GET /tftp/00112233445f.cfg
HTTP/1.0^M Host: 1.2.3.4^M User-Agent: yealink SIP-T20P 1.2.3.4 00:11:22:33:44:5f^M
Accept: */*^M Connection: Keep-Alive^M ^M
8. Yealink
•
•
•
•
MAC range: 001565 XIAMEN YEALINK
16^3 (16,581,375 MACs).
Single threaded, single IP scan, 30 reqs/sec
Can easily write a scanner in ~30 mins
[2013-10-22 12:56:32,463] [scan-yealink-rps.py:131] HIT 001565****** - endpoint is http://*************/***/001565******.cfg
[2013-10-22 12:56:32,627] [scan-yealink-rps.py:119] MISS on 001565******
[2013-10-22 12:56:32,792] [scan-yealink-rps.py:119] MISS on 001565******
10. Snom
• Requires model number in MAC URL.
• This increases scan time right??
• NOPE.
http://wiki.snom.com/Settings/mac
• Could easily write a scanner in 30~ mins
SNIPPET:
Snom300 ---- 00041325XXXX, 00041328XXXX, 0004132DXXXX, 0004132FXXXX, 00041334XXXX, 0004133687F000041336FFFF, 00041337XXXX, 0004133BXXXX, 00041350XXXX
snom320 ---- 00041324XXXX, 00041327XXXX, 0004132CXXXX, 00041331XXXX, 00041335XXXX, 00041338XXXX, 00041351XXXX
[2013-10-22 14:47:50,047] [scan-snom-aps.py:22] Scanning MAC range 00-04-13-25-XX-XX to 00-04-13-25-XX-XX (total 7)
[2013-10-22 14:47:50,276] [scan-snom-aps.py:54] MISS on 00041325XXXX
[2013-10-22 14:47:50,276] [scan-snom-aps.py:66] HIT 00041325XXXX - endpoint is http://*******/**/***.php?mac=00041325XXXX
11. Generic auto prov servers
•
•
•
•
Majority of auto prov servers do not have brute protection
Majority of sys admins don’t check auto prov server logs
Significant number of well known UK providers are vuln to this
Lol 3cx
• Almost every handset is vulnerable to this (encryption is not
always enforced by default)
• Almost every provisioning server is vulnerable to this
• At least one big UK company is exposing thousands of details
because of this
12. Dirty tricks
•
•
•
•
Scanner speed can be significantly increased using coroutines
Request throughput can be increased using proxies from public lists
Easily reach 1000 requests/sec using 200 lines of python code
The majority of servers would crash and burn if URL is hitting
dynamic code (PHP) instead of plain text
• I have not implemented any of these, as this code is for proof of
concept, not a hit-and-run tool to be used maliciously
13. Immediate protections
(for non encrypted configs)
• Implement protections using L7 rules (nginx reverse prox, ZXTM etc)
• Rate limit based on MAC+IP combo (default 10 MACs/IP/24h)
• Enforce user agent checks/validation (not 100%, but helps protect
against chancers)
• Track IPs which access provisioning info, check for fraud patterns
(access from different countries etc)
• Automatically block IP if any protections are triggered
• Remove/modify on a case-by-case basis
• This only slows down brute force attacks, it is does NOT prevent
them, nor does it protect against targeted attacks
• Be smart
14. Immediate protections
(for encrypted configs)
• Haven’t had chance to review these yet
• Snom/Yealink will be chiming in with their two cents on
protections
15. Out of the factory protection
• Vendors are struggling to make phones secure to auto
provisioning out of the factory, relies on providers doing things
correctly.
• Could you not enforce request validation using a one-time-use
key generated from a unique string embedded into that
phone? (perhaps serial no?). This combined with encryption
gives two layers of security – still not perfect is the SN is leaked
• Got ideas? Share them! The only way this will change is if we all
do our bit to help
16. how you can help
• Many other vendors are vulnerable, I don’t have enough time
to check them all
• Got a phone that supports zero touch/auto prov? Give this a
try!
• Simple pcap/syslog analysis will usually give up secrets
• FW cutting only needed if you want to dig a bit deeper
• Most providers/vendors are not implementing encrypted
config by default
• Yealink have partially fixed by adding encrypted config (but it’s
not enforced!)
• Test as many different makes/firmware as possible!!!!
17. This is only the beginning
• Auto provisioning flaws are only the tip of
the ice berg
• Poke around, you will be shocked at what
you find
18. its not all doom and gloom
• Discovered FS after becoming fed up with
incompetent providers
• Met some amazing people in this community
• Learnt a lot of new skills
• Cudatel isn't vulnerable since they ship
firmwares with RPS off by default
19. Acknowledgements
• William King aka quentusrex from CudaTel
Helped with finding ways to protect customers, much appreciated!
• Ken Rice aka SwK from FreeSWITCH
Assistance with broadcasting and arranging this conference, thank you!
• FreeSWITCH community
• Anyone who’s URL I have linked to
• People who took time to write up on fw dissection, it saved me
literally days of work
20. Worried about this?
there are freeswitch consultants who can help setup secure
remote provisioning
Reach out to
consulting@freeswitch.org
21. Hint doc names
A31008-M2212-R910-3-7643_en_Internat.pdf
A31008-M2212-R910-3-7643_en_Internat_2.pdf
A31008-M2212-R910-3-7643_en_Internat_3.pdf
A31008-M2212-R910-5-7643.pdf
Auto Provision Manual version 2.0.4.pdf
Auto Provision Manual version 2.0.4_2.pdf
Category_HowTo_XMLRPC Redirection - Snom User Wiki.pdf
Changelog-YUK-V60FW-03012012.pdf
SiemensC450IPConfiguration.pdf
Terms_and_Conditions_for_use_of_snom_redirection_services.pdf
uts.pdf
V70UpgradingManual-21540749528.pdf
Voip_einrichten_eng.pdf
Yealink Auto Provisioning User Guide.pdf
Yealink SIP Phone Release Note of Version 71.pdf
YealinkConfigurationConversionToolUserGuide-21535047441.pdf
YealinkRedirectionandProvisioningService(RPS)UserManualV10ENG-04371557705.pdf
YealinkXMLAPIforRPS-V1.3-ENG (2).pdf
YealinkXMLAPIforRPS-V1.3-ENG.pdf