3

The control + j feature within PeopleSoft outputs a list of potentially interesting data for a potential attacker. The feature is generally used to aid in debugging. Here is a the [censored] output from a control + j:

enter image description here

Is it a security risk to have control + j functionality enabled in a production (live/public) instance of PeopleSoft? I imagine it is a risk (albeit perhaps small) because it simply saves time for the potential attacker in giving them the specific platform knowledge to go lookup known attacks for that platform flavour.

Is my assessment correct? What other risks (if any) does it impose?

  • 1
    In general, all debugging info should be restricted. That's why even 404 error pages should be customized so that only allowed information is disclosed. – schroeder Nov 5 '14 at 16:00
  • 1
    That's what I say but the counter-argument is always that this particular tools is useful for the helpdesk to track down problems... – Matthew Peters Nov 5 '14 at 16:09
  • Then the decision-maker needs to weigh the customer-service benefits with the info disclosure risks. Is there anything in the debug info that cannot be gleaned using other methods? For instance, can I get the platform info any other way in order to search for platform-specific vulnerabilities? – schroeder Nov 5 '14 at 16:11
  • I would submit that all of this information can be ascertained elsewhere but it would require far more work than a simple two button click... – Matthew Peters Nov 5 '14 at 16:13
  • Then, if true, from a data classification perspective, the data is already public. – schroeder Nov 5 '14 at 16:35
2

I would say a lot depends on if the users are remote, or are on the local machine. I would disable the feature if you do not need it.

Local user / attacker:

If the users are local, an attacker can find out most (but not all) of this information fairly easily, although this report would certainly make it easier for the attacker. Even locally, there are a couple pieces of data that would probably be hard to obtain by other methods that could be useful to attackers.

  • I see component buffer size as being troublesome because it could aid in buffer overflow attacks.
  • Depending on the implementation of the database, database name or possibly component could aid in a SQL injection attack as well (if PeopleSoft is vulnerable to this, which I do not know). Most of the other information can aid in an attack, but is generally available at the local machine anyway.

Remote user / attacker:

If the users are remote, this report is far more problematic. It reveals many details that would be useful to attackers, which would be harder for them to obtain through other means. For example, the OS, browser, service pack, etc... would let the attacker know what they are attacking and if it is out of date (so they know what vulnerabilities there are).

I would highly recommend disabling this feature if you do not need it and there are remote users.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.