_commit_at,_commit_hash,_id,_item,_version,_commit,description,tags,date,pdf-url,nature,title,url,timestamp,pdf-content,decision,_item_full_hash,_changed_columns
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,112,112,1,952,"A financial penalty of $9,000 was imposed on Singtel for failing to put in place reasonable security arrangements to prevent the unauthorised disclosure of personal data of some of its customers via its My Singtel mobile application.","[""Protection"", ""Financial Penalty"", ""Accommodation and F&B""]",2020-02-11,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Decision---Singapore-Telecommunications-Limited-311219.pdf,Protection,Breach of the Protection Obligation by Singtel,https://www.pdpc.gov.sg/all-commissions-decisions/2020/02/breach-of-the-protection-obligation-by-singtel,2020-02-11,"PERSONAL DATA PROTECTION COMMISSION

[2019] SGPDPC 49

Case No. DP-1802-B1732
In the matter of an investigation under section 50(1) of the
Personal Data Protection Act 2012
And
Singapore Telecommunications Limited

… Organisation

DECISION

1

Singapore Telecommunications Limited

Yeong Zee Kin, Deputy Commissioner — Case No DP-1802-B1732
31 December 2019
Introduction
1

On 21 February 2018, the Personal Data Protection Commission (the “Commission”)

received a complaint from an individual mobile subscriber of Singapore Telecommunications
Limited (the “Organisation”) asserting that when the subscriber accessed account details
using the Organistion’s “MySingTel” mobile application (the “App”), the subscriber was able
to view the personal information of another subscriber.
Facts of the Case
2

The Commission’s investigations revealed that due to a technical issue that occurred

during a limited period, certain mobile subscribers of the Organisation were able to view the
personal data of other subscribers when they used the App (the “Incident”). The Incident took
place over a period of approximately 11 hours on 20 February 2018 and the personal data of
750 subscribers (the “Affected Subscribers”) were exposed to the risk of access by other
subscribers. Of these, the personal data of 39 subscribers were, in fact, accessed by other
subscribers. The specific cause of this incident is described below.
3

The Incident arose during the Organisation’s migration of its database of mobile

customer accounts from its existing billing system (the “Existing System”) to a new billing
system (the “New System”). [Redacted].
4

However, an issue arose when there was a mobile number previously assigned to a

subscriber (“historical numbers”) that was subsequently reassigned to another subscriber.
One situation in which this happened was when a subscriber ported over an existing mobile
number from another mobile telephone operator to the Organisation. In order to effect the
porting over, the Organisation would first issue the subscriber with a temporary mobile phone
number (this is referred to as a “dummy number”) as part of the overall porting mechanism.
After the subscriber’s existing mobile telephone number had been successfully ported over to
the Organisation, the dummy number will cease to be linked to the subscriber [redacted].
2

5

[Redacted].

6

During the migration period, when a subscriber logged in to the App, the App would

query the Organisation’s Master Routing Database (“MRD”) to check if the subscriber’s data
had been migrated and then route the query to the relevant billing system. On 20 February
2018, due to slow response times, queries by MRD to the Existing System encountered
timeouts. When these timeouts occurred, even if the subscriber had been migrated to the New
System, the query would by default be routed to the Existing System. If the subscriber had a
historical number, such as a dummy number [redacted], [in certain circumstances] the
service information associated with both the current mobile number and the historical number
would be retrieved and made available to the subscriber. The service information of the
historical number could be viewed by clicking on the mobile number and information bar. If
the historical number had been reassigned to an Affected Subscriber, the service information
of the Affected Subscriber would have been retrieved and made available to, and therefore
at risk of access by, the subscriber. In this way, the associated information of the 39 subscribers
were accessed during the timeouts.

7

The types of personal information of the Affected Subscribers (the “Personal Data”)

which were accessible through the App included:
(a)

mobile numbers;

(b)

mobile plans subscribed to;

(c)

usage details;

(d)

account numbers; and

(e)

add-on services subscribed to. The relevant subscribers1 could also modify the

add-on services tied to the Affected Subscribers’ mobile number; 6 such subscribers
had tried to make such modifications.
8

Upon being notified by the Commission, the Organisation ensured that migrated

Subscribers who encountered timeouts when using the App were shown an error message, and
performed testing to verify that this was the case.
3

Findings and Basis for Determination
9

Section 24 of the Personal Data Protection Act 2012 (the “PDPA”) requires an

organisation to protect personal data in its possession or under its control by making reasonable
security arrangements to prevent unauthorised access, collection, use, disclosure, copying,
modification, disposal or similar risks.
Whether the Organisation Complied with Section 24
10

With respect to the design of the MRD, the Organisation asserted that it did not intend

for the MRD to route queries to the Existing System in the event of a timeout, and that the
Organisation’s intentions was for an error message to be displayed instead. I give the
Organisation the benefit of doubt and accept its assertion. Since the intention was to display an
error message, this ought to have been included as a scenario for user testing. Consequently,
this Incident was caused by the following lapses on the Organisation’s part:

(a)

The Organisation had not carried out more thoroughly scoped tests to firstly

ensure that dummy numbers in these circumstances did not produce any unintended
effects; and

(b)

the test plan should have anticipated likely scenarios, such as session time-

out.

12

If these had been done, the Organisation could have discovered the potential

erroneous retrieval and unauthorised disclosure of the Affected Subscribers’ Personal Data
for such accounts, and consequently, implemented measures to prevent the Incident from
occurring. In view of the above, I found the Organisation in breach of section 24 of the
PDPA.
13

The Organisation in its representations made the point that, in their view, the data

breach “happened only where there was an obscure combination of factors”. While, it is
accepted that a combination of events had to occur before personal data would have been
disclosed, I do not think that the combination of factors was obscure. First, session timeout
for MRD queries was foreseen, with the intention for an error message to be displayed.
4

Second, the Organisation had full knowledge of how dummy numbers are assigned as a
temporary bridge for number porting, and that these dummy numbers are eventually reassigned. The combination of factors giving rise to the Incident was foreseeable and I do
not think that the combination is obscure. The impact of the Incident was contained because
of its prompt action in implementing a temporary fix.

The Deputy Commissioner’s Directions
14

In determining the directions to be imposed on the Organisation under section 29 of the

PDPA, I took into account the following mitigating factors:
(a)

the Organisation was cooperative during the investigations;

(b)

the Organisation took prompt action to mitigate the impact of the Incident by

implementing a temporary fix within 11 hours; and
(c)

although the Personal Data of 750 individuals were at risk, only 39 of such

individuals’ Personal Data were subject to unauthorised disclosure.
15

Having carefully considered all the relevant factors of this case, I hereby direct the

Organisation to pay a financial penalty of $9,000 within 30 days from the date of the directions,
failing which interest at the rate specified in the Rules of Court in respect of judgment debts
shall accrue and be payable on the outstanding amount of such financial penalty until the
financial penalty is paid in full.
16

As the Organisation had completed its migration on 19 August 2018 and there are no

further risks to the Personal Data arising from the retrieval of Subscriber information from the
Organisation’s Existing System, I have assessed that the remedial actions set out at [8] had
sufficiently addressed the risks to the Personal Data arising from the Incident. I have therefore
not made further directions for the Organisation.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR PERSONAL DATA PROTECTION
5

",Financial Penalty,e2d462d64ec0e10bc672b4850fabd12bb0f0d993,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"
2023-10-01T11:02:10+08:00,fbd32491db44d3d0c97aa12a99cefd61ec954264,133,133,1,952,"A financial penalty of $25,000 was imposed on Singtel for failing to put in place reasonable security arrangements to protect the personal data of users on its My Singtel mobile application.","[""Protection"", ""Financial Penalty""]",2019-11-04,https://www.pdpc.gov.sg/-/media/Files/PDPC/PDF-Files/Commissions-Decisions/Grounds-of-Decision---Singapore-Telecommunications-Limited.pdf,Protection,Breach of the Protection Obligation by Singtel,https://www.pdpc.gov.sg/all-commissions-decisions/2019/11/breach-of-the-protection-obligation-by-singtel,2019-11-04,"PERSONAL DATA PROTECTION COMMISSION

[2019] SGPDPC 36
Case No DP-1705-B0781

In the matter of an investigation under section 50(1) of the Personal Data
Protection Act 2012

And

Singapore Telecommunications Limited
… Organisation

DECISION

1

Singapore Telecommunications Limited
[2019] SGPDPC 36

Tan Kiat How, Commissioner — Case No DP-1705-B0781
12 September 2019

Background
1

This case concerns a design issue in a previous version of Singapore

Telecommunications Limited’s (the “Organisation”) “My Singtel” mobile app
(the “Mobile App”), which resulted in the unauthorised disclosure of the personal
data of the Organisation’s customers. The current version of the Organisation’s
Mobile App does not have this design issue as it has been fixed.
2

On 17 May 2017, the Personal Data Protection Commission (the

“Commission”) received information from an anonymous informant alleging that
there was a vulnerability in the Organisation’s Mobile App, which allowed the
informant to access the account details of other customers (the “Data Breach”).
Following an investigation into the matter, the Commissioner found the
Organisation to be in breach of section 24 of the Personal Data Protection Act
2012 (“PDPA”). The Commissioner sets out below his findings and grounds of
decision.

1

Singapore Telecommunications Limited

[2019] SGPDPC 36

Material Facts and Documents
3

The Organisation is a telecommunications company in Singapore. The

Mobile App was developed by the Organisation’s IT team to enable its customers
to track their account information and manage add-on services. Communications
between the Mobile App and the Organisation’s servers are conducted via
Application Programming Interfaces (“API”).
4

The Organisation’s customers can login to the Mobile App via the

following methods:
(a)

Mobile Station International Subscriber Directory Number

(“MSISDN”) login: where a customer’s mobile phone is connected to the
Organisation’s mobile data network (3G/4G), the Organisation’s servers
will verify that the MSISDN and IP address of the mobile phones are
correct before granting the customer access to the Mobile App;1
(b)

One Time Password (“OTP”): through validation of the OTP sent

to customers via SMS and entering it in the Mobile App (“OTP Login
Method”); and
(c)
5

OnePass: by using their OnePass login and password.

Customers that login to the Mobile App via the MSISDN or OTP login

method have access to the following data relating to their own account:

1

Each MSISDN is assigned a unique IP address. When a user logs in to the Mobile App via the
MSISDN login method, the backend server will verify the MSISDN assigned to that IP address.
Once verified, the login attempt will be deemed to be authenticated and the user will be granted
access to the Mobile App.

2

Singapore Telecommunications Limited

[2019] SGPDPC 36

(a)

the mobile number used to access the Mobile App;

(b)

related service plan information (i.e. data, talktime and SMS

usage);

6

(c)

outstanding bill amount;

(d)

bill payment due date; and

(e)

billing account number.

In addition to the data mentioned at paragraph 5 above, customers that

login to the Mobile App via the OnePass method also have access to all the service
information for all Singtel services registered under that Singtel OnePass ID. In
addition, if such customers had opted for electronic billing, they would have
access to the following data relating to their own account:
(a)

the customer’s name;

(b)

the customer’s billing address; and

(c)

all Singtel services and corresponding usage (where applicable)

under the same billing account number.
7

The anonymous informant claimed that the API on the server could be

manipulated by using specialised tools to gain unauthorised access to the account
details of other customers through the following methods:
(a)

The MSISDN is a string of numbers that incorporates within it the

customer’s mobile phone number. By logging in using a legitimate Singtel
account via the MSISDN login method and changing the value in the

3

Singapore Telecommunications Limited

[2019] SGPDPC 36

MSISDN field (i.e. to another customer’s mobile phone number)2 that was
sent from the Mobile App’s API to the Organisation’s servers, the
informant was able to retrieve the account details (such as the billing
account number and billing cycle) of the other customer.
(b)

Thereafter, by logging in using a legitimate Singtel account via the

OnePass method and changing the value in the billing account number and
billing cycle fields, the informant was able to obtain the customer’s bill,
which contains further personal data such as the customer’s name, billing
address and all Singtel services and corresponding usage (where
applicable) under the same billing account number3.
8

The informant accessed four billing accounts and extracted the customer’s

name, billing address, billing account number, mobile phone number as well as
customer service plans (including data, talk time and SMS usage). While there
was no further evidence of unauthorised access, the personal data of
approximately 330,000 of the Organisation’s customers who were using the
Mobile App at the material time were put at risk of disclosure.
9

Although the Organisation had engaged a third party security vendor to

conduct regular security penetration tests on the Mobile App and backend systems
(including the API), the tests had not detected the design issue in the API that led
to the Data Breach and the Organisation was unaware of it.

The subscriber’s mobile phone number was used by the Organisation’s servers to retrieve the
subscriber’s account and billing details.
2

3

As mentioned at paragraph 6 above.

4

Singapore Telecommunications Limited

10

[2019] SGPDPC 36

During the investigation, the Organisation admitted that the Data Breach

was caused by a design issue in the API – the application input4 was not validated
against the login credential used to access the Mobile App before performing the
requested operation (the “Direct Object Reference Vulnerability”). Because all
request parameters sent by the Mobile App to the Organisation’s server during a
valid login session were assumed to be valid, once a user was legitimately
authenticated to initiate a valid login session on the device (via the MSISDN, OTP
or OnePass login methods), the user would be able to intercept and change the
field parameters in the API requests between the Mobile App and the server.
Notwithstanding, the Organisation asserted that such an action was “not
something that a normal user of the App would attempt” and the attacker must be
“technically competent” as the changing of the parameters could only be
performed on a workstation.
11

Soon after it was notified of the Data Breach, the Organisation took

remedial actions to resolve the Direct Object Reference Vulnerability. The
Organisation enhanced the API in order to tightly couple the Mobile App user’s
identifiers to the authenticated session. In this manner, should the parameters be
modified during the same authenticated session such that they do not match the
Mobile App user’s identifiers (e.g. the MSISDN field is changed to another
number and service information such as data usage of that other number is
requested), the user will see an error message and be logged out.

4

Such as the MSISDN for the MSISDN or OTP login method, and the MSISDN, billing account
number, billing payment due date for the OnePass login method.

5

Singapore Telecommunications Limited

[2019] SGPDPC 36

The Commissioner’s Findings and Basis for Determination
12

It is not disputed that the subscriber’s name, billing address, billing

account number, mobile phone number as well as customer service plans
(including data, talk time and SMS usage) are “personal data” as defined in section
2(1) of the PDPA (“Personal Data”). There is also no dispute that the PDPA
applies to the Organisation as it falls within the PDPA’s definition of
“organisation”. The key issue to be determined in this case is therefore whether
the Organisation had complied with its obligations under section 24 of the PDPA.
Whether the Organisation complied with its obligations under section 24 of the
PDPA
13

Section 24 of the PDPA provides that an organisation shall protect

personal data in its possession or under its control by making reasonable security
arrangements to prevent unauthorised access, collection, use, disclosure, copying,
modification, disposal or similar risks. It is not disputed that the Personal Data
was in the Organisation’s possession and/or control.
14

Having considered the material facts, the Commissioner finds that even

though the Organisation had engaged a third party security vendor to conduct
regular penetration tests on the Mobile App and backend systems (including the
API), the Organisation failed to put in place reasonable security arrangements with
respect to the said API to protect the Personal Data.
15

First, by the Organisation’s own admission, the Data Breach was caused

by the Direct Object Reference Vulnerability, which was a design issue in the API.
The Organisation failed to take into account the risk of manipulation to the
parameters sent from the Mobile App’s API to the Organisation’s servers when

6

Singapore Telecommunications Limited

[2019] SGPDPC 36

designing the Mobile App. The validation of parameters (whether input or noninput fields), which could have prevented unauthorised access to the Personal
Data, were not implemented as part of the API’s initial design.
16

The Direct Object Reference Vulnerability is a relatively basic design

issue and well-known security risk that a reasonable person would have
considered necessary to detect and prevent. It was one of Open Web Application
Security Project (“OWASP”) 2013’s top 10 most critical web application security
risks and OWASP recommended, among other things, the usage of Indirect Object
Reference as a prevention method.
17

Furthermore, as highlighted in the Commission’s Guide to Building

Websites for SMEs (at [6.5]), programmers should be aware of the common
website vulnerabilities and adopt the appropriate programming techniques and
practices to ensure that personal data cannot be exposed through such
vulnerabilities. Although the Guide to Building Websites for SMEs sets out key
considerations for the process of setting up a website, the same principles are
similarly applicable when programming a mobile application. This is because the
same issues arise when a server responds to requests from a mobile app as when
it responds to requests from a web browser.
“6.5 Website Programming

6.5.1 When programming the website, programmers should be aware of
the common website vulnerabilities, and adopt the proper programming
techniques and practices to avoid them. Programmers can use the
OWASP Top 10 vulnerabilities list as guide and some common
vulnerabilities include:

7

Singapore Telecommunications Limited

[2019] SGPDPC 36



Injection (e.g. SQL Injection)



Cross-site scripting



Buffer overflows



Poor authentication & session management

6.5.2 Organisations and any engaged IT vendors should ensure that
personal data cannot be exposed, either accidently or by design,
through any such vulnerabilities. The website functions should be
thoroughly tested or scanned for vulnerabilities, before the website is
launched.”

[Emphasis added.]
18

By failing to take into account the risk of manipulation to parameters sent

from the Mobile App’s API to the Organisation’s servers, the Commissioner finds
that Organisation subjected its customers to the risk of actual and potential
unauthorised access of their personal data.
19

At this juncture, the Commissioner would like to deal with the

Organisation’s claim that exploiting the Direct Object Reference Vulnerability
was “not something that a normal user of the App would attempt” and that the
attacker must be “technically competent” as the changing of the parameters could
only be performed on a workstation.
20

While the changing of parameters would require a person to have some

knowledge of the tools and methods for doing so, anyone with working knowledge
of how a mobile app communicates with the servers through an API could have
exploited the Direct Object Reference Vulnerability. The tools and software
required to manipulate the parameters are available online.

8

Singapore Telecommunications Limited

21

[2019] SGPDPC 36

The Organisation was aware that direct object reference vulnerabilities had

been discovered in its Mobile App. Despite having received professional advice
to take precautions against such vulnerabilities, the Organisation omitted to
conduct a full code review on the input and non-input fields and hence failed to
discover the Direct Object Reference Vulnerability that was exploited in this case.
22

As mentioned at paragraph 9 above, the Organisation had engaged a third

party security vendor to conduct regular security penetration tests on the Mobile
App and backend systems.5 The Direct Object Reference Vulnerability was not
detected prior to the Data Breach but a variation of it was found in the October
2015 penetration test (“2015 Penetration Test Report”) and rectified in
November 2015. In the 2015 Penetration Test Report, the security vendor cited
three examples of Direct Object References vulnerabilities in the API
(collectively, the “2015 DOR Vulnerabilities”).
23

During the investigation, the Organisation represented that the 2015 DOR

Vulnerabilities were specific to the API accepting input fields (i.e. parameters
keyed in by users at the user interface level), whereas the Direct Object Reference
Vulnerability did not validate non-input fields (i.e. parameters not keyed in by
users such as automatically generated URL at the backend). As the Organisation
had only conducted a code review for the 2015 DOR Vulnerabilities on APIs
accepting input fields, the Direct Object Reference Vulnerability that caused the
Data Breach was not discovered at the time. However, contrary to the
Organisation’s representation, a review of the 2015 Penetration Test Report
showed that both input and non-input fields were affected by the 2015 DOR

5

At the time of the Data Breach, the most recent penetration tests on the Mobile App and backend
systems were conducted in October 2015 and January 2017.

9

Singapore Telecommunications Limited

[2019] SGPDPC 36

Vulnerabilities, and even non-input fields could be manipulated by the Mobile
App’s call to the API and that this should be remedied.
24

Based on the findings and recommendations in the 2015 Penetration Test

Report, the Organisation ought to have been more diligent in performing a
thorough assessment of the security posture of the API and the server. The
Organisation should have examined all other functions to determine whether they
could be exploited by changing the input parameters and implement the relevant
fixes, but it had failed to do so.
25

For the reasons above, the Commissioner finds that the Organisation is in

breach of section 24 of the PDPA as it failed to make reasonable security
arrangements with respect to the said API to protect the personal data in its
possession and within its control.
26

The Organisation submitted representations after a preliminary grounds of

decision was issued and raised four points. First, the Organisation asserted that it
was reasonable that any request parameters sent by the Mobile App during a login
session was treated as valid without having to re-validate the request parameters
during the session, given that the user was required to be legitimately
authenticated via one of the three login methods. This does not address the Direct
Object Reference Vulnerabilities which could be exploited by a third party.
Paragraphs 15 to 25 above, deal with this point.
27

Secondly, the Organisation asserted that not all of its 330,000 customers’

data was put at risk of disclosure as the informant would have had to use the
correct combination of the mobile number of the customer, the customer’s billing
account number, billing account ID and billing cycle date in order to generate a
bill specific to that customer or a correct mobile phone number to generate the

10

Singapore Telecommunications Limited

[2019] SGPDPC 36

relevant subscription information. The Organisation thus asserts that the decision
should be narrowed to only the 4 accounts that were successfully accessed. The
manner in which the informant was able to access the records of the said 4
accounts is set out above at paragraphs 7(a) and 7(b). While the informant only
accessed 4 accounts, the informant or someone with similar skillset and access to
the same resources could potentially have access to the personal data of all
330,000 subscribers who were using the Mobile App during the material time of
the Incident. In the circumstances, it is correct that the full size of the database
was one of the factors taken into consideration in assessing the financial penalty
quantum.
28

Thirdly, in reference to paragraph 19 above, the Organisation asserted that

the technical expertise required by someone to exploit the Direct Object Reference
Vulnerability was underestimated in this Decision. For the avoidance of doubt, it
is agreed that some level of technical expertise would have been required for
someone to exploit the Direct Object Reference Vulnerability. While this level of
technical expertise is not uncommon, what cannot be ignored is that the
vulnerability is well known and the requisite knowledge, tools and software to
exploit the Direct Object Reference Vulnerability can be acquired online. This
increases the likelihood that someone with the wrong motivation could have
exploited the vulnerability.
29

Finally, the Organisation also restates that the Direct Object Reference

Vulnerability was not detected in the security penetration tests. This is dealt with
at paragraph 21 above.
30

In the circumstances, the Commissioner decided to maintain his finding

that the Organisation was in contravention of section 24 of the PDPA.
Nevertheless, the Commissioner has decided to impose a reduced financial

11

Singapore Telecommunications Limited

[2019] SGPDPC 36

penalty quantum as set out at paragraph 32 below, given that the exploitation of
the vulnerability requires some level of technical expertise.
The Commissioner’s Directions
31

Given the Commissioner’s findings that the Organisation is in breach of

section 24 of the PDPA, the Commissioner is empowered under section 29 of the
PDPA to issue such directions as it deems fit to ensure compliance with the PDPA.
This may include directing the Organisation to pay a financial penalty of such
amount not exceeding S$1 million.
32

Having considered all the relevant factors in this case, the Commissioner

hereby directs the Organisation to pay a financial penalty of $25,000 within 30
days from the date of the Commissioner’s direction, failing which, interest at the
rate specified in the Rules of Court6 in respect of judgment debts, shall accrue and
be payable on the outstanding amount of the financial penalty until the financial
penalty is paid in full. The Commissioner has not set out any further directions
given the remediation measures that the Organisation has already put in place.

YEONG ZEE KIN
DEPUTY COMMISSIONER
FOR COMMISSIONER FOR PERSONAL DATA PROTECTION

6

Cap 322, R5, 2014 Rev Ed.

12

",Financial Penalty,1cfca0515da19cdcbdfd450d34bfa1d3c2583b97,"[""pdf-content"",""timestamp"",""decision"",""pdf-url"",""tags"",""nature"",""url"",""title"",""date"",""description""]"