Sunday, February 26, 2006

Security

Is it easy to hack PeopleSoft? The answer to this question is not a simple ‘NO’. You could keep arguing on this, but let me give you some background on what I did, trying to achieve this and also provide a feature which any ERP must package along with its application.

I was into my sixth month as a PeopleSoft consultant and did not know much about PeopleSoft at this point I was reading a book on cryptanalysis (I don’t remember the name of the book, it was not any computer hacking book instead it gave a very good Mathematical analysis on the topic); my interest in hacking the PeopleSoft system could be attributed to this book. One place where I thought PeopleSoft was weak in its security offering was the Application Designer connected to the database in two-tier mode, PeopleSoft Peoplebooks has this to say about Application Designer in two-tier;

“A determined hacker could hack into the PeopleSoft system if he is provided with this.”

A first step here is to realize the simple fact that when we log on to the Application Designer we use PeopleSoft user id and password. PeopleSoft user id and password are stored in the database; PeopleSoft Application Designer must be able to establish a connection to the database before it could validate the user id and password – interesting! This is when I remembered the connect id and password, and the grant.sql in pshomes where I could set the connect id and password. The connect id and connect password are the access id and access password to the database with permissions to select from PSSTATUS, PSACCESSPRFL and PSOPRDEFN. This is where the Application Designer validates the PeopleSoft user id and retrieves the access id and password to log on to the database.

I have found the place from where I can retrieve the information but know it is encrypted (This is where you must be “determined hacker”). Application Designer has a C++ code which actually knows how to decrypt the passwords retrieved from the database (A determined hacker would be able to obtain the code by decompiling the application at this level, will also find himself behind bars for obtaining the source-code of a commercially licensed product). I realized that there is still another place, if I get the encryption logic with the key (once I get the encryption code, the key should be within the piece of code that was used for encryption.). PeopleSoft user profile creation page allows the user to enter a password and on saving a user profile it encrypts the password that we typed in. Had PeopleSoft been stupid enough (which they are absolutely not) they would have written the encryption code as a PeopleCode, but instead they provided a peoplecode built-in function “HASH” to encrypt the passwords (I would love to set a PeopleCode trace and know if the code for an inbuilt function is visible….I know for certainty that it would not be).

Can I stop my hacking desire here? No, because I remember something that was taught to me during my initial PeopleSoft Boot-Camp – we could encrypt the passwords using Data Mover (this is just an encrypt.dms which again uses a PeopleSoft inbuilt function) and cipher.bat file. Cipher.bat file interested me and made me think that I can do it now. But I outsourced this particular job to one of my friends and he told me that this bat file calls a number of java class files (I’m not certain about this and not sure whether we could decompile the class files – not a geek when it comes to programming languages). People who are interested can actually try something out here.

But if only you are a mathematical hacker you could hack the encrypted passwords and get the key used by PeopleSoft, if I do this I would probably land in RAND or behind bars (basically because PeopleSoft must be using the RSA and it has one private key which is built-in, RSA decryption is not a simple thing but we can get lots of sample data by creating our own user ids and passwords.) This is sure to take a lot of time but it is not without its benefits, read on to know how you could benefit out of this particular effort.

I have seen a lot of customers who blindly use people and peop1e to be connect id and password respectively in their PeopleSoft system (We should be through to get the encrypted passwords). PeopleSoft does provide the option of extended encryptions to Customer’s passwords, but this code (and algorithm) has to be developed by the Customer. Not even a single Customer who I came across has done this, reasons could be that you have to find a mathematician to develop the algorithm and then implement it. None of the service providers could take the pains of accomplishing this. If we could somehow obtain the PeopleSoft encryption key, we get access to almost all the PeopleSoft systems on planet Earth (remember we must have two-tier access). At the three-tier level I have a strong feeling that PeopleSoft is very secure.

So is there something that can be done about this? The solution is that an ERP should provide strong encryption algorithms (PeopleSoft already does this) along with this the Customer must be allowed to choose his private key which can only be used to decrypt the passwords. The Application Development environment (Application Designer in the case of PeopleSoft) must get the private key from the Customer and then use the inbuilt decryption algorithm to decrypt the password.

4 comments:

Anonymous said...

I hate to disagree, but I've never considered PeopleSoft particularly secure. All of the security is enforced at the application level and very little is enforced at the database level. No big deal if you can't get the super user password (usually SYSADM in an Oracle database). But getting SYSADM's password is much easier than you might think.

The weakest link is with SQR. To call an SQR, PeopleSoft passes SYSADM's user ID and password on the command line.

Back in the 7.5 days, to get SYSADM's password all you had to do was to rename notepad.exe to SQRW.EXE and put it in the c:\temp directory. Then change your SQRBINW directory in config manager to point to C:\temp. Then run any old SQR on your client. It would execute Notepad (now called sqrw.exe), and notepad would error out with a "Cannot open SYSADM/secretpwd".

Starting with version 8 you can't run things on the client. But a developer with the right access could still redirect SQR to a rogue script or batch file that echos the command line.

Maybe a little more security at the database level would be a good thing.

PS-GUY said...

Replacing Notepad.exe for sqrw.exe that was something that I never tried. Great thanks for the info.

Anonymous said...

Couple things...

a) PeopleSoft uses a one-way encryption technique, where even if you had decompiled code, you would not be able to "decrypt" any passwords.

b) Many of these ideas assume an internal user and a non-secured data center. Using standard network security techniques, the user should not be able to access machines with SQR or other binaries.

c) Datamover can be a huge weakness as well, and admins need to secure the rights to run datamover to only the very privileged.

Also, the SYSADM user should never be called "SYSADM" or "sa" as this is public information. Additionally these passwords should be strong and rotated monthly.

PS-GUY said...

ab,

The post talks about PS's one way encryption with their own encryption algorithm and key to be the biggest weakness. If you are a proffessional hacker and are able to hack one PeopleSoft system, you will have complete access to all the other PS systems. That is why I want PeopleSoft to provide the customer with a capability to choose his private key instead of making it universal.

All this said, I am restating the same aspect, the PS systems are as secure as they always are in the three tire architecture.

Internal user is not always the case, all PS customers will have some piece of the work to be done by an outside consultant. Once you have hacked the password security you could work with multiple clients and get sensitive information (Would not think about doing it, just pointing the weak link here)

Thanks