Southern Water provide utility drinking water and waste management services to around 4.7 million customers in the South of England, covering as far west as Bournemouth, along the coast to Dover and Ramsgate, and up to Dartford and Haslemere.
Several years ago, they created a section on their website that allows customers to manage their account — view bills, make payments, update details, etc.
Unfortunately, a vulnerability in this management area allowed any logged in customer to view bills and documents from other customers, as well as retrieve authentication tokens which allowed for direct API access to their internal billing SharePoint site.
A partial fix was implemented around 34 hours after the receipt of the report, and it is no longer possible to access any customer data using the methods described.
Any actual data accessed during the discovery and reporting of the issue has been securely and completely destroyed, and was never shared with any other party. No copies of any personal or customer data exist on any system, and any screenshots included have been heavily redacted.
The following is a running commentary on the background of the issue, how it was discovered and reported, the kind of information that was available and some discussion on possible additional threats that an attacker might have leveraged.
Once logged in to the account management system, Southern Water provide a page for downloading any correspondence they have sent you, which aren’t bills — in this case you can see a couple of Direct Debit confirmations on my list.
When the correspondence is viewed, it is opened as a PDF document in a new tab in my browser. From here, we can see the document looks to be correctly addressed to me and contains my details.. but what about that URL bar — what is it hiding..?
It seems that for whatever reason, Southern Water decided to include the internal SharePoint link to the document as a parameter in the customer-visible URL.
Could it be that this page is really a proxy to their internal SharePoint system? Let’s replace the correspondence URL with a SharePoint application URL that might return us some interesting information…
Oh. Ouch. It appears the call to the SharePoint application page returned us some links to other customer’s correspondence.
You should never allow users to make unknown authenticated calls against internal systems — See OWASP for details on Server Side Request Forgery.
As a final barrier of defence, there should be some kind of authorisation or check which prevents us from being able to see these other customer’s documents, right..?
This doesn’t look good.
I was able to retrieve correspondence for someone who wasn’t me.
From this document, I was able to see: full name, address, customer account number, payment reference number, bill and payment dates, account balance, payment amount, bill amount, meter details and meter readings.
If we assume that documents such as my own direct debit confirmations are also visible via this means, limited banking information is therefore also exposed.
With this trove of information, a bad actor could easily set up a targeted phishing campaign to pretend to be Southern Water and get customers to part with their money. It should also be noted that a utility bill is sometimes also needed for credit applications or proving identity — these documents could quite easily do the trick.
The issue could have been easily mitigated by replacing the internal URLs in the parameter with a unique identifier, and adding a lookup table in the database. This would also allow for strict authorization enforcement to ensure that customers can only see documents that belong to them.
But wait, there’s more..!
Within the SharePoint application page returned earlier, there is another piece of interesting information — a JWT access token to an undocumented Microsoft SharePoint API.
I’m not a SharePoint expert, and I’ve tried to find more information about this API, however, it appears to be mainly undocumented and therefore information about the endpoints and capabilities are limited.
If there were an endpoint that allowed for searching, for example, there is a possibility that a more targeted vulnerability could exist, where correspondence can be actively searched based on a customer’s name or postal code.
For now, we can check a known endpoint that lists SharePoint activity. From the response we get back, we can see even more customer correspondence URLs are visible.
Just as in the first part of this issue, these correspondence URL’s can also be passed in to the parameter, and the contents of the PDF are downloaded again without any authorisation or checks to see if we are allowed to access it.
As soon as I became aware of the extent of the issue, I attempted to report it to Southern Water. I sent a tweet to their @SouthernWater account on Sunday 23rd August 2020, asking for a security contact at their company.
Since then, a long back-and-forth ensued inside a Twitter direct message thread, where I continually asked for a direct contact for the security team. I also provided a walkthrough covering the steps in this article.
I was given no indication that the company was taking this issue seriously, or would be resolving it in a timely fashion given the nature of the information exposed.
Subsequently, after Southern Water were reached through other means, the priority appeared to escalate drastically, and the issue was resolved promptly.
It is extremely important that companies understand when a security issue is being reported, and have all the necessary procedures in place to handle it quickly and efficiently — a great way to inform security researchers about your procedures is to have a security.txt file. It also helps to offer a two-way communication channel so that details are fully understood, and can be clarified quickly avoiding unncessary misunderstandings.
Around 17:40 GMT on 25th August 2020, it appeared that a partial fix was being implemented, removing the attack vector.
At that time, the endpoint for returning correspondence lists was returning a HTTP 500 Internal Server Error.
Additionally, attempting to fetch a correspondence via the direct URL resulted in the request timing out.
Later in the evening, the list of correspondence began to display again, however clicking the View Document button now resulted in a “Site Under Maintenance” page being displayed in place of the letter.
UPDATE: 26th August 2020, 10:50 GMT
A comment was provided by Southern Water:
We take the protection of customer data very seriously
UPDATE: 26th August 2020, 16:40 GMT
Additional clarification was added that any data downloaded as part of this research and reporting was securely deleted and destroyed, and no personal or customer data has been stored or disseminated.
- 23rd August 2020, 22:10 GMT — Posted message on Twitter asking for Southern Water to DM a security contact e-mail address.
- 24th August 2020, 07:36 to 12:01 GMT — Twitter DM thread back-and-forth, asking for contact details of their security team and sending initial details of the problem.
- 24th August 2020, 12:05 GMT — No contact details provided — requested security contact reach out through provided e-mail address.
- 24th August 2020, 14:00 GMT — First draft of blog post, unlisted.
- 24th August 2020, 19:49 GMT — Generic “we have passed the information on” message received.
- 25th August 2020, 17:40 GMT — Partial fix appears implemented.
- 26th August 2020, 07:30 GMT —Public disclosure, blog post published.