POODLE has been a fairly common topic with security teams recently since Google announced the vulnerability.
There is plenty of reading available on the POODLE attack so I’m not going to go into too much detail but I’ll give a short description. POODLE is a man-in-the-middle attack which uses an attackers ability to force the protocol of the server/client communication to fall back. When the attacker can force the downgrade of the protocol to SSLv3 they can attack the weaknesses of that protocol. SSLv3 has been around for a really long time, since 1996, and has been superseded by multiple versions of TLSv1.x. TLSv1.2 is the latest version available and TLSv1.3 is currently in draft status. As these new TLS versions were released they were implemented in new servers and applications, however for interoperability all the old protocols were also left active.
So are you vulnerable? As a PeopleSoft Admin/User/Developer do you need to worry about this? Well, that depends. From my experience, the vast majority of PeopleSoft installations are internally accessible only and do not even implement SSL. So if you are in this category, hey, don’t worry, your data crosses your network in it’s birthday suite regardless! The next category is those who run PeopleSoft internally with SSL implemented, a good idea in general. Since this is a man-in-the-middle attack, if you can only access the system internally, the attacker would need to be internal. If you are one of the smallest group, those that are running PeopleSoft externally exposed, I recommend checking your system with the free Qualys SSL Tester. This tool will scan your site if it is running on the default port of 443 and give you a nice report.
Your exposure to POODLE and remediation steps are dependent on where the SSL is actually deployed. If you are in a large complex environment that utilizes load balancers, SSL offloading devices, or other reverse proxies, someone may have already mitigated the risk for you. As a PS Admin, there may not be anything for you to do. However, if you are running a smaller shop and using SSL directly on Weblogic you should look more into your particular usage.
The fastest mitigation strategy is to disable SSLv3 entirely on the device that handles SSL. As mentioned prior, that could be a multitude of things. I’ve worked in environments that used F5’s, Cisco Ace’s, reverse proxies, or just did SSL right on the Weblogic instance. In the general world of https just putting a hard stop on SSLv3 may not be entirely possible. However, in our limited scope of PeopleSoft, we generally have more control of who or what connects to our environment. Our systems usually have a more targeted audience and we have more control in the relationship. If you have very old browsers or integration components in your environment this might not be feasible though.
From a user standpoint, you can disable SSLv3 in your browser. Pretty much every browser vendor has announced they are disabling SSLv3 in their browsers going forward. Mozilla has already disabled SSLv3 with Firefox 34 which was released Nov 25th. This would give each individual user with SSLv3 disabled protection. But as we know not everyone stays current on browsers. For anyone running PeopleTools 8.49 or older which supported IE 6, you may wish to review your access logs and analyze what browsers are hitting your system. If any of your users may still be running IE 6 disabling SSLv3 at the server would most likely deny those users access. IE 6 does contain TLSv1.0 support, however it is disabled by default. You would need to get all your users to enable TLSv1.0 before disabling at the server.
I’m currently working on an article about my analysis of SSL in Weblogic and other PeopleSoft components. It will be the article that someone wanting to mitigate POODLE directly on Weblogic will want to read.
Update: The new SSL and Weblogic analysis article is now finished.
Leave a Reply