Responsible Disclosure and Timeframe for Fix

GreeBo wrote: »

whats the impact to real people if the service has to be shut down until fixed?

They have to edit what is returned in the JSON to not include private data. Two-second fix, literally. The information returned isn't fundamental to customer's use of service, so shutting down endpoint for repair would have little effect.

It's a big national company.

I'm bloody well sick of this, here's the full disclosure.

2nd July 2014

I wanted to know where Eircom's eFibre order page was getting its details on maximum line speeds from. So seeing as it was all ajax-ey I took a look at the Chrome developer network tab.



There was a ton of private info that could be returned based on just a landline, including information on landlines not listed in the phonebook. Here's a redacted sample of it for my landline number, concerning details bolded:

https://[REDACTED]/[LANDLINENUMBER]


<?xml version="1.0"?>
<search_result xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
[B]<ARD_ID>*****</ARD_ID>
<UNIT_NO/>
<UNIT_NAME/>
<BUILDING_NO>*</BUILDING_NO>
<BUILDING_NAME/>
<STREET_NAME_TOWN>********* *******</STREET_NAME_TOWN>
<POSTAL_DIST_NAME>*******</POSTAL_DIST_NAME>
<COUNTY_NAME>**********</COUNTY_NAME>[/B]
<SITE_CODE>***</SITE_CODE>
<STD_CODE>**</STD_CODE>
<TELE_NUMBER>******</TELE_NUMBER>
</search_result>


https://[REDACTED]/[ARD_ID]

<?xml version="1.0"?>
<search_result xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
<ARD_ID>*****</ARD_ID>
<UNIT_NO/>
<UNIT_NAME/>
<BUILDING_NO>*</BUILDING_NO>
<BUILDING_NAME/>
<LOCATION>********</LOCATION>
<POSTAL_DISTRICT>********</POSTAL_DISTRICT>
<COUNTY>*******</COUNTY>
<CAB_RFO_DATE/>
<MAX_HSI>**M_**M_R</MAX_HSI>
<MAX_NRA>**M_**M_FR</MAX_NRA>
<FIBER_TYPE>FTTC</FIBER_TYPE>
[B]<CABINET_NO>*****</CABINET_NO>[/B]
<NGA_EXCHANGE>****</NGA_EXCHANGE>
<COPPER_EXCHANGE>*****</COPPER_EXCHANGE>
<PHONE>**********</PHONE>
</search_result>


https://[REDACTED]/[LANDLINENUMBER]

{
  "product": "BB NGA FTTx RES",
  "profileCode": "**M_**M_R",
  [B]"bitstreamId": "***1_***A eth **\/**\/**",[/B]
  [B]"socCode": "*****",
  "ossOwner": "**-**",
  "staticIpFlag": "N",
  "staticIp": "",
  "isFibreCustomer": true
[/B]}

https://[REDACTED]/[LANDLINENUMBER]


{
  "county": null,
  "postalDistrict": null,
  "address": null,
  "fullAddress": null,
  "ardId": null,
  "date": null,
  "maxHSI": "**M_**M_R",
  "maxNGB": "*M_***K_R",
  "maxNRA": "**M_**M_FR",
  "maxDSL": null,
  "exchangeCode": null,
  "cabinet": "***1_***",
  "isNGA": true,
  "isNGB": true,
  "isActive": true,
  "isTownEnabled": null,
[B]  "isCustomer": true,
  "isFibreCustomer": "true",
  "isBroadbandCustomer": true,[/B]
  "validationType": "phone",
  "phone": "***",
  "error": null,
  "processing": false
}

So after much musing over the issue of how to let Eircom know their web developer didn't understand the security difference between client-side code and server-side code, I decided to report the matter through the Data Protection Commissioner, so as Eircom couldn't get away scott-free with such lazy leaking of customer data.

Date: Wed, 2 Jul 2014 17:08:49 +0100
Subject: Responsible Disclosure of Data Leaking on Eircom Website
From:
To: DPC Info <info@dataprotection.ie>

Dear Sir/Madam,

I write to inform you that the eircom website is currently leaking private
information associated with landline telephone numbers.

When a person checks their landline number for an upgrade to 'eFibre', at
https://www.eircom.net/broadband/productDetails?id=bu_23 , a number of
asynchronous client-side calls are made to eircom's APIs, returning data
about that landline. This is so eircom can tell the customer what speed
they can expect to get with the product.

However, the API calls return more data than just the line speed. They
return the following sample of concerning information as well.


- *Full address associated with the landline*
- *The serial number of the street cabinet the landline is connected to*
- *Whether the landline is a customer or not.*


This can easily be abused.


Here are example API calls for my landline number (), although an
adversary can substitute whatever number they want.

=================================================


[I included samples of the data for my landline here, and provided clickable URLs to allow DPC to verify it]

=================================================


=================================================


Yours sincerely,

[ME]

Subject: Acknowledgement of your e-mail to the Data Protection Commissioner
From: "Info" <info@dataprotection.ie>
Reply-To: info@dataprotection.ie
Auto-Submitted: auto-generated
To:
Message-ID: <[REDACTED]@justice.ie>
Sender: "Stewart P. Fennell" <SPFennell@dataprotection.ie>
Date: Thu, 3 Jul 2014 08:49:58 +0100

To Whom It May Concern

I acknowledge receipt of your e-mail to the Data Protection Commissioner.
Where your email relates to a query (as distinct from a formal complaint
under the Data Protection Acts),
you should be aware that in line with our Customer Service Charter we aim
to reply within 15 working days and usually much sooner.
In doing so, we will communicate clearly, providing you with a full
response to your query.

If we are not in a position to issue a reply within that period, we will
inform you of its status.Regards

Office of the Data Protection Commissioner
Canal House
Station Road
Portarlington
Co. Laois

Date: Wed, 23 Jul 2014 18:54:08 +0100
Subject: Regarding Email Sent July 2nd 2014
From:
To: DPC Info <info@dataprotection.ie>

Dear Sir/Madam,

I sent an email to your office 'Responsible Disclosure of Data Leaking on
Eircom Website' on July 2nd.

15 working days have now elapsed, and the security hole still exists.

Regards,

[ME]

After my follow up email I received a phone call from a case officer at the DPC. He apologised for the delay and said my email had only now been forwarded to him. He said he would send details of the problem to Eircom, and "tell them to fix it or we'll have to prosecute them".

I was happy enough with this.

Weeks later nothing had changed on Eircom's side. I rang the DPC again, was told we had to give Eircom a chance to respond.

Blah blah blah more calls. I realised I needed to put my consternation in writing.

Date: Tue, 19 Aug 2014 23:22:12 +0100
Subject: To Be Forwarded to [CASE OFFICER] Re: Eircom
From:
To: DPC Info <info@dataprotection.ie>
Content-Type: text/plain; charset=UTF-8

Hi [REDACTED],

It concerns me that as of now Eircom continue to leak private customer data
via a public API.

I would appreciate any update on this matter.

Regards,

[ME]

Badabing badaboom, a few days later Eircom put up this ajax error message:





Fina-fúcking-ly. (I posted my ill-founded relief this on this thread).

As it turned out, Eircom had something better to do than protect its customers' data, and nothing had changed.

Rang case officer at the DPC once again, told me he was sending an email with 24-hours threat to Eircom. (In my opinion the 24-hours threat should have been bloody months ago).

Checked it today, and Eircom have finally consolidated everything into one AJAX call.

{
  "ardId": "***",
  "cabinet": "***",
  "exchangeCode": "***",
  "isBroadbandCustomer": true,
  "isCustomer": true,
  "isFibreCustomer": true,
  "isNGA": true,
  "isNGB": true,
  "maxHSI": "**M_**M_R",
  "maxNGB": "*M_***K_R",
  "maxNRA": "**M_**M_FR",
  "phone": "***-*****",
  "validationType": "phone",
  "completed": true,
  "partialAddresses": [
    
  ],
  "isRedCustomer": false,
  "isNeighborAddress": false
}

Oh well, at least the landline->address lookup API is gone. Right?

.
.
.
.
.
.
.
.
.


Nope, they haven't taken any of the old API calls offline.


GRRRRRRRRRRRR

All the signs point to that I should have just shut up about it, built a reverse marketing directory and sold it to Indian scammers.

Attached is Eircom's old javascript (publicly available by the way) with evidence of their idiocy regarding APIs (a full list of endpoints). Hopefully they'll cop on some day if we shame them.