Weekend Learning: Oracle Key Vault - Master Note

Are you responsible for the security of your Oracle installation or the EBS application?  Do you know what Oracle Key Vault is, or how it can enhance your current security measures?  Find out more from MOS note 2120572.1 for the article "Master Note For Oracle Key Vault" so you can research!

Weekend Learning: Exadata security information

Do you run an Exadata installation?  Are you responsible for the security of said system?  Well then you might want to check out document "Responses to common Exadata security scan findings" on My Oracle Support note ID 1405320.1 and prepare for a lot of homework/investigation on your platform because this document is EXHAUSTIVE!

Weekend Learning: Security by Asset book whitepaper

Earlier this week I posted about Assets and linked in that MOS post was "Security by Book White Paper" found by article ID 111129.1 but I think it is important to highlight it here in Weekend Learning because there is always an opportunity to learn more so check this 30+ page PDF out to pick up something new!

Weekend Learning: Database Security Products - Information Center

In this day and age of cyberattacks or security leaks you need to bookmark My Oracle Support note 1548952.2 for the document "Information Center: Overview of Database Security Products" to keep up with the latest in Oracle security features, products, whitepapers, and new exploit information.

EBS R12 Security Issue: FND_LOG_MESSAGES

Were you aware that when you upgrade to E-Business Suite R12 one of the changes introduces a very serious security issue?  Read this note from CERT to find out what happened to the FND_LOG_MESSAGES table with the upgrade to R12 and why it is the root cause for the issue I shared at the beginning of the year about the volume growth for FND_LOG_MESSAGES!

ALERT: Bash vulnerability and Oracle products

Coming straight from Oracle Security Alert CVE-2014-7169, is the notice that the GNU Bash shell command line for Unix/Linux has a newly released vulnerability which will allow an unauthenticated user session to run code.  There are many products like Exadata, Solaris and Linux which do have a patch available to fix this (Exadata was not patched earlier this morning, unless I missed something) but there is a long list of Oracle application which do not yet have patches.  Follow the link to find all the details!

Limiting your attachment size in EBS

Did you know there is a built-in profile option to limit how much space users can upload in a single attachment for your Oracle EBS application?  After reading the MOS article "How to Limit The Attachment File Size?" via note ID 604458.1 you will know about the profile option as well and can start thinking of ways to use it to limit potential abuse.

Weekend Learning: DBA_NETWORK_ACLS

Did you know that you can use the information in the views DBA_NETWORK_ACLS and DBA_NETWORK_ACL_PRIVILEGES to control access to your system?  Note 1634275.1 from My Oracle Support clued me in on it, as this gives us a script to reverse-engineer a solution in case the ACLs are ever lost and it clearly shows this access is controllable down to the user level.  I was talking about security for our system a few days ago, and this is yet one more way to help secure the system!

Weekend Learning: Adding more security to Oracle Workflow

If you're a regular reader of this blog, you'll know that the Oracle Workflow product is near and dear to my heart for several reasons, so when I stumbled upon MOS note 965413.1 my curiosity was captured.  This note outlines several options for making the Workflow product more secure by limiting the amount of data returned to the user based on the partition that the data resides in, but I think the real benefit of this might be the suggestion you can add your own security sets on these data objects which may yield some positives if you're using the Workflow product quite a bit and need to segment your data returns.  How would you use this type of extra security in the Workflow product?

ANONYMOUS: To delete, or not to delete?

Have you ever seen the ANONYMOUS user in your EBS application, and wondered if it would be a good idea to remove it?  Well, read My Oracle Support Note ID 1078993.1 and find out!  Then, visit either Oracle's link to the note for securing R12 or visit my previous post on securing your EBS application which has both note references for R12 and 11i security.

Food for thought: Cloud Security

This post raises a good question: Why are more people and organizations not choosing to go with Software as a Service as their first option when it makes sense?  The answer is: cloud security.  I thought it was amazing that 50% of organizations are putting sensitive data into the cloud, but the figures of about 1/3 of companies have any type of cloud security policy shows how immature this field is right now and how dangerous it could be for organizations.  Lots of ideas, and articles, in this one.  Chew on it a bit.

How to secure your EBS platform

Did you know that Oracle provides you documentation on how to successfully configure the Oracle EBS for security?  It's true!  My Oracle Support note 403537.1 details the items for R12, while note 189367.1 goes over what you need to do on the older R11 version of EBS.

Since this is Security Week, I'll go out with a bang and tell you that while you're thinking security you should visit notes 564125.1 and 443353.1 as well to find out how to setup password security and how to change the GUEST password respectively.  Now let me ask a question.  Did you enjoy Security Week or did it fail to deliver for you?  Let me know in the comments!

Don't mix and match your GUEST passwords

Continuing Security Week here, My Oracle Support note 602425.1 tells you what happens when you change the password for the GUEST account to all lowercase or mixed characters in R12.  This type of situation reminds me of a time where we went to a single sign-on application but didn't test any permutations of accepted user passwords so there was a range of symbols which went untested before release.  When we made the switch to the new solution, it was in conjunction with a localization patch as well so it made it hard to understand what was causing a very small group of users not to be able to successfully log into the EBS system.  It wasn't until we did additional research like enabling logs and asking specific questions about what was in their passwords (without actually getting the passwords of course) that we realized the population having the problem all had special characters in their passwords and that the translation of the passwords from one system to another wasn't setup to allow the special characters until we could release a hot fix to the system.

The password is right there!

In an interesting post, here we see Oracle telling you right where a file is that has some of your critical and sensitive passwords in it in My Oracle Support note 458064.1.  Sure this might be filed under "for emergencies only" but I think it is dangerous for individuals with either server access or the technical know-how to get to the files being able to get a hold of this file and the associated passwords.  Good note to read, since the first step in battling security holes is to know where they currently exist.

EBS password size

This is a little off course from our usual "Security Week" type of post, but I think it is important information to know anyways in your efforts to secure the EBS application as well as your environment.  Per My Oracle Support note 1550649.1, users can encounter errors on the R12 platform if passwords are longer than 30 characters as some functions like FNDCPASS and AFPASSWD do not behave properly.  A few interesting bits on the page about what characters are NOT allowed in the password, other error messages that may occur for your end users, and the Enhancement bug which has been logged to get the UI updated to not allow passwords to be set to this length.

Unauthenticated setting of a profile value

You read the title right.  Oracle has documented in My Oracle Support note 364503.1 how you can set a profile value without being authenticated to the EBS application at all.  Sure, it is supposed to be used in an emergency manner and only for those that want to go and do some good or fix their systems.  What if it is used by individuals that don't exactly have good things in mind?  Would it be possible for somebody to get an authenticated database session, maybe using other things I talk about during Security Week, to your system and then really start to take over your EBS application?  Maybe they don't even try to take over your EBS system, but just start to collect usernames and passwords by changing something like where your authentication system directs to which can then be leveraged for more sensitive systems that you might have.

Of course if they get a authenticated database session with enough privileges it might make this a moot point, but if you visit that note you might find out a new way of setting your profile values at least!

APPLSYSPUB security - Part 2

Following up my first article on securing the APPLSYSPUB account, is this new article which tells you yet another place the password is hidden in your system and Oracle will ask you for it.  When the report Diagnostics: Apps Check (OMCHECK.sql) is run with the parameter of Application Object Library it will find all of the associated Profile Option Values for the Application Object Library module, which doesn't seem like a bad thing unless you realize that it will list the value for the profile option "Gateway User ID".

Not only does this profile option value have the username/password combination for APPLSYSPUB hard coded, but the Diagnostics: Apps Check report has no further security validation built into it so once it is available to a responsibility it is available to run for ANY module.  Ever have to add this to a responsibility to give Oracle some data?  Did you make sure to remove it?  Do you know who is running this in your system?

Security Week - GUEST during password change

This started out perfectly innocently as I needed to go into a test environment and reset a user account password so that they could get into the application and test something out.  Imagine my surprise when I encountered this scenario!

USERA logs into the application, in a second window USERB logs into the application but is prompted for a password change; going back to the first window and logging out USERA provides you with a returning User ID of GUEST for some strange reason and not USERA.  This means to me that before USERB gets authenticated, the Oracle EBS utilizes the GUEST user account and gets an authenticated session with that user ID.

This pretty much blew my mind, and lead me to do some more investigation of security issues related to user security for EBS so this week I give you "Security Week" after finding quite a few interesting nuggets from My Oracle Support.

Even better to prove my original hypothesis, going back to the window for USERB and trying to complete the password change attempt results in this message being displayed:

Error : You do not have a current session, please log in before visiting this URL.

APPLSYSPUB security

Recently I was asked to post the output from running "Generate concurrent processing environment information" to an Oracle SR, but before I did I scrolled through it before posting just to make sure there wasn't anything sensitive that was being transmitted.  I was quite shocked at what I found!  The password to the APPLSYSPUB account was right there in plain text for the whole world to see!

Listing of all Environment Variables:
.
.
.
.
GWYUID=APPLSYSPUB/<plain text password>
.
.
.
.