Telkom website exposes personal information

[Kevin Lancaster]

Telkom website exposes personal details

Telkom’s website is exposing the personal details of people, including their ID numbers, contact details, and home addresses.

 

[Yuu]

View attachment 2015-10-08_13-04-40.bmp

mybroadband, may or maynot be linked but when being redirected from the Ti Tracking tool to topup, this is what is shown when accessing another part of the site exposing ones username and password in plain text .

Edit:
Also seen another subscriber's details exposed when accessing the SMT [Servce Management] Tool. The details have since been removed. Also showed my mailbox deleted when i checked again just now :wtf:.

View attachment 2015-10-08_13-11-22.bmp

 

[whatwhat]

View attachment 303706

mybroadband, may or maynot be linked but when being redirected from the Ti Tracking tool to topup, this is what is shown when accessing another part of the site exposing ones username and password in plain text .

It is over HTTPS though.

 

[Yuu]

It is over HTTPS though.

Is it supposed to show it like that in the address bar, nevermind me, if someone at the office is accessing it?

 

[AntiGanda]

Now the order screen defaults the customer as a single, female Dr.

How odd!

 

[ThinkCentre]

Why am I not surprised?

 

[Malasius]

This has been going on for a while already, surprised its only been picked up now?

 

[whatwhat]

Is it supposed to show it like that in the address bar, nevermind me, if someone at the office is accessing it?

If you use a GET (for example going to a website) you cannot post a message body. So to get past that the people put all the parameters in the URL. That is normally OK if you are over a secure connection, but the URL itself (with the params) has the possibility of ending up in a log file somewhere on a server.

One other way to do this would have been a POST with the information in a request body, you wouldn't see the info in the URL then.

 

[Yuu]

If you use a GET (for example going to a website) you cannot post a message body. So to get past that the people put all the parameters in the URL. That is normally OK if you are over a secure connection, but the URL itself (with the params) has the possibility of ending up in a log file somewhere on a server.

One other way to do this would have been a POST with the information in a request body, you wouldn't see the info in the URL then.

I hope they are taking note of what you have said because that is exactly what they should be doing now . Thank You for explaining, beyond my skill set but also am intrigued in wanting to learn about this more.

 

[MickeyD]

Telkom was alerted to the security problem, and it is understood they have applied a patch to resolve the issue.

And?

Was the patch successful?

 

[Trilkop]

And this is the reason why we will never see the launch of the Popi act. Even though telkom will not be affected by the act in these cases, there are just too many vulnerabilities all over the show. I believe government recently postponed the act for another 2 years while they are looking at appointing a commissioner.

 

[Thor]

Dammit now I can't continue scraping

Fun while it lasted

 

[Trilkop]

Dammit now I can't continue scraping

Fun while it lasted

I found about 9 million records while it was open, but it was based on phone numbers and not unique clients.

 

[ranger]

If you use a GET (for example going to a website) you cannot post a message body. So to get past that the people put all the parameters in the URL. That is normally OK if you are over a secure connection, but the URL itself (with the params) has the possibility of ending up in a log file somewhere on a server.

One other way to do this would have been a POST with the information in a request body, you wouldn't see the info in the URL then.

There are reasons we couldn't use a POST.

So, the original requirement to be able to have all the features was a directive from above without much context to our other initiatives, and we were told 'make it so'. We highlighted the issues, but due to timelines using a GET with the values was the only option that would make the timelines (that were aligned with other projects outside our teams).

However, as soon as the initial deployment was completed, work started to address this issue (not just the exposing of the details). However, that change hasn't made it through QA yet (due to other projects and bug-fixes).

Of course, the actual long-term solution has been delayed (as we highlighted to management when they came with this 'quick-fix') because the quick-fix wasn't quick and has resulted in a lot more work than they thought should be required.

 

[ranger]

View attachment 303706

Edit:
Also seen another subscriber's details exposed when accessing the SMT [Servce Management] Tool. The details have since been removed. Also showed my mailbox deleted when i checked again just now :wtf:.

View attachment 303718

It's working correctly for me, and I don't think this should be possible ... please send me details (your username) if it persists.

 

[MagicDude4Eva]

There are reasons we couldn't use a POST.

So, the original requirement to be able to have all the features was a directive from above without much context to our other initiatives, and we were told 'make it so'. We highlighted the issues, but due to timelines using a GET with the values was the only option that would make the timelines (that were aligned with other projects outside our teams).

However, as soon as the initial deployment was completed, work started to address this issue (not just the exposing of the details). However, that change hasn't made it through QA yet (due to other projects and bug-fixes).

Of course, the actual long-term solution has been delayed (as we highlighted to management when they came with this 'quick-fix') because the quick-fix wasn't quick and has resulted in a lot more work than they thought should be required.

I have no words for this then. You knew that this will expose the company, alerted management and "due to timelines" then still went ahead and implemented if. I honestly can not understand why there is a "technical" challenge between a GET and a POST - it is markup in HTML. It is also an illusion that data is safe on a GET if it is transmitted via HTTPS. Your site is massively open to XSS, SLI and session hijacking. Once an attacker injected BeEF into your website, you are pretty much done for and C99 shells will be sitting on your servers.

Surely Telkom subscribes to ITIL and COBIT and has a CSO who is in charge of security - puzzling that your management team of dev, IT ops and architecture allowed all of this. It is one thing to unknowingly make a mistake and open up a vulnerability but it is on a completely different level to do so knowingly.

 

[whatwhat]

I have no words for this then. You knew that this will expose the company, alerted management and "due to timelines" then still went ahead and implemented if. I honestly can not understand why there is a "technical" challenge between a GET and a POST - it is markup in HTML. It is also an illusion that data is safe on a GET if it is transmitted via HTTPS. Your site is massively open to XSS, SLI and session hijacking. Once an attacker injected BeEF into your website, you are pretty much done for and C99 shells will be sitting on your servers.

Surely Telkom subscribes to ITIL and COBIT and has a CSO who is in charge of security - puzzling that your management team of dev, IT ops and architecture allowed all of this. It is one thing to unknowingly make a mistake and open up a vulnerability but it is on a completely different level to do so knowingly.

As much as those are good practices, in reality in a big corporate that isn't always possible. Sometimes you just have to make it work, even if it isn't optimal and hope that it can be fixed later.

 

[KhoisanX]

There are reasons we couldn't use a POST.

Could you please elaborate on this, because I really can't think of any scenario where it would be technically impossible(or even challenging) to implement POST instead of GET.

 

[ranger]

I have no words for this then. You knew that this will expose the company, alerted management and "due to timelines" then still went ahead and implemented if.

'We' didn't decide to put it in like that, we logged the defect, highlighted the risk to management, and *they* decided it should go in with the defect.

(In actual fact we recommended against the entire project in favour of focusing on another project that will replace all the apps with a single portal which supports modern SSO, but that project is now even further off because of time lost on this 'quick win').

I honestly can not understand why there is a "technical" challenge between a GET and a POST - it is markup in HTML.

The original design was for POST to prevent the credentials showing in the URL, but apparently the servlet api doesn't support something that was required to get the POST approach to work.

Thus the defect has been logged and another approach that supports GET was developed and is currently in QA.

It is also an illusion that data is safe on a GET if it is transmitted via HTTPS. Your site is massively open to XSS, SLI and session hijacking.

I am not a developer, but shouldn't same-origin and http-only on the session cookies prevent XSS?

Once an attacker injected BeEF into your website, you are pretty much done for and C99 shells will be sitting on your servers.

All filesystems writeable by the web tier are mounted no-exec.

Surely Telkom subscribes to ITIL and COBIT and has a CSO who is in charge of security - puzzling that your management team of dev, IT ops and architecture allowed all of this.

See above. ITIL doesn't guarantee the correct decisions get taken.

It is one thing to unknowingly make a mistake and open up a vulnerability but it is on a completely different level to do so knowingly.

So you're saying next time we shouldn't worry about security at all?

 

[km2]

While you guys are at it, make sure your ArcGIS system is locked down. I know when I was trying to check my VDSL rollout date it offered up waaaay more information than it should for a proxied public service.