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].


GoodSAM App – CSRF/Stored XSS Chain Full Disclosure

I’ve been a user of the mobile/web application named “GoodSAM App” which is an application where the Ambulance service in London or the East Midlands can dispatch “Responders” who are trained in Basic Life Support (BLS) and can be dispatched to cardiac arrests or other priority calls and users at emergencies can also request a “Responder”.  Now this application is absolutely brilliant in the nature of what it does and I fully support them.

Despite this however, I did find two vulnerabilities within the application that may have been overlooked. Specifically Cross Site Request Forgery (CSRF) within the “Account Profile” page, along with Cross Site Scripting (XSS) within the same page, the account profile page being loaded upon login.

Now typically, CSRF and XSS issues on their own are not that much of a critical vulnerability in the grand scheme of things, however in this instance it was possible to chain both CSRF/Stored XSS vulnerabilities to set the XSS payload within the account profile fields and then steal the user cookie every time they login or view the page.

Finally, as the GoodSAM Data Protection section said they take data protection seriously, I thought I would not have any problems getting these vulnerabilities resolved under responsible disclosure, however I was wrong on this occasion and have had to release the information. (See Disclosure Issues section).

“We take your data protection extremely seriously. We are registered with the Information Commissioners Office (no: ZA094052) and our technology team take the security of our data and servers very seriously. “


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).