3rd party providers are difficult to secure, even for spooks
Over the years, I've collected data on the general health of various government encryption certificates on the internet. Although most have improved over time, they’re not 100% up-to-date and secured. Understandably, nothing is 100% risk-free or secure. However, there‘s a perception; not based in reality, that governments would be better at security than us mere mortals. I believed in Santa until I was 5, that didn't make him real.
Information is sanitised
The target information is sanitised. For purposes of this article, we will use GCHQ.3rdPartyProvider.com in place of the real 3rd party provider.
I attempted on numerous occasions to responsibly report these and other issues to GCHQ via the NCSC-UK. However, after pleading in the news media and privately speaking with a UK Ministry The NCSC-UK reached out promptly after the minister lent a hand. There was one major problem, the information was sensitive and must be secured when sending over email. Most CERT type organisations use PGP or similar methods to encrypt email communications. The only PGP key the NCSC-UK sent me, to secure the information. A two-year-old expired PGP key from a different, defunct organisation. The previous UK CERT’s PGP key. Leaving me unable to disclose to GCHQ responsibly.
New UK Government 3rd party requirements for cyber security
Like most government agencies, GCHQ uses various third parties for some technology services. Recently, the UK started a new scheme to help bring up necessary levels of cyber security, especially with companies which do business with the UK government. The scheme, Cyber Essentials, is required for central UK government contracts advertised after 1 October 2014. The required program upper levels, entail a technology review, audit and penetration/vulnerability test. Not sure why or how this particular technology service provider wasn't required to be part of the Cyber Essentials scheme. However, it’s a excellent example why to audit 3rd party services.
One of GCHQ’s third part technology services provider, has no Cyber Essentials certification posted. 3rdPartyProvider.com provides services to the UK government; as well as, 22,000 UK businesses.
GCHQ is listening but not encrypting very well
The GCHQ.3rdPartyProvider.com SSL certificate provided by the 3rd party, was graded an F, fail. Due to using SSL version 2, incomplete certificate chains and weak encryption elements.
In addition to a weak certificate, The service provider appeared to use the same * wildcard HTTPS and SMTPS encryption certificate for all it’s IP addresses. Using the SSL certificate serial in Shodan, I was able to quickly discover 24 instances using the same exact serial number on 24 different IP addresses. The same encryption certificate appeared in use across the entire third party provider network. The * wildcard could have exposed all other businesses to GCHQ listening and GCHQ communications to all the other 22,000 businesses and IP addresses. The same supposedly private key was instead in use with everyone. Not very private….
“A “wildcard certificate” (* wildcard) is a certificate which contains, as possible server name, a name which contains a “
*" character. Details are in RFC 2818, section 3.1. The bottom-line: when the server certificate contains
*.example.com, it will be accepted by clients as a valid certificate for any server whose apparent name matches that name.” StackExchange
Using three web based tools, Shodan.io, Censys.io and Qualys SSL labs. The results were the same, the GCHQ 3rd party was using the same exact * wildcard encryption certificate on up to 98 different internet facing IP addresses.
Major issues with the encyrtpion with GCHQ’s 3rd party:
- Difficult to near impossible to report responsibly to GCHQ’s NCSC-UK, the UK’s CERT replacement.
- 3rd party provider used the same weak certificate for HTTPS web and email services. Giving customers a false sense of security and possibly exposing business customer and GCHQ sensitive data to each other.
- Why was GCHQ using a 3rd party encryption certificate? This implies trust between a 3rd party and an intelligence agency.
- Cyber Essentials, where? Was the requirement waived because the technology services contract wasn't a general UK government contract? Did the contract fall through the cracks? Was the * wildcard used on purpose? Questions remain.
- For an organisation which deals directly with encryption. The 3rd party utilised weak encryption algorithms and elements such as SHA-1 with RSA, RC4 , with all IPs. TLS_RSA_WITH_RC4_128_SHA (
0x5) TLS_ECDHE_RSA_WITH_RC4_128_SHA (
Let’s be bluntly honest: Third party suppliers and technology providers are some of the most difficult things to secure. This sanitised example shows even the big time professionals are challenged. There is no magic network cable to waive over all your cyber stuff and, viola, magically secured. I was not expecting to discover an encryption * wildcard in use with a third party of an intelligence organisation. The issues were found using web-based search and certificate checking tools. No “hacking”, unauthorised access or decryption took place. If I found them with ease, super secret spies from other countries could too. Lastly, I wish to state categorically: I do not own a sports bag, just in case….. :0
This post is a case study from my upcoming book: OSINT Through the Looking Glass. The book is based on open source intelligence gathering tools and techniques using various intelligence and government agencies as targets. This OSINT example involves no illegal activity (per Dutch laws). No authentication, or breaking of encryption took place.
Leave a clap (or 50+) and a please feel free to comment.