Skip to Content

<p>Recently I was performing an upgrade for Seeburger set of adapters on SAP PI 7.0 from version 1.7 to 1.8.1 (The latest version recommened for PI 7.0). During this upgrade, we faced some issues which made me realize that a basic flaw during installation of the Seeburger suite on PI could lead to a Security breach and could provide an opportunity for Mischief (a mild word) lovers or Swindlers (a harsh word) 🙂  </p><p>You might have recognized this earlier, but the couple of PI systems I observed, the Security team missed it. This promoted me to share this small but “could be relevant” issue.</p>h5. The Weak Point 

<p>One of the steps of Seeburger Installation is to create a user “seeburger” and assign the role “SAP_J2EE_ADMIN” to this user. Then it is advised to set the password of this user to “xxxxxxx” (I am not mentioning the password here as it could provoke some users to exploit it. This password is available with the installation manual). Wherever I happened to chek PI systems using Seeburger adapters, I knew there is a user “seeburger” with password “xxxxxxx” with quite good access to PI system information and configuration. I tried logging in and succeeded as this is a Dialog user. In most of the cases, a Basis consultant performing the installation doesn’t really dare to manipulate any such passwords to avoid security breach. This would mean that any developer who is part of Seeburger installations anywhere across the globe is able to access PI systems of their client with role SAP_J2EE_ADMIN. Access to this role, I believe, is not a recommended practice especially for large PI installation involving large number of PI developers.</p>h5. What to do? 

<p>The simple solution is to change the password as per your conventions and the Security Administrator could maintain such passwords separately.  The location where this password is used is</p><p>Visual Admin -> Server -> Services -> Connector Container -> Connectors -> Connector 1.0 -> seeburger.com/com.seeburger.xi.<Module> -> Managed Connection Factory -> Properties</p><p>Change the password of key “adapterUserPassword” to the new password and Save.</p><p>I hope the Security Administrators read it before the developers! ;)</p>

To report this post you need to login first.

10 Comments

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

  1. Julius von dem Bussche
    This (in)convenience was recently discussed in the SDN security forum as well, and to my knowledge Seeburger are removing password suggestions and looking into a standard role to deliver with their applications which use remote connectivity.

    See Authorizations for a RFC-User for Seeburger Application

    Thanks for adding the procedure to change the password on the connection side, so that customers can protect their systems.

    Cheers,
    Julius

    (0) 
    1. Prateek Raj Srivastava Post author
      Thanks Julius for the information and link about the ongoing discussion. I have a few more issues to be discussed about the product but I believe that should be taken offline with Seeburger.
      Best regards,
      Prateek
      (0) 
      1. Julius von dem Bussche
        I contacted Seeburger offline as well and found them to be very responsive to the issues.

        I always marvel at how security unaware some developers are, who implement such things without reacting to the thought (or faint suspect) that sooner or later it is going to backfire on them.

        Does anyone know what the legal position is? For example, if a hacker where to misuse this to access (all the rest of) a customer’s system would Seeburger be liable for damages?

        Cheers,
        Julius

        (0) 
        1. Prateek Raj Srivastava Post author
          Hi Julius,
          I really doubt that the product owners would ever bear the responibility of some flaws in their product. Otherwise it would have been difficult for Microsoft to tackle all hacked Windows systems’ responsibility 🙂 But I am not really aware about the legal aspects. May be someone from SAP could help us with that.
          Another issue I have should not be discussed on blog or forum (as it would be an unnecessary exposure and I don’t have any solution for it). Therefore I am still wondering whom should I contact.
          Best regards,
          Prateek
          (0) 
          1. Julius von dem Bussche
            Hi Prateek,

            I sent the contact details to you. Also copy secure@sap.com (SAP Security Response Team).

            Regarding responsibility, SAP themselves also have a “convenience password” but it is equiped with the bare minimum of access both by default and resets itself to this “non-critical” access… but whenever there is a program error within this accessible area then SAP fix it with HotNews priority.

            I think delivering a “convenience password” together with “full access” would be very very deep into the “grey zone” as you do not need any skills at all to exploit it and the impact is devastating for the whole system, as well as other connecting systems (which in the case of PI would be like “Rome”… ;-).

            Cheers,
            Julius

            (0) 
  2. Bernd Eckenfels
    Hallo,

    as you have mentioned: you can and should use a random/secure password for the PI RFC User. I already proposed to change the documentaiotn which was proposing a default password.

    However a small warning: if you use a random password this might get reset if you upgrade the adapter. This seems to be a problem with the RFC connector of NW, where the settings get overwritten. So be carefull to enter the user password again after an update. You should also use a non default user name.

    (0) 
    1. Prateek Raj Srivastava Post author
      Hello Bernd,
      Thanks for your comments and quick proposals.

      >>You should also use a non default user name.
      Does that mean that instead of user “Seeburger”, we could suggest Administrators to create altogether a different user? If there are no hard references to this username then this sounds good.

      Best regards,
      Prateek

      (0) 
      1. Bernd Eckenfels
        Hell,

        Yes, both, username and password can be configured with properties on the managed connection factory. It is adapterUser and adapterUserPassword properties respective.

        I think newer adapter versions use “seexxxx” (where xxxx is the adapter name) as the default value for the user name and older versions used a single user named “seeburger”.

        I would recommend to start it with “see” or “zsee” prefix to better find this technical user. As far as I know a single user is as fine as multiple, we changed this only to lower the impact of locked user, since we had some support calls because of that.

        Greetings
        Bernd

        (0) 
        1. Prateek Raj Srivastava Post author
          Hi Bernd,

          Now that we are doing away with the standard password suggestion “*******”, may be the point I am going to mention won’t be relevant anymore, but I would like to share one of the problems we experienced during Seeburger upgrade.
          With the latest SAP Basis versions, there is an option to set the minimum required length of the passwords. I discussed with some of our Security team members and they suggested that customers usually prefer minimum 8 character password (most of the times). The standard password we had for Seeburger user was only 7 characters and in our case we had to make it 8. This was the point where I started looking into the places it could affect and found the mentioned location. At that time I thought that the suggested password should be usually 8 (or whatever a general Security related trend in market is).

          Best regards,
          Prateek

          (0) 
          1. Julius von dem Bussche
            As password policies can differ (see SAP Note 862989) what you can do is test drive the password with the FM PASSWORD_FORMAL_CHECK to see whether it would comply with the policy (which ever that may be).

            Note that dependencies with the user type influence the policy, particularly the validity and the compliance with the current policy check of a user’s existing password.

            This means that for SERVICE and SYSTEM users which already have this problem historically, and the password is not reset voluntarily… then the problem will remain.

            I think customers should be notified of this, as they will otherwise not notice. Hardening the password policy will not help.

            Cheers,
            Julius

            (0) 

Leave a Reply