EE 4GEE HH70 Router Vulnerability Disclosure

After finding vulnerabilities in the 4GEE Mobile WiFi Router last year, I thought I would give my brand new EE home broadband router a run for it’s money and it seems like last time, it’s vulnerable to another attack vector, this time being hard-coded credentials for SSH root access, which luckily is only available via the LAN.

This would enable any user on the LAN to gain access to the router using these hard-coded credentials.

Update: 26/10/2018 – EE have released patch that fixes the issue. Users are recommended to follow the EE router upgrade process via the web UI.

Hardware Version/Model: 4GEE Router HH70VB-2BE8GB3 (HH70VB)
Vulnerable Software Version: HH70_E1_02.00_19
Patched Software Version: HH70_E1_02.00_21
Vulnerability CVE(s): CVE-2018-10532
Product URL:


EE 4GEE Mobile WiFi Router – Multiple Security Vulnerabilities Writeup

After performing security testing on the 4GEE Mobile WiFi router it was discovered to be vulnerable to several security vulnerabilities. These vulnerabilities in combination make it possible for an attacker to remotely exploit the device, which can be achieved through having a user view a crafted texted message that was sent to him.

Other attacks are also possible by misleading and/or tricking users into executing code or clicking crafted URLs to trigger multiple functions such as device reset, device reboot, device restore (malicious config), sending SMS messages or stealing device configuration information, SMS messages and any other information on the device that a user may have access to and without authentication.

Additionally, multiple JSONP information disclosures were discovered, which display the full username and password of the administrative user while unauthenticated and allow access to multiple privileged functions such as device reset, device reboot and device configuration download/upload and SMS messages stored on the device.

I’d also like to note, the responsiveness and prompt vulnerability resolution from EE, as I was expecting this issue to get ignored or swept under the carpet, like most IOT/Router vulnerabilities, however in this case constant communication was kept throughout the process and the issues resolved.

Hardware Version/Model: 4GEE WiFi MBB (EE60VB-2AE8G83).
Vulnerable Software Version: EE60_00_05.00_25.
Patched Software Version: EE60_00_05.00_31.
Vulnerability CVE(s): CVE-2017-14267, CVE-2017-14268, CVE-2017-14269.
Proof of Concept Code:


Azure Cloud Root Keys (Insecure Storage) – Responsible Disclosure

Back in February I found an Android application which is used by the emergency services, that had exposed Azure API keys within the application leading to potential compromise of sensitive incident reports, attachments, and infrastructure server “.vhd” files with the access level to spin up new instances or delete them. I immediately reported this to the application developer and it’s respective organisation under responsible disclosure, which resulted in an instant and prompt response, which I give huge kudos for.

OWASP Defines this class of vulnerability as “Insecure Data Storage”:

Insecure data storage vulnerabilities occur when development teams assume that users or malware will not have access to a mobile device’s filesystem and subsequent sensitive information in data-stores on the device. Filesystems are easily accessible. Organizations should expect a malicious user or malware to inspect sensitive data stores. Rooting or jailbreaking a mobile device circumvents any encryption protections. When data is not protected properly, specialized tools are all that is needed to view application data [1].


Major League Baseball Reflected XSS

Recently I have been looking for vulnerabilities such as XSS/CSRF within online applications and came across an XSS vulnerability within the Major League Basketball (MLB) website, which in question was vulnerable to reflected XSS. I did attempt responsible disclosure through Open Bug Bounty [3] and attempted contact via Twitter also, with no response returned and hence full disclosure.

In particular, the website was vulnerable within the “FORM_CODE” parameter with the payload of “–!><Svg/Onload=confirm(‘ OPENBUGBOUNTY’)>” being used to exploit the reflected XSS vulnerability. (See below).