Incorrect Access Control in the Account Access / Password Reset Link in Enterprise before 2019-04-23 allows Unauthorized Attackers to READ/WRITE Customer or Administrator data via a persistent HTTP GET Request Hash Link Replay, as demonstrated by a login-link from the browser history

The Vulnerability

When any management portal administrator/user or booking/scheduling service provider client account is created, a non-expiring MD5 hash value is generated and associated with that account in perpetuity. The purpose of the hash is to allow a 1-click login and password reset function for administrators, users, & clients of both the services booking/scheduling website and the services management portal.

The login-link URL contains the sub-domain for a particular booking site hosted on and a token in the form an MD5 hash value that appears to be created the first time it is used and stored in the database for the duration of the life of the account. This hash represents a fully authenticated session for the associated user, and anyone who has knowledge of the hash has the ability to perpetually re-authenticate as that user regardless of any password, username, email address changes made to the details of that account.

Because the hash does not expire and it is passed as part of the URL in a GET request, this means it will be recorded in both browser history logs, and business web monitoring service logs. So if a user accesses their account using a login-link via a shared system and even makes sure to log out and clear their session cookies afterwards, the full URL path is still recorded in the browser history and anyone with access to the browser can access and use it to access the account associated with that login-link.

Clients of the booking service website

When the “Client Login” custom feature is enabled on a site, both the “send login link” and “password reset”” features send a hyper-link via email to the client’s registered email account when activated. For client accounts hyper-link is in the form of:


User accounts used for accessing the management portal

Management portal accounts have a hyper-link in the form of:


on your post. This theme adds a dark background with a white panel to show your content.

Observations & Recommendations

Tokens used for password reset and account recovery should be randomly generated and be single use only and should expire as soon as either one of the following conditions are met:

  • After a specified short amount of time (e.g. 5 mins)
  • After they are used.

Account owners should be sent a notification email upon creation and use of a login-link and also when any changes are made to their user details or account information. (e.g change of email address or phone number).

Due to time limitations, I have not fully carried out entropy testing or reverse engineering of the MD5 generation algorithm in this case. However, if a deterministic dataset (e.g a combination of account details + time or + static salt value) is being used to generate the MD5 hash values this leaves the system fully open to remote compromise of accounts and services hosted on the platform because this approach is open to reverse engineering and “login-link MD5 Hash prediction attacks” resistant to account lockout due to the authentication system design.

Because have implemented user data access and handling features to enable compliance with the European General Data Protection Regulation (GDPR), if service providers enable the feature on their site, this additionally risks detailed and complete repositories of user data becoming accessible to attackers. This is because, anyone with a valid login-link for a client account is able to reconfigure the email address for that account, get an access code via their own email, download a full copy of the account owners Personal Data Report, then change the email back to the original without the account owner being made aware. This scenario is demonstrated below and would lead to a full breach of CONFIDENTIALITY,INTEGRITY and ACCESSIBILITY of client account data.

For security reasons it is becoming common practice within secured business networks for web traffic to be monitored, and for GET requests originating from within their networks to be logged. A typical sample of a logged GET request will contain the full URL path. As you can see in the demonstration using Nginx Proxy access logs, the login-link values would also be logged in such a situation.

Exploit Examples

Here I will demonstrate how an attacker that finds a login-link in the history of the browser they have shared access to can lead to full loss of CONFIDENTIALITY,INTEGRITY and ACCESSIBILITY of the data associated with account the login-link is associated with.

Step 1

Starting without a user session, we can open the history search sidebar and search for “simplybook hash” to get a list of all the login-link” URLs saved in the browser history.

[Image Error!]

Step 2

Next, by opening one of them we are instantly granted access to the associated user account. Even though the link has been used previously, the user logged out, and no session state was saved in the browser.

[Image Error!]

Step 3

Now an attacker is able to change the account email address to one that they control.

[Image Error!]

Step 4

Then they can safely click to read the Personal Data Report of the owner of the account and intercept the temporary access code without the data owner being notified.

[Image Error!]

Step 5

The attacker can now export all data ever generated by or on behalf of that associated account identity. The Data can include Financial Transaction Data, Medical Data, SMS History, Email History, Social Media Authentication Data

[Image Error!]

The same kind of attack is also possible for any management portal accounts that do not have 2FA enabled (disabled by default) and would lead to an even more devastating attack if combined with the Management Portal Privilege Escalation Exploit demonstrated on another post.

As you can see below. The same situation is true for a Admin account login-link where it can be harvested from an old entry in browser history. It’s hardly worth showing, but here you go…

Step 1

Search history for a link used by management accounts.

[Image Error!]

Step 2

Click Link… Instant Admin with access to the whole customer database, credit card payment api keys/credentials, web services management etc…

[Image Error!]

Vendor Response

(covers CVE-2019-11488 & CVE-2019-11489)
13-April-2019: Vendor is first sent the details of the vulnerabilities.
23-April-2019: Notified of fix and bounty award by the vendor.


Thank you.

As a reward for accepted vulnerabilities we will pay you 600USD, since we consider them as average seriousness:

(1) with admin access issue, the attacker, employee of same company as he would already need access, can only affect the system internally (not cross-system) and

(2) with hash issue the attacker needs to have access to user’s browser data.

Obviously both issues that should absolutely not be there, and have been fixed already, and we are thankful for you pointing them out to us.

. . .

Additionally we will give you 2 years of premium access to our system.

Best regards, Elina - Security Manager

Overall it was a positive experience communicating with the team, and I was glad to see the devs work to apply a fix within 10 days.

Thanks for reading,
Please Comment Below.

The CybrGrade UK Team
Image Error!