Skip to Content

People who have worked since ramp-up XI3.0 or earlier generally know the Ins & Outs of XI3.0 administration. Back then, It was an all-in-one role (all-win roles we used to call it) where the 1 man army used to install, develop, take the objects all the way through production, go-live & support. But with SAP XI/PI widely accepted as integration broker & ESB, it became the responsibility of NW Administrors aka basis teams to maintain XI/PI systems and there was a clear distinction in the roles & responsibilities of PI developer and administrator.

When messages from Adapter engine just vanish in the vaccum without reaching integration server, IDOCs don’t reach the target systems, logs & traces not active, a seasoned XI/PI  consultant will be tempted to go to SXMB_ADM or IDX1/2 to check if the post-installations were performed properly. But with limited authorizations & per development process, have to raise an issue for NWAdmin to figure it out.

One such time, SLDCHECK failed and i had to wait for days but the issue was still un-resolved. I wanted to get to the roots of it and check the configuration but i didn’t have the authorization. So i started debugging SLDCHECK and i came across PIAPPLUSER password. [Generally Administrators try to keep the passwords consistent or atleast logical in the landscape. (un)luckily, they had the same password for PISUPER]. I jumped out in joy like a kid who found a bag of candies hidden right under his desk. I hacked-in, found the issue and requested NWAdmin to check this specific configuration and they fixed it.

Hacking in PI 7.0

LCR_LIST_BUSINESS_SYSTEMS uses the configuration maintained in SLDAPICUST (TCode) to access the SLD and get the list of Business Systems. For local SLD installations, it uses SLDAPIUSER. But for Central SLD’s, SAP recommends to replace SLDAPIUSER with PIAPPLUSER in SLDAPICUST. (as per configuration & post installation guides).

Refer to Section 2.4 Basic SAP System Parameters & Section 5.17.1 Performing PI-Specific Steps for SLD Configuration for more details on Maintaining SLD connection parameters.

SLDAPICUST

Figure 1.0 SLDAPCUST Configuration in PI System

LCR_LIST_BUSINESS_SYSTEMS function Module can be hacked to get the PIAPPLUSER password& set a Breakpoint at line 67.

LCR_LIST_BUSSYS_Code_Breakpoint.JPG

Figure 2. Breakpoint in LCR_LIST_BUSINESS_SYSTEMS

create object accessor.
accessor->set_tracelevel( tracelevel ). 

PIAPPLUSER_Password.JPG

Figure 3.0 PIAPPLUSER password hacked

Caution:  Changing configurations by using the Hacked users/passwords is strongly discouraged.

Word to SAP: SAP can take it as a positive feedback & release a note to enrypt the password.

Links of Help

Change PI Service user passwords with caution

SAP NoteNo: 999962 : PI 7.10: Change passwords of PI service users
SAP NoteNo: 936093 : XI 7.0  : Changing the passwords of XI service users

To report this post you need to login first.

12 Comments

You must be Logged on to comment or reply to a post.

    1. Former Member Post author
      I know that debugging gives you greater flexibility but i am not aware of FM’s where you can see the unencrypted passwords.

      Do you know of any other FM’s in any of other SAP systems (not just ECC or PI), where you can find unencrypted passwords by debugging? If you can, then it is a serious compliance issue.

      -Siva Maranani

      (0) 
      1. Former Member
        “… but i am not aware of FM’s where you can see the unencrypted passwords.”
        The correct approach would be to contact SAP via secure@sap.com (Security Response Team) as this would be a security bug for which SAP should first have a patch availeble before “going public”.

        Amongst security researchers, this is known as a “grace period” for administrators.

        Cheers,
        Julius

        (0) 
  1. Former Member
    There is little which is worse than debugging and this is not the only risk.

    Have you seen SAP Note 1161548? The encrypted password’s callstack is now protected by the SecureStore area in the kernel! There is a reverse option for the migration, but you can protect that with authorizations as well.

    I guess it is a general problem that if you save logon credentials on the client side then even if you encrypt them, they must be reversible at some stage to be presented to the server side… otherwise you would need to distribute the one-way hash function itself which is much worse, and anyone stiffing the network or debugging could simply insert the hash into the field and not even need to know the password.

    If you can call a function via a connection with reversible credentials you also do not need to know the password, as the system does the task for you. Now the trick is to prevent the user from “catching” the password on the client side or in transit accross the nextwork and logon from a client which he has more access to (such as debug authority, or installing software, or SDK’s, etc…).

    If you already have debug authority or access to the test environment of the workbench (see SAP Note 587410, skip the middle section but read the last sentence), then you have already won and I am sure you will find many other passwords and user’s accounts which you can “step into”…

    For me the biggest problems here are that the 2 passwords are the same and the cardinality of the users entered in the client side and many : 1 -> this makes you insecure and inflexible.

    Cheers,
    Julius

    (0) 
    1. Former Member
      Personally I would have consulted with SAP’s product management before publishing such a blog.

      SAP Note 1146690 was released prior to the blog…

      Equally important is the storage location, see SAP Note 1161548 which followed.

      Cheers,
      Julius

      (0) 
      1. Former Member Post author
        Good to know that SAP had already released notes. Hacking (even it were using debugging) is a controversial topic. So whether to share such thru blogs/forums is always debatable. But i strongly discourage using these passwords to change configuration & settings.

        -Siva Maranani

        (0) 
        1. Former Member
          I agree with you, but it is a hack and the account should not be able to change config if it is hackable or considered to be uncritical which cannot on it’s own do anything serious.

          The bigger problem here (in my opinion) is that the passwords were the same or silos are used in them (which include system typ, SID name, etc).

          You can see a part of that in the screen shot…

          If you think about the implications, then that is much worse if someone breaks the weakest link in the chain!

          Which is what Siva did here… and then misused it. He did not know the password of PISUPER, but could guess it based on the cleartext password of the SLD user.

          This is why the cardinality of connections are important: to make them unique and their passwords as well. Then you can change them at will, and not need to cache them, etc.

          Cheers,
          Julius

          (0) 

Leave a Reply